How Win2K and NT 4.0 Apply Group Policy and System Policy
The party line on Windows 2000 Group Policy and Windows NT 4.0 system policy, which can include computer and user policies, is as follows. Win2K and NT 4.0 apply policy from the domain in which the respective account exists. In the simplest case—when the computer and user accounts are in an NT 4.0 domain—clients running either platform apply computer and user settings from the NT 4.0 system policy file, ntconfig.pol. When computer and user accounts are in a Win2K domain, the client OS applies the equivalent Group Policy settings for the computer and the user. When a computer account is in an NT 4.0 domain and the user account is in a Win2K domain, the client receives computer policy settings from ntconfig.pol and applicable user settings from Win2K’s Group Policy. In the reverse situation—when the machine account is in a Win2K domain and the user account is in an NT 4.0 domain—the computer settings come from Win2K's Group Policy and the user settings from NT 4.0's system policy. I haven't tested all these combinations, so let me know if your experience deviates from the party line. And if you have trouble debugging these scenarios, try the Win2K environment debugging technique I described last week.
NT 4.0 and Win2K System Policy Mode Settings in the Registry
Have you ever defined a system policy, logged on to a system where the policy should apply, and wondered where the policy settings went? Apparently, some OEMs are shipping Win2K and NT 4.0 systems with a registry setting that disables the application of system policy. In such cases, registry value entry UpdateMode (type of REG_DWORD) in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update registry key is set to zero. If you set UpdateMode to one (Automatic mode), the system searches for a system policy file named ntconfig.pol in the authenticating server’s Netlogon share. If you set UpdateMode to two (Manual mode), the OS searches for the system policy file in the location defined by the accompanying value entry NetworkPath. Microsoft article Q168231 documents these registry settings.
Windows 95 RAS Connection Problem
I get mail every week from people who have problems connecting Windows 95 clients to a RAS server. Here's yet another explanation for Win9x client connection problems, but this one's specific to RAS—it's not a known problem with NT 4.0’s RRAS. When a Win95 client attempts to connect to an NT server using encryption, the client might receive one of our least favorite messages, "No domain server was available to validate your password. You may not be able to gain access to some network resources." You might also find Event ID 8006 in the Event Log with the text, "The browser has received an illegal datagram from the remote computer <Windows 95 client name> to name <Server name> on transport <Transport name>. The data is the datagram." Really helpful information, huh? If you select the Enable Encryption check box on the Win95 client connection, the problem won't occur.
Microsoft’s explanation for this behavior is that when both the server and the client use encryption, they occasionally lose synch with each other and end up trying to negotiate encryption with different (i.e., non-matching) keys. Microsoft article Q262466 indicates that you can call Microsoft Support for a bug fix that corrects the synchronization problem. Ask for the version of ndiswan.sys released May 8. The article header indicates that this is a problem with Service Pack 4 (SP4), but the keyword indicates that it’s a post-SP6a fix. I assume the post-SP6a description is more accurate; if so, I wonder why Microsoft didn’t post the article until 5 months after releasing the bug fix.
How to Restore Control Panel
Occasionally—and especially after playing with computer and user policy or Group Policy—
Control Panel’s .cpl files become corrupted. The corruption can exhibit many different symptoms, but among the most obvious are missing Control Panel icons or icons that don’t match the utilities they represent. If things are in really bad shape, your Win2K or NT 4.0 system hangs when you try to open Control Panel—and when Control Panel is this corrupted in Win2K, you can’t even open it when you boot in Safe mode.
Each Control Panel utility has a corresponding .cpl file in the System32 directory, and several .cpl files support multiple tools. When Control Panel doesn’t open, you must figure out which file is corrupt so you can replace the corrupt file with one that works. Here’s a general debugging technique you can use to isolate the bad .cpl file or files. Create a temporary folder on the desktop and move all the .cpl files from the System32 directory to the temporary folder. Next, try to open Control Panel. If it opens, don’t be surprised when no icons appear—you moved the .cpl files, so the icons are gone. Copy the .cpl files back to the System32 directory one at a time. Open Control Panel after copying each file, and when the problem reoccurs, you have identified the corrupt .cpl file. Of course, the system will hang. Reboot, delete the offending .cpl file from the System32 directory, and replace it with a clean version from the distribution media. You can find detailed instructions for reconstructing Control Panel in Win2K, NT 4.0, and Win9x in Microsoft article Q221153.
