IE Online Error-Reporting Utility
Microsoft, apparently very interested in the public’s experience with Internet Explorer (IE) failures, has put a new online mechanism in place that lets you report irrecoverable errors such as General Protection Faults (GPFs) and invalid page faults. To use the online reporting procedure, download and install the IE error-reporting utility from the Microsoft Windows Update Web site. Microsoft article Q276550 indicates that the utility, iedw.exe, updates three IE components— dwintl.dll, dw.exe, and Iexplore.exe— and that it's compatible with IE 5.0 or later.
Once installed, the error-reporting tool presents a screen with the error message, "Microsoft Internet Explorer has encountered a problem and needs to close. We are sorry for the inconvenience" whenever IE fails. You can select options on the screen to restart IE and send error data to Microsoft. When you send the error data, the utility determines whether your problem is a known problem with a known solution. If a patch or a workaround exists, the utility directs you to a Web site from which you can download the fix. Otherwise, you receive notification that Microsoft will analyze the fault data and identify and perhaps correct the problem. What an appropriate follow-up to last week's discussion about IE page faults!
IE 5.5 Might Corrupt the Control Panel Add/Remove Programs Applet
Here’s another major headache. In unspecified situations that arise after you install IE 5.5 on a Windows 2000 system, the Control Panel Add/Remove Programs applet might hang or become corrupt. Of course, without this applet, you can no longer install or remove most add-on utilities and applications. Microsoft article Q265829 indicates that this is a known problem without a fix. To work around the problem, Microsoft recommends that you reinstall IE 5.5. Although I haven’t experienced this problem myself, I assume, based on the recommended workaround, that we can reinstall the latest and greatest version of IE without the Add/Remove Programs applet.
Win2K TCP/IP Firewall Bug Fix
Microsoft article Q264794 indicates that you might receive a Stop error message in tcpip.sys if you have firewall, proxy, or similar software installed on your Win2K system. The problem occurs when Win2K frees a bad raw IP packet and software installed on the computer references the offending packet. Microsoft released a new version of tcpip.sys October 23 that eliminates this problem; you must get the fix directly from Microsoft Support.
Win2K and NT 4.0 Firewall Port Requirements
Are you adding Win2K domains to your network? If so, your firewall must enable specific TCP/UDP ports to establish a trust between Win2K and Windows NT 4.0 domains, Lightweight Directory Access Protocol (LDAP) ports to create trusts between Win2K domains, and TCP/UDP ports to propagate DNS name resolution and WINS replication data. Microsoft article Q179442 (http://support.microsoft.com/support/kb/articles/Q179/4/42.asp) documents firewall port requirements for each of these operations. You can find a complete listing of the ports various Win2K and NT 4.0 services use in the file services.txt, which you can find in Winnt\System32\Drivers\Etc.
For Win2K-NT 4.0 trusts, use standard firewall ports to establish a trust relationship:
- PORT 135 (TCP or UDP) for the remote procedure call (RPC) service
- PORT 137 (UDP) for NetBIOS name service
- PORT 138 (UDP) for NetBIOS datagram (Browsing)
- PORT 139 (TCP) for NetBIOS session (NET USE)
- ALL PORTS above 1024 for RPC communication
Win2K-Win2K trusts require several additional LDAP ports for Active Directory (AD)-specific communication:
- LDAP_PORT 389
- LDAP SSL 636
- LDAP GC PORT 3268
- LDAP SSL GC PORt 3269
- KERBEROS 88
To successfully propagate DNS zone transfers and DNS name resolution requests during DNS and WINS replication, you must enable Port 53 (TCP and UDP). To ensure that WINS database replication traffic passes through a firewall, you must enable Port 42 (TCP and UDP).
When you establish a trust with a PPTP VPN connection, you must enable TCP Port 1723 and IP Protocol 47 (Generic Routing Encapsulation protocol— GRE).
When you run a mixed-mode domain with a Win2K domain controller (DC) and one or more NT 4.0 BDCs, you can use NT 4.0's Server Manager to initiate a domain-wide account database synchronization. If you synchronize the domain with an old version of Server Manager, Active Directory (AD) replication might not work.
Microsoft article Q249140 indicates that the replication failure occurs because the synchronization request that the old NT 4.0 version of Server Manager generates triggers a computer account password reset operation. After the computer account password changes, the PDC can't establish a secure replication channel between itself and its partner DCs. To avoid replication failures, install the new version of Server Manager. The new Server Manager checks to see whether the PDC is a Win2K DC. If it is, the new version doesn't trigger a password reset operation. Call Microsoft Support for the new version of srvmgr.exe released in December 1999.
If you think your systems aren't synchronizing properly, you can diagnose replication failures in your mixed-mode domain with the Resource Kit utility replmon.exe. The utility tests replication on each DC and reports systems that fail. Replication failures also cause errors in the Internet Service Manager (ISM) service— when replication fails, the service might not start and might display an SEC_E_LOGON_DENIED error code.