SQL Server SP2 Problems, Slow Open/Save Operations, EFS and Password Changes

SQL SP2 causes NAT Problems on RRAS Server
If you support a Microsoft SQL Server that also runs RRAS with Network Address Translation (NAT) or Internet Connection Sharing (ICS), be advised that SQL Service Pack 2 (SP2) sets a registry value that severely restricts the addresses the RRAS NAT driver allocates to outgoing connections. The SP2 installation script limits the TCP/IP port range to only two addresses—1433 and 1434—in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersReservedPorts registry subkey. The Windows 2000 NAT driver reads this key and limits outgoing TCP/UDP source mappings to these two addresses. If your SQL/RRAS server has this problem, internal clients that connect to the Internet through RRAS or ICS might be able to view only the text portion of a Web page, but not images or embedded objects. To eliminate this problem, delete the ReservedPorts subkey and reboot the server. For more information, see Microsoft article "NAT Clients Cannot View Web Sites After You Install SQL 2000 SP2 on an RRAS Server" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q324288.

Network Timeouts Slow Open/Save Operations
I’ve noticed this problem repeatedly on my systems. When you create persistent connections to network drives (in a logon script, in Windows Explorer, or with a net use command), you might encounter a long delay when you click the up or down arrow in the Open or Save As dialog box in Notepad or Microsoft Office applications. The delay occurs when one or more of the mapped drives aren't online or reachable on the network and when you are working offline. The length of time you must wait for the system to change the location in the Look in field at the top of the dialog box can be several minutes and is proportional to the number of mapped drives the code must query. During the delay, you don’t see the hourglass spin, and the system appears to be hung. I’ve killed Notepad and Word many times on systems with these symptoms.

Microsoft now acknowledges that a bug in how Windows 2000 queries network drives is responsible for this frustrating delay. When you click either the up or down arrow in the Look in field, the code queries each persistent network connection multiple times, and the system waits for each query to the same unavailable drive to fail before it times out the request. So, if you have only one unavailable drive, the Open/Save dialog box might not respond for 30 seconds or more; when you have multiple unavailable connections, it might take several minutes for the system to respond to the up or down arrow mouse click.

You can temporarily work around this problem by adding persistent network connections to Network Neighborhood. To permanently solve the problem, call Microsoft Product Support Services (PSS) and ask for the new version of shell32.dll with the file release date of June 3. This is a Post-Service Pack 3 (SP3) fix. For more information, see Microsoft article "The 'Look In' and 'Save As' Boxes in Common Dialog Boxes Are Slow" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q321126.

Restored Domain Controller FRS Problems
When you backup and then restore the only domain controller (DC) in a domain, the restore process doesn't restore the File Replication Service (FRS) database. Instead, the restore assumes that the restored DC should obtain the most current copy of database from another DC in the same domain. When you reboot a machine on which you have restored either the system state or the whole OS, by default FRS attempts to locate a more current replication partner to resynchronize its database. When you have only one DC, or when you have restored all the DCs in a domain, FRS on every restored machine incorrectly looks for a replication partner that doesn't exist.

The most obvious symptom of this problem is that the DC is missing the Sysvol and Netlogon shares. When FRS is unable to synchronize with an existing replication partner, it can't share Sysvol and Netlogon. You can verify a system has this problem by running the dcdiag.exe utility and asking for a Flexible Single-Master Operation (FSMO) check with the command dcdiag.exe /test:fsmocheck. If the utility can't locate the FSMO and fails with the message "Warning:DcGetDcName (GC_SERVER_REQUIRED) call failed, error 1355," FRS is incorrectly looking for a replication partner. Dcdiag can return several 1355 error messages, so be sure the error you see specifically contains the text GC_SERVER_REQUIRED.

You can workaround this problem by defining the restored DC as the FSMO by editing the registry. First, stop the FRS service, then locate the

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParameters Backup/Restore registry subkey and change the value entry Process at Startup (data type DWORD) to a hexadecimal value of D4. (The Process at Startup value entry only appears as an FRS parameter on DCs). Finish by restarting the FRS service.

You'll experience a short delay while FRS rebuilds the database using the current contents of the system volume. In a domain where you've restored all the DCs, the remaining DCs will synchronize with FRS database on the machine you designate as the FSMO. For more information, see Microsoft article "The Sysvol and Netlogon Shares Are Missing After You Restore a Domain Controller from Backup" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q316790.

Encrypted Files and Password Changes
Here’s a Catch-22 that occurs when you use encryption to secure your files. The Encrypting File System (EFS) uses your domain password to create a hash value for the encryption algorithm. Each time you save a file, the system encrypts the file using the same hash value key. To avoid unnecessary overhead, the system doesn't re-encrypt protected files when you change your password; instead it re-encrypts and saves each file as you access it using your new password. If you're not logged on to the domain on your first attempt to access files encrypted with the previous password, as for example when you store encrypted files locally, the system denies access and issues an error message. I didn’t actually reproduce this problem, so I can’t be specific about the error message you’ll see and the reference article, "You Cannot Access Protected Data After You Change Your Password," at http://support.microsoft.com/default.aspx?scid=kb;en-us;q322346, is pretty vague about the details. However, if you use EFS as a standard security measure, call Microsoft Product Support Services (PSS) for the extensive patch that eliminates this problem.