Windows 2000 User Profiles; An SP6a Winlogon Bug Fix

Windows 2000 Roaming Profiles in a Mixed Environment
Many of us are testing or running mixed environments with Windows 2000 (Win2K) and Windows NT 4.0 servers and clients, and the majority of us implement server-based user profiles to ensure user desktop integrity. Here’s a quick summary of two important changes in Win2K user profile management and a couple of pointers for avoiding roaming profile update problems in a mixed environment of Win2K workstations and NT 4.0 servers.

Win2K requires greater access permission than NT 4.0 does to update user profiles. When Win2K updates a user profile, it writes information about any desktop changes a user makes during the interactive session. In addition to updating the contents of the profile, Win2K also updates the user profile file’s ACL (an extended file attribute). In NT 4.0, the system updates only the contents of the user profile file, not the ACL associated with the file. Another critical difference between the old and new OSs is that the Win2K user profile update code requires WRITE_DAC access to update the ACL on a server-based roaming profile. While Change permission NT Server 4.0 doesn't allow this access, Change permission in Windows 2000 Server (Win2K Server) has the appropriate rights to update the server-based profile’s ACL.

The upshot is that when you store a Win2K user profile on an NT 4.0 server and the profile share has only Change permission, Win2K can’t update the profile file’s ACL and the roaming profile update fails. If you’re running this configuration, your users will see the error message, "Windows cannot update your roaming profile. Contact your network administrator. DETAIL - Access is denied" when they log off. To eliminate the profile update error and ensure that Win2K updates the profile successfully on an NT 4.0 server, you must give each user Full Control access to his or her profile share on the server.

If you support NT 4.0 clients but store user profiles on a Win2K server, you don’t have to grant Full Control to user profile shares because the enhanced Win2K Change permission lets the OS correctly update the user profile ACL. See Microsoft Support Online articles Q255113 and Q257848 for more information about roaming profiles. You can also find good hints and tips on managing user profiles in a mixed environment in Microsoft Support Online article Q224012.

User Profile Space Requirements
Another difference between Win2K and NT 4.0 profile management is that Win2K employs a two-step process to copy a user profile. To successfully update a profile, Win2K's two steps require that the profile directory have free space equal to twice the user profile file size. If that space isn’t available, the message "Windows cannot update your roaming profile. Contact your network administrator. DETAIL - There is not enough space available on the disk" might appear when a user logs off, and Win2K won’t update the server-based profile. If you implement disk quotas, be sure each profile directory has a quota greater than twice the user profile file size. Microsoft Support Online article Q257838 discusses profile space requirements.

User Profile Registry Entries
You can't change the Default User Profile cache location on a local machine in NT 4.0, but in Win2K, you can change the two Registry entries that identify the directory and the path of the Default User profile. The Registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList DefaultUserProfile Reg_Sz Default value = "Default User" defines the directory, and the Registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList ProfilesDirectory Reg_Sz Default value = "%SystemDrive%Documents and Settings" defines the path to the directory.

You can easily change the path and the directory by modifying these Registry entries with your favorite Registry modification tool. See Microsoft Support Online article Q214636 for more information.

Service Pack 6a Winlogon Bug Fix
Service Pack 6a (SP6a) introduces a memory leak in the WinLogon termination code that prevents orphaned handles from closing. If you call the RegConnectRegistry() API repeatedly, many open handles to Winlogon might accumulate and slow authentication and system performance. On April 4, Microsoft released a bug fix that closes the handle leak. You must call Microsoft Support to get the bug fix, which updates two components—services.exe and winlogon.exe. Microsoft Support Online article Q259042 documents the problem.

Office 2000 SR1 Installation Sequence Problems
If you install Office 2000 on an NT 4.0 system, upgrade the system to Win2K, and then apply the Office 2000 Service Release 1 (SR1) update, the Search and Find buttons in Office 2000 cease to function. The upgrade sequence introduces other problems as well: Nothing happens when you open a Web page in a new window, Internet Explorer (IE) doesn’t start when you click a URL in an Outlook message, you can’t view Outlook in full-screen mode, and both Word and Excel generate the error message, "An unexpected error has occurred" when you click a hyperlink. Microsoft Support Online article Q258774 explains that if you install SR1 in this sequence, it doesn’t properly register oleaut32.dll. You can resolve these problems by manually registering the missing DLL with the command Regsvr32 Oleaut32.dll.