Cleaning Up After Sysprep

Windows 2000 uses the Server Message Block (SMB) protocol to implement remote file access. When a Win2K Professional client accesses a file on a Win2K server, the client uses opportunistic locking (oplock) to cache file information locally and ensure that the file is marked as open and in use. The caching part of the technique reduces the time the client spends accessing the file; oplock technology also prevents another client from accessing and potentially modifying the same file until the first client is finished and closes the file. When the client closes the file, the Win2K server must release the lock before the file is available for access by another client. Although releasing the lock takes server-processing time, the trade-off in speed on the client usually compensates for the server overhead.

The oplock mechanism is enabled by default on Win2K Pro systems but isn't enabled on the server versions. According to the Microsoft article "Configuring Opportunistic Locking in Windows 2000", you can enable and disable oplocks on Win2K Pro systems by modifying the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMRxSmbParametersOplocksDisabled registry subkey with a value of type REG_DWORD. The system uses oplocks when the OplocksDisabled is 0 and disables oplocks when this value is set to 1. On the server side, you can configure the server to grant or deny oplock requests from a client by changing the value of the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparametersEnableOplocks subkey, which has a value of type REG_DWORD. When enableOplocks is 1, the server grants oplock requests; the server denies requests when this value is 0. The reference article also documents several oplock fine-tuning controls in the registry.

If you use Sysprep to build Win2K Pro client images, when you copy the master image to two systems, a bug in the utility causes both systems to have the same globally unique identifier (GUID) in the registry. A coding error in Sysprep writes the same GUID as a value entry in the registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparameters.

A duplicate GUID in this registry location prevents new client systems from using oplocks and thus slows access to remote files. You can work around the problem by deleting the GUID entry in the registry of the master image before the final reboot. When you delete the GUID, the system creates a unique identifier during the next reboot. The idea behind Sysprep is that you build your image and deploy it, so the manual step of deleting a registry value entry can be inconvenient when the pressure’s on.

Microsoft released a bug fix for the duplicate GUID on Windows XP and Win2K images. The Win2K fix updates 34 files, and most of the files have a release date of February 6. The XP fix consists of a new version of the server service, srvsvc.dll, also with a release date of February 6. These fixes are available only from Microsoft Product Support Services (PSS). To speed the response you receive, cite the Microsoft article "Opportunistic Locking May Not Be Granted If Windows Is Installed by Using Sysprep" as a reference.

Sysprep Image Logon Delay
On a related note, you might experience a significant delay—maybe as long as 2 minutes—when logging on to a system built with Sysprep. The utility incorrectly sets a value in every image that controls the interval between full Group Policy Object (GPO) loads. This forces a Sysprep-created image to reload the full GPO each time a system boots—and the delay you experience logging on is directly proportional to the complexity of your group policy.

According to the Microsoft article "Logon Delays on Computers That Were Imaged by Using Sysprep.exe", the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionWinlogonGPExtensions\{GUID}MaxNoGPOListChangesInterval subkey defines the maximum interval in minutes between full GPO loads when the policy hasn't been modified. The correct default value for this entry is 960 minutes (16 hours), but the mini-wizard that runs after Sysprep finishes incorrectly sets this entry to 1. Because the maximum interval is 1 minute, each Sysprep-built image reloads the full GPO every time you restart the system. This problem has no bug fix, but you work around the problem by changing the registry subkey to 960 minutes—either manually or with a script.

Win2K Post-SP3 LSASS Memory Leak
Win2K Service Pack 3 (SP3) corrected several Local Security Authority Subsystem (LSASS) problems, but Microsoft has uncovered yet another memory leak in this component that can cause a Win2K server to hang. If you have a heavily used server that periodically stops responding, this memory leak might be the problem. To diagnose the problem, run Performance Monitor to monitor the private bytes counter for the LSASS process. Over time, the number of private bytes steadily increases until the pool is exhausted, then the server hangs. You can restore server operation by simply rebooting, but you might want to ask PSS for the bug fix released at the end of January. Microsoft article "A Memory Leak Occurs in the Lsass Process" states that the patch updates 25 files, most of which have a file release date of January 24, 2003.