You also need to remove the HIDE option from the AccessUtil= line. Otherwise, components in the old base components section won't be available in the Add/
Remove Programs applet. Finally, save and close the file.
To display the selected components in Add/Remove Windows Components after Setup completes the installation, go to the \%systemroot%\inf folder, and locate the sysoc.inf file. Make a backup copy of the file (e.g., by copying sysoc.inf to sysoc.bak), and use a text editor, such as Notepad, to open the sysoc.inf file and make the changes described in the previous procedure. After you finish and save your changes, you can manage these components through the Control Panel Add/Remove Programs applet.
In our Windows NT 4.0 Service Pack 4 (SP4) environment, we use DNS (through BIND 4.0 servers). Our biggest NT resource domain is called TELLABS, and most of the workstations at our headquarters are in this domain. We're concerned that our UNIX box might be getting barraged by queries to the TELLABS domain. The Fully Qualified Domain Name (FQDN) of the UNIX host is tellabs.hq.tellabs.com (the short name or alias is tellabs). We haven't selected the Enable DNS for Windows resolution check box for any of our machines. Are our concerns valid?
I don't think your UNIX box is receiving any unnecessary traffic because the DNS and NetBIOS namespaces are separate. If a NetBIOS name query for TELLABS comes from a WINS-enabled client, the query will probably be in the form of a request to locate a domain controller for the TELLABS domain (e.g., to a WINS server or through a broadcast). The WINS-enabled client usually directs its NetBIOS-style name query at a WINS server; thus, DNS wouldn't receive the query. The WINS server's response to this query is a list of the IP addresses of various domain controllers for the TELLABS domain, not the tellabs.hq.tellabs.com UNIX host.
However, this process doesn't guarantee that you won't experience a name-resolution conflict in the future. A more likely scenario for undesirable results is an environment in which the DNS host name is identical to a NetBIOS name on a different IP host. In this case, depending on how a client queries for the name, a name server might return the wrong IP address to the client. For more information about why this error could occur, see "Navigating Name Resolution, Part 1," June 2000, and "Navigating Name Resolution, Part 2," July 2000. A good practice is to keep your DNS and NetBIOS names the same on machines whenever possible, and to avoid creating conflicts between these two namespaces (with host names and group names such as the NT domain name).
While trying to find a solution to a problem in which Windows NT doesn't boot unless I use a boot disk, I discovered the Microsoft article "Windows NT Does Not Boot with Highly Fragmented MFT" (http://support.microsoft.com/support/kb/articles/
q228/7/34.asp). This article instructs me to run bcupdate.exe but doesn't provide any information about where to find this file. Any ideas?
From what I can tell, you've discovered a phantom utility. From time to time, in Knowledge Base articles, Microsoft mentions utilities and patches that the company claims to have developed for various problems but that don't actually exist. In the article you mentioned, Microsoft describes bcupdate.exe as a utility that ships with NT Service Pack 6 (SP6) and SP6a and modifies NT's boot code. The article claims that this modification remedies your boot problem, which is caused by excessive fragmentation of the Master File Table (MFT) on an NTFS system partition. I searched every NT service pack CD-ROM, TechNet, the Microsoft Web site, and newsgroups and NT-related discussion sites, but I never found any mention of this utility. Perhaps Microsoft incorporated bcupdate.exe's functionality into the SP6 and SP6a update process. Or maybe the utility never materialized.
To solve your problem, try upgrading to SP6a to see if the boot-code modification promised in Microsoft's article occurs. If this method doesn't solve your problem, you can use the most recent versions of Executive Software's Diskeeper and Symantec's Norton Speed Disk utilities to defragment the MFT on an NTFS volume. You might be able to use one of these utilities to sufficiently defragment the MFT and restore typical boot functionality to your system.
Although setting up the Internet Connection Server (ICS) service on my Windows 2000 Server system seemed straightforward, I'm having problems getting ICS to work properly. Any ideas about what might be causing the problem?
My guess is that the server you're attempting to configure ICS on is also acting as a dynamic DNS (DDNS) or DHCP server. To enable LAN clients on the private network to use ICS's connection for connecting to the Internet, ICS automatically sets up a small DHCP scope (called the DHCP allocator) and a DNS proxy service. These two services bind to the same ports that DDNS and DHCP servers use; thus, a conflict results between ICS and DDNS or DHCP. Solutions to this problem include moving ICS to a different machine or using Network Address Translation (NAT—
within RRAS) instead of ICS to enable IP translation for the internal network. Unlike ICS, NAT is configurable. For example, you can configure NAT not to use the DHCP allocator by clearing the Automatically assign IP addresses using DHCP check box on the Address Assignment tab of the NAT Properties dialog box; this action removes the interference with DDNS. You can also configure NAT to avoid conflicts with DDNS services running on the same machine by clearing the Clients using Domain Naming System (DNS) check box on the Name Resolution tab of the NAT Properties dialog box. For more information about ICS conflicts, see the Microsoft article "ICS May Not Function Properly with DNS or DHCP Server Services on the Same Computer" at http://support.microsoft
.com/support/kb/articles/q250/6/03.asp.
I'm having a problem with Internet mail on Microsoft Exchange Server. In my event logs, I often see undeliverable messages with the error message 503 Please introduce yourself first. What is causing these errors?
This problem relates to Enhanced SMTP. ESMTP includes encryption on top of the authentication that Exchange Server uses to transfer Internet mail. SMTP doesn't include this additional layer of encryption. Some systems aren't compliant with Internet Engineering Task Force (IETF) Request for Comments (RFC) 1651, which defines ESMTP commands. This limitation can result in compatibility problems when sending email: The receiving email server expects an SMTP response from the sending email server, and the sending email server sends the response in ESMTP, which the receiving email server doesn't recognize.
To solve this problem, you can disable outbound ESMTP in Exchange Server. However, by doing so, you lose the ability to send the ETRN command on a dial-up connection. ETRN is an ESMTP command that alerts one ESMTP gateway or mail host to process email that is awaiting delivery to another SMTP mail-handling system. If your email server is sending and receiving email over a leased line, this loss of ability won't be a problem. However, if you're using Exchange Server with DUN to retrieve email from an outside host, talk to the host's managers about the potential effect of disabling the ETRN command. Disabling ESMTP also removes the added encryption layer you gain from using ESMTP rather than SMTP.
To disable outbound ESMTP in Exchange Server, start regedt32, go to the HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\MSExchange
IMC\Parameters subkey, and add the DisableOutbondESMTP subkey of data type REG_DWORD and a value of 1. Verify that the new value appears in the parameters list, close regedt32, and stop and restart the Internet Mail Service (IMS).