NT 4.0 IIS Security Hotfix
Microsoft article Q271652 details a new security hotfix that eliminates a vulnerability in Microsoft IIS 4.0. The bug affects IIS’s processing of an intentionally malformed URL, rendering the Web service unable to respond to requests for Web pages and FTP services. (The vulnerability doesn't, however, let a malicious user compromise data or administrative privileges on the server.) This vulnerability exists on Windows NT 4.0 Server and Workstation; NT Server 4.0, Terminal Server Edition (TSE); and NT Server, Enterprise Edition. Download the Intel hotfix, q271652i.exe, and the Alpha version, q271652a.exe, from the Microsoft Web site.
SMS 2.0 SP2 Bug Fix
After you upgrade your Systems Management Server (SMS) 2.0 hierarchy to Service Pack 2 (SP2), Windows 95 clients might hang during hardware inventory when a Microsoft Outlook attachment is open or when a Microsoft Office document is open in Windows Explorer. When this behavior occurs, the system logs the following error messages in the hinv32.log file:
- WARNING 1 - Failed to update new cycle info !!! Hardware Inventory Agent
7/24/2000 11:49:37 AM 4294127983 (0xFFF3316F)
- ERROR 1 - Cannot get schedule for previous cycle !! Hardware Inventory Agent
7/24/2000 11:49:37 AM 4294127983 (0xFFF3316F)
If you experience this problem, call Microsoft Support for the SMS 2.0 SP2 Intel and Alpha bug fixes. The patch contains six files: compverwbem.ini, read1st.txt, stdprov.dll, wbemsdk.exe, q269411.exe, and preinst.exe. The most recent files in the bug fix are dated August 18. Microsoft recommends that you disable hardware inventory before you apply the fix to ensure that Win95-based clients are running. See Microsoft article Q269411 for instructions about how to install the hotfix manually.
The article also indicates that you can apply two temporary workarounds. The first involves disabling hardware inventory, which might or might not be desirable. The second requires installing Distributed COM (DCOM) 1.3 and then Microsoft Windows Management Instrumentation (WMI) 1.5 on all Win95-based clients. You can deploy these products with a logon script or with an SMS 2.0 software distribution that targets all Win95-based clients.
A Browser Reference List
I receive several email messages each week from readers who have remote clients (dial-up or VPN) that can't browse the network. The browser service's primary function is to provide a list of computers that share resources in a client's domain—along with a list of other domain and workgroup names—on the LAN and across a WAN. The service provides this list to clients that display network resources using Network Neighborhood or the NET VIEW command.
The browser service maintains a list of the names in the domain or workgroup that a computer is part of. On each network segment, NT elects a master browser from the group of computers located on that segment.
The master browser is responsible for collecting host or server announcements, which each server on the same segment sends as a datagram every 12 minutes. These announcements include the server's NetBIOS name of <01><02>MSBROWSE<02><01>, <DOMAIN><1d>, or <DOMAIN><1e>, as appropriate for the server type. When the master browser receives a server announcement from a computer, it adds that computer to the browse list. The master browser then returns lists of backup browsers to computers running NT Server, NT Workstation, and Windows 9x. The master browser also instructs the potential browsers for each network segment to become backup browsers. The backup browser on a given network segment provides a browse list to the client computers located on the same segment.
In an NT domain, the PDC always functions as the domain master browser. All other domain controllers are designated as backup browsers. Additionally, NT allocates one backup browser for every 32 computers on the network segment. Backup browsers call the master browser every 15 minutes to get the latest copy of the browse list and a list of domains. Each backup browser caches these lists and returns the list of servers to clients that send a request to the backup browser. If the backup browser can't find the master browser, it forces an election.
The browser is one of NT's and Windows 9x's most temperamental components. After 8 years of hammering away at browser problems, I’m convinced that nobody really understands the gory details of how a browser operates. Now that we can have NT 4.0 and Win9x browsers in a mixed-mode Win2K domain, you have to troubleshoot even more layers when a browser runs amok or goes blind. If you’re in proactive troubleshooting mode and you’re migrating to Win2K, you might find one or more of the following references helpful.
Win2K. Microsoft article Q188001 describes how the Win2K browser service interoperates with legacy client browsers. The document also describes how a master browser operates, how a master browser merges lists of names from multiple subnets, how long it takes to register and either propagate or remove NetBIOS names browsers on a network, and how browsers resolve the names they broadcast to each other. If you read through this whole article, you’ll see it can take a backup browser up to 12 minutes to determine that no master browser is on the network.
Win2K and NT. Microsoft article Q136712 presents common questions and answers about how a browser operates in both platforms.
- Chapter 3 of the Microsoft Windows NT Server 4.0 Resource Kit.
The Microsoft Windows NT Browser White Paper provides a serious level of detail about NT browser operation, including the network packets each system sends, how browsers hold elections, how NT manages a browser failure, and the number and type of NetBIOS names each system registers.
Win95. Chapter 11 of the Microsoft Windows 95 Resource Kit—although I avoid Win9x like the plague. (I assume information in this document also applies to Windows 98.)