SEND US YOUR TIPS AND QUESTIONS. For answers to more of your Windows 2000 and Windows NT questions, visit our online discussion forums at http://www.win2000mag.com/support.
\[Editor's Note: Bob Chronister contributed answers to this Tricks & Traps.\]
My company runs Computer Associates' Inoculate IT 4.53 on its network, and most of the machines are behind a server running Microsoft Proxy Server 2.0. Processes running on some of our Windows NT systems fail to initialize properly at system startup, and we therefore must manually start them. The problem isn't limited to Inoculate IT processes—even the Task Scheduler utility (mstask.exe) is experiencing problems. In each case, the NT Event Viewer Application log shows an Event ID 3 with Winsock Proxy Client as the source and the following description:
Application <name of failed process> was started while the service manager was locked and the NtLmSsp wasn't running. If the application will try to remote via WinSock Proxy it can cause a deadlock with the service manager. For this reason the remoting is disabled. If the application is a service and you want to be able to remote, make it dependent on NtLmSsp.
What can we do to resolve this problem?
This problem is common in, but not exclusive to, systems running the Winsock Proxy Client that accompanies Proxy Server. The problem usually happens because the service in question is attempting to initialize and run through Proxy Server's remote Winsock service while the service database is in a locked state. I've seen similar error messages when newly installed services don't create the proper service dependencies (i.e., loading service A before loading service B). In your situation, the problem is that the NtLmSsp service isn't running when other services that depend on it attempt to initialize.
The solution is to manually edit the Registry entry related to the failing service so that the failing service won't attempt to load until the NtLmSsp service has successfully initialized. I recommend that you use the regedt32 Registry editor to make the following changes because it (unlike regedit.exe) properly supports the REG_MULTI_SZ Registry data type.
First, you need to locate the Registry entry related to the failing service. Service Registry entries are listed alphabetically in the HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services Registry subkey. In some cases, the service's Registry key name will be the same as the process name (e.g., NtLmSsp); other services' keys will have descriptive names (e.g., InoculateIT Server). To locate the right key, use the Registry editor's Edit, Find option to search for the process name (i.e., the name of the process' .exe file) within the Services subkey. After you locate the service's Registry subkey, select the service name in the Registry editor's left pane, and edit or add the DependOnService subkey of type REG_ MULTI_SZ. Set the value of the DependOnService subkey to the name of the service (as it appears in the Services Registry subkey) that you want the failing service to depend on. In your case, set the value to NtLmSsp, as Figure 1, page 188, shows.
If the failing service requires multiple dependencies, enter the name of each service on separate lines in the DependOnService value dialog box. Some services are members of service groups (e.g., SCSI miniport, Primary disk, Video), so you can also create dependencies with service groups. For more information about service and service group dependencies, see the Microsoft articles "CurrentControlSet\Services Subkey Entries" (http://support.microsoft.com/ support/kb/articles/q103/0/00.asp), "REG: Network Services Entries, Part 2" (http:// support.microsoft.com/support/kb/ articles/q102/9/96.asp), "HOWTO: Control Device Driver Load Order" (http:// support.microsoft.com/support/kb/ articles/q115/4/86.asp), and "How to Delay Loading of Specific Services" (http:// support.microsoft.com/support/kb/ articles/q193/8/88.asp).
You can use the Microsoft Windows NT Server 4.0 Resource Kit's sc.exe utility to query and modify service dependencies from the command line. See the resource kit's documentation for information about how to use sc.exe.
My supervisor and I can't figure out how to configure authentication for Windows NT security. We set up an IUSR_computername account in User Manager, permitted anonymous access in Microsoft Internet Service Manager (ISM), and selected Basic (clear text) authentication. However, when we test the authentication, we receive a pop-up dialog box that asks for the username and password. The system then rejects the username and password that we submit. How do we configure the system to let clients see a site after they input their username and password?
Anonymous authentication (i.e., authentication for directories and files that don't require explicit authentication and are publicly available) requires an extra step in addition to the configuration you've already set up. You need to verify that the password of the IUSR_computername account (e.g., IUSR_MYSERVER—the account that the system uses to provide anonymous access to the server) matches the password configured in ISM. (You can check this manually in Microsoft IIS 4.0 or 3.0 or through automatic synchronization in IIS 4.0 and later.) In User Manager, you also need to ensure that you assign to the IUSR account (or the group that contains this account) the rights to log on locally to the NT IIS server. Also, through file-system ACLs, make sure that you assign to the IUSR account the appropriate NTFS permissions on any directories to which you want anonymous users to have access (i.e., set read permissions on these directories). To require authentication for Web server access (i.e., so that even the default home page on the server prompts users for authentication), when you configure the server or a particular Web site, clear the Allow Anonymous Access option on the Directory Security tab to disable anonymous access.
To set up access to content that requires explicit authentication, you follow the same procedure as you did for anonymous authentication. However, you must also create an additional account in User Manager to which you assign rights to all files and folders that require authenticated access. In your case, don't assign rights on these files and folders to the IUSR account. Doing so causes the clients' browser to prompt the clients for authentication when they attempt to access the protected folder or file on the server. Your authentication setup should work correctly as long as you've assigned the proper ACL permissions to the user's account (i.e., the account that the user authenticates with through the browser) for the files and folders that you want them to be able to access, the user account has local logon rights on the server (or domain if the IIS system is a domain controller), and the system uses the correct password to authenticate the user.
Unlike Windows NT 4.0 Setup, Windows 2000 Setup doesn't let you choose whether you want to install components such as games, multimedia files, accessories, utility applications, and accessibility options. Win2K Setup installs them by default. After Win2K Setup completes the installation, I go into the Control Panel Add/Remove Programs applet and select Add/Remove Windows Components, but no options are available to remove these items. Can I control whether Win2K Setup installs these components?
A:You can modify Win2K to control whether Setup installs these components during setup or after. However, doing so requires manual file editing. To force Win2K Setup to enumerate these items for selection during setup, copy the \i386 folder from the Win2K installation CD-ROM to a distribution share on your local system or the network. Next, locate the sysoc.in_ file in the \i386 directory, and use the following command line to expand it:
Next, edit the expanded sysoc.inf file to display the components that you want to be able to select during installation. (Figure 2, page 190, shows an example expanded file.) To edit the file, locate the line in the file that reads
For each component that you want to appear in the Add/Remove Programs applet, remove the HIDE field and its associated comma. For example, to force Setup to enumerate multimedia components, change the line that reads
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).