SP5 System Crash Not Recorded with Insufficient Dump File Space
Most administrators configure their systems to automatically generate a dump file after a system crash. Savedump.exe is the module that writes the dump file, which by default is stored as %systemroot%\memory.dmp. When you do not have enough free disk space on the system disk for a dump file, Savedump does not record a system crash in the system event log, and a crash can go unnoticed. The obvious workaround is to ensure you have adequate free space on the disk containing the dump file. You need at least the amount of physical memory plus a couple of megabytes. To ensure good performance, system administrators should keep a minimum of 25 percent of a disk’s storage free at all times, and inadequate dump file space on the system disk should never happen. This problem, documented in Microsoft Support Online article Q235999 (http://support. microsoft.com/ support/kb/articles/ q235/9/99.ASP), applies specifically to Service Pack 5 (SP5). Call Microsoft Support for the new Savedump.exe, released on June 23, 1999.

Checked Version of Service Pack 5 Hangs NT
An incorrectly set flag in a file read by the graphics device interface (GDI) code of the checked version of Service Pack 5 (SP5) causes the checked version of SP5 to hang, even when properly installed on a checked build of Windows NT 4.0. According to Microsoft Support Online article Q236466 (http:// support. microsoft.com/ support/kb/ articles/q236/ 4/66.ASP), the workaround is to reboot the system and the article does not mention a bug fix for this problem.

The checked versions of NT and service packs are intended for developers who need to debug code. Microsoft distributes the checked builds of the OS and updates to Microsoft Developers Network (MSDN) subscribers. You can also download the checked version of SP5 at http://www.microsoft.com/ ntserver/nts/ downloads/recommended/ sp5/sp5build/ default.asp. This page does not identify the release date for the SP5 checked version, but I’m guessing the update will be posted at this URL when it is available.

BDC Promotion Fails with Checked Version of SP4 and SP5
There’s more trouble with the checked builds of both Service Pack 4 (SP4) and SP5, specifically when you promote a BDC to a PDC in Server Manager. The problem occurs when both the PDC and BDC are running a checked build of the same service pack. Microsoft Support Online article Q238062 (http://support. microsoft.com/support/ kb/articles/Q238/0/ 62.ASP) indicates that the promotion can fail and the BDC can generate a crash dump of kernel files. Microsoft Support has a bug fix for this problem—an updated version of netlogon.dll with a release date of June 30, 1999.

TCP/IP Multicast Packets Confuse Multimedia Apps
A bug in TCP/IP causes Windows NT to send multicast packets with a Time-to-Live (TTL) of zero over the network; the packets are supposed to be used only for internal TCP/IP and inter-process communication. According to Microsoft Support Online article Q234980 (http://support. microsoft.com/ support/kb/articles/ q234/9/80.ASP), packets with a TTL of zero can cause problems with multimedia tools that use this same mechanism for testing and for autodiscovery of components on a multimedia conferencing bus. The bug fix, available from Microsoft Support, applies to all versions of NT, independent of service-pack level. The bug fix updates two files, ndis.sys and tcpip.sys.

German Windows NT Profile Quota Bug
Service Pack 4 (SP4) includes a Profile Quota tool that restricts the amount of disk space a user’s profile can consume. When the user profile exceeds the quota, an error message tells the user to delete items and free up space. However, in the German version of Windows NT, the error message continues to appear after the user has reduced the profile to below the quota setting size. According to Microsoft Support Online article Q238174 (http://support. microsoft.com/ support/kb/ articles/Q238/ 1/74.ASP), the problem is caused by a localized string that is too long (whatever that means). If this applies to you, call Microsoft Support for the proquota.exe bug fix, which Microsoft released on July 22, 1999. This bug fix applies specifically to German versions of NT running SP4 or SP5.

Replicating Large Groups Efficiently
Article Q238191 (http://support. microsoft.com/ support/kb/ articles/Q238/1/91.ASP) offers tips on how best to manage replication when you change groups of 1000 or more members. To minimize unnecessary replication, when you change large groups you should make all changes on the PDC in one sitting and then force a synchronization with the BDCs. You can initiate SAM synchronization several ways: Server Manager, the Net Account/synch command, Nltest/sync from the Windows NT Resource Kit tool (NL stands for NetLogon), and DomSynch, a third-party utility from Greyware (http://www.greyware.com).

When you add or remove a member in a large group, the PDC records the SID of the group, a serial number, and other update information in the file netlogon.chg. If you don’t manually initiate a synchronization from the PDC to the BDCs, synchronization occurs automatically after a default period, usually 15 minutes. You can adjust the default period and the amount of data transmitted up or down by changing the associated Netlogon Registry value entries. These entries are documented in Microsoft Support Online article Q207552 (http://support.microsoft. com/support/ kb/articles/q207/5/ 52.ASP).

During synchronization, the PDC sends the entire contents of the group to the requesting BDC, even though only one member has been added or removed. According to the Microsoft Support Online article, when you change a group that has 1000 members, the PDC sends approximately 8KB of group-specific data to the BDC. The important point is that when you add 100 new members in one sitting, domain controllers require only one or two rounds of synchronization to update their account databases.

When you add new members to large groups throughout the day or over several days, you force the PDC to send the group data multiple times. In a worst-case scenario, the PDC may replicate 100 times, transmitting 8KB to each BDC. If you have 30 BDCs, the PDC will transmit this data 30 times, 8KB x 100 x 30, for a total of 24MB of SAM changes. These large and repeated synchronizations cause very long replication times and can peg the PDC’s CPU utilization at 100 percent. When you organize changes and apply them serially, you’ll save network bandwidth and keep the PDC’s performance snappy.