Profile Issues; VPN Client WINS Settings; A RAS Bug Fix

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.

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:

System32raspptpc.dllSystem32raspptpl.dllSystem32Driversraspptpe.sysSystem32Driversraspptpf.sysSystem32Driversraspptpm.sysSystem32Driversraspptpu.sys

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 SOFTWAREMicrosoft section and six keys from the registry's CurrentControlSetServices. You’ll need to reboot the system to unload any active PPTP components.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNdisWan(x)HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesNetBTAdaptersNdisWan(x)HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesRASPPTPEHKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesRASPPTPFHKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesRASPPTPMHKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesRASPPTPM(x)HKEY_LOCAL_MACHINE SOFTWAREMicrosoftRASTAPI DEVICESRASPPTPMHKEY_LOCAL_MACHINE SOFTWAREMicrosoftRASPPTPHKEY_LOCAL_MACHINE SOFTWAREMicrosoftRASPPTPEHKEY_LOCAL_MACHINE SOFTWAREMicrosoftRASPPTPMHKEY_LOCAL_MACHINE SOFTWAREMicrosoftTAPI DEVICESRASPPTPMHKEY_LOCAL_MACHINE SOFTWAREMicrosoftWindows NTCurrentVersionNetworkCards(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.