Win2K SP2 Integrated Installation Hits the Street
Microsoft released a new-install only version of Win2K with integrated Service Pack 2 (SP2) files on May 7. The integrated installation contains an SP2 version of all Win2K platforms. This version lets you install new systems running Win2K SP2, but it doesn’t let you update existing Win2K systems to SP2. If you’re eager to start testing, you can download the integrated version from the Microsoft Web site. At 101MB, it’s a large download, and it expands to a robust 120MB. Files in the service pack have a release date of May 4.
For a brief overview of what the integrated download contains, use the command w2ksp2.exe /x to expand the service pack, and open the file \i386\root\spnotes.htm. Because the public release is in progress, the file links to Web pages that aren’t yet public. However, the file contains some important details:
- SP2 installs the high-encryption version of the OS, and you can’t revert to the standard 56-bit encryption.
- Because the installation integrates SP2 files with the baseline OS, you can’t uninstall the integrated version and revert to SP1.
- You can’t use the integrated installation to update Windows Me or upgrade Win2K systems to SP2.
See Microsoft article Q289907 (when it becomes available) for more information about SP2. I expect that we’ll see the traditional standalone version of SP2 that upgrades existing Win2K systems within a few days. I’ll have more about what is and isn't included in this long-awaited update next week.
Upgrading NT 4.0 DC to Win2K Can Take Hours
When you upgrade from Windows NT 4.0 to Windows 2000 and the winnt32.exe program is running, NT 4.0 domain controllers (DCs) that have large SAM account databases might hang for excessive periods during the "Performing final tasks" phase of the upgrade. Under extreme circumstances, the machines might hang for up to 2.5 hours after 90 percent of the "saving settings" phase has completed. The "saving settings" phase is the final step before the Active Directory (AD) installation wizard converts the NT 4.0 SAM to AD. Eventually, the upgrade process finishes and the computer responds as it should.
NT 4.0 DCs with 50MB-to-70MB SAM account databases are the most susceptible to excessive upgrade times. When Win2K must convert many SAM accounts to AD accounts, the speed of the operation depends on the amount of available memory (e.g., physical memory, pagefile memory) and the amount of memory available in the registry.
Factors that can affect upgrade performance include not only the SAM size, but also the processor or disk subsystem performance and Registry Size Limit (RSL) settings. To improve the upgrade performance on computers that have large SAM databases, try one or more of the following techniques:
- Set the RSL to its maximum permitted value. For example, you can set the RSL to 200MB so that it adjusts to 80 percent of PagedPoolSize when the computer restarts.
- Set the pagefile size to 1.5 times the amount of physical memory.
- Add additional physical memory to the machine you’re upgrading. For an NT 4.0 PDC with a 30MB SAM, 128MB is the minimum amount of memory you should have.
- Clean up and compress the SAM on the PDC. See Method 3 in Microsoft article Q140380 for more information.
- Add a new NT 4.0 BDC to the domain, promote the BDC to a PDC, then upgrade your computer to Win2K. The newly replicated SAM file should be less fragmented than the copy on the original PDC. Any reduction in SAM size can mean less memory use and faster upgrade performance. This method is particularly suitable when you deploy new hardware with Win2K DCs.
See Microsoft article Q273823 to learn how to increase the size of the registry, size the pagefile, and compress the SAM.
A Win2K DC and NT 4.0 BDC Interoperability Problem
If you upgrade an NT 4.0 PDC to Win2K or install a Win2K DC in an NT 4.0 domain and then apply the hisecdc.inf security template to the DC, NT 4.0 BDCs can’t interoperate with the Win2K DC. The high-security DC template sets the RestrictAnonymous registry entry to a value of 2, which disables NT 4.0’s ability to communicate over a secure channel with a Win2K DC. To understand the security implications of enabling or disabling anonymous access, see Microsoft article Q246261.
When an NT 4.0 BDC can’t log on with an anonymous account, the system can’t locate the Win2K DC or synchronize the SAM database. This restriction also prevents an NT 4.0 BDC from starting the local Netlogon service, so the BDC can’t obtain a list of backup browsers. When an NT 4.0 BDC can’t perform these operations, Netlogon, the Service Control Manager, and the browser post error messages in the System event log at system startup. These messages include (but aren’t limited to) the following events:
- Event ID: 3210, Event Source: NETLOGON, Description: Failed to authenticate with \\
, an NT or Win2K domain .
- Event ID: 7023, Event Source: SERVICE CONTROL MANAGER, Description: The Netlogon service terminated with the following error: Access is denied.
- Event ID: 8032, Event Source: BROWSER, Description: The browser service has failed to retrieve the backup list too many times on transport \Device\
. The backup browser is stopping.
You can eliminate these interoperability problems by setting the RestrictAnonymous registry value to 0 on the Win2K DC that functions as the operations master. You need to make this change only on the operations master, so it’s fastest to edit the registry manually. Open the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ subkey and set the value entry restrictanonymous to 0 (restrictanonymous:REG_DWORD:0x0). Restart the Win2K DC to activate this change. For more information about these interoperability issues, see Microsoft article Q293127.
Preparing Win9x for an Upgrade to Win2k
Your initial reaction to reading this entry’s title might be to laugh. However, I needed an emergency replacement firewall for a client a couple of weeks ago, and the only available machine was an old 166MHz system running Windows 95. Desperate times call for desperate measures, so I jumped in and upgraded this old workhorse to Win2K Advanced Server. It took a great deal of foot tapping, but—amazingly—the upgrade worked and the dinosaur booted up clean. If upgrading Windows 9x to Win2K is on your to-do list, check out the preparation pointers in Microsoft article Q250297.