Win2K and NT 4.0 Profile Issues
I spent a frustrating couple of weeks attempting to implement Windows NT 4.0 system policies and profiles on several new Windows 2000 workstations in an NT 4.0 domain. In the process, I encountered numerous roaming-profile load, modification, and update issues, which I describe below. I caused some of the problems by forgetting to set up the correct profile access permissions, but several of the problems are endemic to the way the two platforms manage local and roaming profiles.
- Win2K Doesn't Display Domain Accounts. A pre- and post-Service Pack 1 (SP1) Win2K problem crops up on servers and workstations when you attempt to copy a local profile. After you click Profile Change, the Select User or Group screen's "Look in" field incorrectly sets the filter to display only the local system’s accounts—even when you log the Win2K system on to an NT 4.0 domain with a domain account. This bug prevents you from granting a domain user permission to access a local profile. The workaround is to convert the local profile to a roaming profile and manually copy it to the target domain user's profile directory. After you copy the profile, you must also manually grant the user account the correct set of permissions on the newly created profile. Hardly fun, but manageable. According to Microsoft article Q255573, Microsoft Support has a fix that sets the account filter correctly. Ask for the new version of sysdm.cpl released April 7, 2000, nearly a year ago.
- Win2K Templates Directory Permissions. While manually copying profiles, I discovered another funny problem with the profile Templates directory. Like NT 4.0, Win2K updates roaming profiles at logoff. When I logged off a domain account, Win2K consistently reported an "access denied" error when attempting to write updates to the Templates directory. After experimenting with permissions, I discovered that Win2K requires the user account to have Full Control on the templates directory to update it properly. Other subdirectories in a user profile don't require Full Control. In fact, Win2K can update all other subdirectories of a user profile as long as the user has Read, Write, Execute, Delete (RWED) access. I couldn’t find a Microsoft article that describes this problem.
- NT 4.0 Telephony Bug Prevents Roaming Profile Update. If you use the Internet Connection Wizard (ICW) to define a new connection, a bug in the Telephony service prevents NT from updating roaming profiles. The ICW asks the Telephony service for user information, and the Telephony service incorrectly opens the HKEY_CURRENT_USER registry hive—and leaves it open long after you have defined the new connection. The hive remains open after you log off, which prevents Winlogon from accessing the user’s profile information. To work around the problem, you can stop the Telephony service. However, if you or your users need to define new connections, this workaround is clumsy at best. Microsoft Support has a bug fix for NT and NT Server 4.0, Terminal Server Edition (TSE), a new version of tapisrv.sys released in September 1999.
NT 4.0 VPN Client WINS Settings
If you run a NT 4.0 RRAS server and you support VPN connections, you probably know that you can define each VPN port as dial out, receive calls only, or dial out and receive calls. If you define more than 105 RRAS ports and you set all the ports to dial out and receive calls, the server might not assign WINS settings to incoming VPN clients correctly. You can work around this problem by defining the VPN ports as receive calls only (VPN connections are typically inbound). See Microsoft article Q289688 for more information.
NT 4.0 RAS Client Bug Fix
A bug in the NT 4.0 RAS client software rears its head when you log on to an NT system with cached credentials (meaning that the system couldn't locate an NT 4.0 domain controller—DC). If you then use the RAS client to connect (via dialup or VPN) to an NT domain for which your domain account password has expired, the RAS server doesn't let you change the expired password. Without a valid password, the RAS server can't authenticate your session and will abruptly disconnect you. To troubleshoot this issue, check the RAS server's event log for Event ID 709. This event should contain a message indicating that the password change wasn't successful. Microsoft has a bug fix for this problem, a new version of rasdlg.dll released March 9. Microsoft article Q257286 documents this problem and states that if your domain password hasn't already expired, the RAS server will let you change your password successfully.
Manually Removing PPTP from NT 4.0
Last week, I wrote about the Windows Installer CleanUp utility, an antidote for several Add/Remove problems. It can help you uninstall software so you often won't have to resort to a manual remove. Unfortunately, this utility is useless when you must add or remove native NT 4.0 protocols and services. In some cases, when you remove PPTP from an NT 4.0 server or workstation, the removal process doesn't clean up the associated registry settings (surprise, surprise). Six NT files support PPTP, and you need to delete each one to manually purge the protocol from the system:
Following is a laundry list of the registry keys you must delete to expunge all traces of PPTP from a system. You must delete six keys from the registry's SOFTWARE\Microsoft section and six keys from the registry's CurrentControlSet\Services. You’ll need to reboot the system to unload any active PPTP components.
HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\RAS\TAPI DEVICES\RASPPTPM
HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\TAPI DEVICES\RASPPTPM
HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\Windows NTCurrentVersion\NetworkCards\(x)
See Microsoft article Q288172 for more information.
No-Sound Option on NT 4.0 Generates Blue Screen at Shutdown
Here’s a rather unusual problem that might be difficult to troubleshoot. If you prefer quiet systems, NT gives you the option of setting the system's sound scheme to "no sounds." However, when a system is in silent mode, the OS still attempts to locate a sound file when it shuts down an application—which isn't a problem when you run an application locally. However, problems can arise when you run an application from a network share. When you shut down the system, the shutdown process closes all open applications. When closing an application, NT attempts to locate the file close.wav on the network drive where the application resides. When it can't locate the .wav file, the system crashes and displays a Stop code of 0x50. You can work around the problem by placing a real or phony close.wav file in the %systemroot% directory on the local machine; the file doesn't actually need to be a .wav file. Microsoft article Q281968 states that Microsoft Support has eliminated this problem in a new version of mup.sys released March 5.
NT 4.0 NetBIOS Memory Leak
NT employs NetBIOS, the chatty protocol that runs over TCP/IP, to broadcast share names, computer names, usernames, and names for local services, as well as for NetBIOS name resolution requests. Microsoft article Q284215 reports that a bug affects how NetBIOS processes a specific packet known as UdpSendNSBcast. When the system doesn't receive a response to this type of packet, the OS discards the packet without releasing the non-paged pool memory where it stores the packet. Each time this happens, the system leaks 160 bytes of memory. Over a period of time, the leak can consume all non-paged pool memory and your only recourse is to reboot. Call Microsoft support for the new version of netbt.sys that eliminates the problem. The file has a release date of Feb 12.