Open License Expiration Notification
Last week, one of my clients received a letter on Microsoft letterhead that began by asking, "Did you know that your organization has a Microsoft Open License Agreement that has expired or is about to expire?" The letter identifies a Master Agreement license number and states that the license will expire on or before December 31 of this year. For clarification, the letter points out that although the software licenses will remain valid, customers might need to purchase new licenses if they have upgraded to newer versions or installed additional copies of the software.
This letter is unnecessarily alarmist and, considering the last-minute Y2K concerns many of us are addressing, poorly timed. Further, the letter doesn’t identify the software the Master Agreement applies to, doesn’t specify the number or types of users, and doesn’t indicate whether the recipient must take corrective action. The letter simply instructs recipients to call SoftChoice for more information. When I called, SoftChoice informed me that it has no way to determine which product licenses are expiring, but that the company would be happy to sell me more licenses if and when I can determine which new ones I need.
Microsoft’s entire license program is an exercise in the fine art of obfuscation. Historically, we get licenses for free, and, over time, client access evolves into a tangled web. I’m not sure that anyone understands the license model, whether for BackOffice; Windows NT; Windows NT Server 4.0, Terminal Server Edition (TSE); or Internet Information Server (IIS). I tried searching for "software licenses" and "open license agreement" at the TechNet search page, and came up with absolutely nothing. I’m sure Microsoft has a page somewhere that describes client license options and costs, but the last time I found license information at the site, it was as clear as mud.
The next time Microsoft wants to inform its customers of license issues, I recommend the company provide enough detail so that we can follow up effectively. And Microsoft might want to send such a letter a bit earlier next time so that we have adequate time to take corrective action, instead of dealing with a potential last-minute crisis.
New Memory Leaks
- TCP services—NT 4.0 Service Pack 6 (SP6) introduced a new leak in tcpsvcs.exe that occurs when the Line Print Daemon (LPD) is heavily processing print jobs. To view this leak, start Performance Monitor and track Working Set and Private Bytes for tcpsvcs.exe. The LPD service stops responding after an undetermined amount of memory becomes occupied, and you have to restart the service to fix the problem. Microsoft has created an updated version of lpdsvc.dll that eliminates the memory leak and the LPD hang. To get the bug fix, you must call Microsoft Support and demonstrate that your system is experiencing this problem. According to article Q246541, Microsoft will include this bug fix in SP7.
- CreateRemoteThread—When the CreateRemoteThread API is unable to create a thread, it doesn’t release the handle associated with the thread and improperly returns a null handle to the calling process. Because the handle is null, the calling process can’t close it, resulting in a memory leak. If you’re programming with this API, you can detect the leak by using Performance Monitor to watch the object Handle Count for the process that calls the CreateRemoteThread API. Microsoft Support Online article Q246691 (http://support.microsoft.com/support/kb/articles/q246/6/91.asp) states that this memory leak occurs in NT 4.0, SP4 through SP6, and that Microsoft has eliminated the leak in a new version of kernel32.dll. The bug fix is available only from Microsoft Support.
Win32k.sys Blue Screen
Win32k.sys might hang and display blue screen with a Stop 0x1e message when your Windows NT system is performing at top speed. This error occurs when the system deletes the Window property while the pointer to the property list is set to Null. Microsoft Support Online article Q247240 points out that this error should occur only in a high-stress environment. Microsoft has created a bug fix that updates four critical files: win32k.sys, gdi32.dll, gser32.dll, and winsrv.dll. You must call Microsoft Support for the new files.
Internet Router Discovery Protocol Gateway Problem
If a computer you have configured to use Internet Router Discovery Protocol (IRDP) temporarily stops receiving router advertisements from a gateway, and the default gateway detection routine discovers that the gateway is invalid, Windows NT deletes the route to that gateway from the computer's route table. When the gateway becomes valid and starts sending IRDP updates to the computer, the computer does not add the newly valid route to its route table. When a system has a blank default gateway, it can’t communicate with any systems beyond the local subnet. You can restore the missing route manually or by rebooting. According to Microsoft Support Online article Q246988, this bug applies to NT 4.0, SP4 through SP6a. You can call Microsoft Support for a new version of tcpip.sys that properly restores the route.
Unattended RAS Installation Bug
Microsoft Support Online article Q246954 documents a RAS bug in unattended setup mode. When your setup file contains a RAS section that defines a static address pool, as in the example below, RAS generates an error message stating that the install failed because you specified an invalid IP address.
\[RASParamSection\] ... StaticAddressBegin = 10.0.0.1 StaticAddressEnd = 10.0.0.10 ...
This problem occurs only if the address contains a zero in the second or third octets. You can work around this bug by selecting a non-zero value for either field. You can get the bug fix, a new version of rascfg.dll, directly from Microsoft Support.
