A DNS Coexistence Solution

Windows 2000 and Windows NT 4.0 DNS Coexistence
Last week, I wrote about my experiences with Windows 2000 (Win2K) and Windows NT 4.0 coexistence and mentioned that I had to stop and restart my NT 4.0 DNS servers every time I booted a Win2K server. (This problem didn’t occur on Win2K systems I configured as domain controllers.) If you're testing a mixed environment, the symptoms of this problem include a blank domain name field in the top portion of the Ipconfig/all display and an error from Nslookup stating that the DNS server is unknown. An enterprising reader in Saudi Arabia passed on Microsoft’s solution for eliminating the NT 4.0 DNS stop-and-restart step.

When you set up standalone Win2K servers as members of an NT 4.0 domain, you must manually enter the primary DNS suffix for the server. You can define the DNS suffix (e.g., win2000mag.com) during installation or any time after you get the server running (as long as you haven’t also installed and configured Certificate Authority—CA—in standalone or enterprise mode). Open My Computer, Properties, Network Identification, Properties, More, and enter the DNS suffix information. Reboot the server. Run Ipconfig and verify that the DNS name appears as you entered it, then try Nslookup again. On my systems, this adjustment made NT 4.0 DNS work properly. I only wonder why Win2K doesn’t automatically enter the DNS name when you install a standalone server—the OS does enter the DNS suffix field when you install a Win2K domain controller running Active Directory (AD).

Rdisk Security Fix
On January 2, Microsoft released an update for the emergency repair utility Rdisk that eliminates a vulnerability that occurs when Rdisk terminates abnormally. If Rdisk fails when you’re updating Registry information (e.g., creating repair files), the utility leaves behind a temporary disk file containing all the Registry hives with their current settings. The temporary file permissions are wide open, so anyone can read from or write to the file. The Rdisk vulnerability exists in Windows NT 4.0, Terminal Server Edition (WTS) and NT 4.0. You must call Microsoft Support to get the update.

In the unlikely event that Rdisk fails before you install the updated version of rdisk.exe, you can eliminate the security hole by deleting the temporary file after you restart the system. See Microsoft Support Online article Q249108 for details.

Batch Job Access Violation
Do you run batch jobs that contain a for/f construct? If so, your batch job might terminate with either an access violation or an access denied error message. The errors result from the way the console program reuses memory. In some cases, memory locations return to the console program without zeroing first, which causes your batch job to encounter unexpected data. According to Microsoft Support Online article Q250998, the algorithm that cmd.exe uses to extract tokens that pass as parameters in the for/f command is vulnerable to reused memory—poor programming, to say the least. Microsoft released a new version of cmd.exe on January 25, and you must call Microsoft Support to get the update.

Knowledge Base Not Updated
I like to check the text version of the Windows NT Knowledge Base each week for new entries. Sadly, Microsoft hasn’t updated the text version in a timely fashion for a couple of months. The text database is the only one that includes a cumulative index, and there are no new entries since January 21. I reviewed the daily updates to the Windows NT Knowledge Base and found more articles regurgitating old information dating back to 1998 than new articles, so it’s not clear what’s really going on. The alternative, examining daily postings, is arduous and time-consuming compared to downloading a current index file and selected articles. If Microsoft plans to retire the text version, it should let us know where we can obtain the equivalent information, specifically a daily or a weekly index of what has changed and a downloadable text version of the articles.

Troubleshooting User Profile Problems
One task you face when reorganizing your NT 4.0 networks is moving user profiles from one server to another. When you test the new environment, you log on as a user with mandatory or roaming profiles, and you’ll often experience profile-load problems. When NT Workstation can’t load a user profile, you’ll see UserEnv Event Id 1000 errors in the Application Event Log (AEL). Microsoft Support Online article Q185198 is a good reference for troubleshooting such a problem. The article documents many profile-specific event log messages and provides suggestions for correcting profile access errors. According to the article, three common causes prevent NT from loading a profile:

Profiles also fail to load when the Registry database exceeds the Registry size-limit parameter. You can check the Registry’s current and maximum size and the maximum configured size by clicking the Virtual Memory button under Properties in My Computer. Microsoft Support Online article Q189119 documents how Registry size-limit settings affect profile loading for NT and Win2K.

SAM Sizing Guidelines
Do you ever wonder how big your SAM database would be with 3000 or 60,000 users? If so, check out the table in Microsoft Support Online article Q130914. You’ll find size guidelines based on number of users for the SAM, the Registry, paged pool, physical memory, and primary pagefile. The article recommends single CPU systems for 3000 to 30,000 users and SMP systems to support 30,000 to 60,000 users. I was pleased to see that the pagefile size guidelines match my recommendations, which is at least double the amount of physical memory. The second part of the article, while somewhat dated, describes techniques you can use to proactively monitor consumption of these key resources to avoid performance bottlenecks.