I'm noticing incompatibilities between Microsoft Internet Explorer (IE) 5.01 Service Pack 1 (SP1) and Microsoft Office 2000's Help features. Users who attempt to access Help features within Office receive the error message Help requires Microsoft Internet Explorer 3.0 or greater. Can you help me solve this problem?
The problem occurs because IE 5.01 SP1 writes invalid build and version number information to the system Registry. Programs that leverage IE (e.g., Office's Help system) use this information to determine whether you have a supported IE version installed on your system. Because IE sets the value incorrectly, applications think that the IE version is too old and therefore issue an error message.
The Registry value that determines the IE build number resides within the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer Registry subkey. The value name within this key is Build (of type REG_SZ). On an IE 5.01 SP1 machine that exhibits the problems you describe, this value is probably set incorrectly to 5.00.3103 .1000. To restore functionality to Office's Help features, change the value to the correct number, 53103.1000.
I recently set up a dual-boot system with Windows 2000 Professional and Windows NT Workstation 4.0 on one C drive. (I use NT 4.0 as my primary OS on this system.) Although both OSs work fine, I'm forced to reboot to Win2K if I need to run Chkdsk on the C drive. Can I force NT 4.0 to run Win2K's NTFS 5.0- compatible version of Chkdsk?
The Win2K installation process automatically converts any NTFS 4.0 volumes (i.e., created under NT 4.0) to NTFS 5.0. Although NT Service Pack 4 (SP4) and later support most reading, writing, and booting functionality from NTFS 5.0 volumes, they can't repair them (i.e., with Chkdsk). Although you can't force NT 4.0 to run Win2K's version of Chkdsk, Systems Internals has a utility called NTFSCHK that lets you run Chkdsk on NTFS 5.0 volumes from NT 4.0. For more information about this utility, go to http://www.sys internals.com/ntfschk.htm.
While upgrading my company's PDC to Windows 2000, I received the error message Cannot find valid system partition. Other than this message, the installation completed successfully—no booting problems or errors in the event logs. Have you seen this problem before?
I've seen this problem once before. Determine whether the drive in question—the drive containing the Windows NT boot partition, not necessarily the boot partition itself—contains a partition that is running some form of Windows 9x compression (e.g., a multiboot system that has a Win9x partition with compression). If so, you need to remove compression from all partitions on the drive and retry the Win2K installation.
Your problem has another possible cause. The driver that Win2K uses (according to hardware autodetection) during installation might not be working properly because of a difference in the translation of your drive's geometry between the Win2K and NT 4.0 disk-controller drivers. If this is the case, see whether your disk-controller manufacturer—in most IDE controllers, the motherboard or IDE chipset manufacturer—offers an updated Win2K driver that is more recent than the driver that ships with Win2K. If you obtain an updated driver, try using the F6 option (i.e., load a custom or updated driver) at the beginning of the Win2K Setup process to install this driver in lieu of the default driver that Setup uses.
In my experience, PPTP doesn't work in the UK when you use a firewall. I've heard that the reason for this incompatibility is because Microsoft ships different versions of its OSs to different countries. Can I work around this problem, or must I continue to use IP Security (IPSec) for VPNs in the UK?
Microsoft maintains 128-bit and 40-bit versions of PPTP and the company's other encryption-based technologies and products. However, I don't think these differing versions are the cause of your problem. PPTP, regardless of the version, should work through a properly configured firewall. The trick is to make sure that you've configured the firewall to pass IP protocol type 47 Generic Routing Encapsulation (GRE) packets as well as TCP port 1723. After you configure the firewall to allow this type of traffic to your PPTP RAS servers, you should be able to successfully connect to the servers through remote PPTP clients.
You might want to consider continuing to use IPSec, either in conjunction with or instead of PPTP. IPSec is a Layer 3-based encryption technology, whereas PPTP is a Layer 2-based technology. IPSec is therefore faster and more efficient than PPTP for VPNs. Using IPSec-based VPN products, I've been able to achieve performance improvements of 100 percent or more over PPTP.
Microsoft also builds IPSec support into Windows 2000, making IPSec an attractive PPTP alternative for companies that have already migrated to Win2K. Although IPSec doesn't support protocols beyond TCP/IP—PPTP supports TCP/IP, NetBEUI, IPX, and SPX—this lack of support isn't a problem on most networks.
Although IPSec still faces interoperability challenges between different vendors' implementations, these problems should disappear in the near future as the standard evolves. In the meantime, the best bet for using IPSec is to use one vendor's implementation on both ends of the connection (i.e., the client and the server) wherever possible.
I've heard rumors about a Windows 2000 Registry setting that lets you use a special keystroke to intentionally crash your system. As a developer, I would find such a capability extremely useful for evaluating the effects of a system crash. Does this capability exist?
The rumors are true. To enable this modification, run a Registry editor and navigate to the HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSetServices\i8042prt\Parameters Registry key. You'll need to create a Registry value called CrashOnCtrlScroll (of type REG_DWORD) and set the value to 1. (Figure 1 shows this value and Registry location.) After you make the modification, you must reboot your system.
Then, you can manually initiate a blue screen crash by holding down the right Ctrl key—the left Ctrl key won't work—and pressing the Scroll Lock
key twice. The system will produce a blue screen that contains the following
message:
*** STOP: 0x000000E2
(0x00000000,0x00000000,0x00000000,0x00000000)
The end-user manually generated the crashdump.
Obviously, this modification is inherently dangerous because it performs an abnormal system shutdown. The system crash that this tool produces might cause Registry or file-system corruption, so use extreme caution when initiating this behavior. In addition, consider using it on test systems rather than production systems. At the very least, be sure to exit all applications and stop as many services as possible before you produce the blue screen.
I'm experiencing a problem with my Windows NT Server 4.0 Service Pack 5 (SP5) system. I'm connecting by modem from a Windows 98 client linked to the NT server by RAS. I have administrative access to the server for performing such tasks as viewing or managing drives (e.g., C, D), but I need to be able to reboot the server from my client. Unfortunately, the server contains no tools such as Symantec's pcAnywhere or Compaq's Carbon Copy. Any ideas?
Unfortunately, because of Win9x limitations—and because of inherent differences between the architectures of Win9x and Windows 2000 or NT systems—you can't use built-in tools under Win9x to reboot a remote Win2K or NT system. I searched for a utility that would let you dynamically install such a tool on the remote server, but I found nothing. Therefore, I recommend installing Win2K or NT on your workstation. Then, you can use tools such
as the GUI-based shutgui.exe or the
command-line-based shutdown.exe to remotely reboot the server.
To facilitate future management of a remote server from non-Win2K and non-NT clients (including shutting down or rebooting), you might consider third-party tools such as 3am Laboratories' RemotelyAnywhere, puresoftware.com's remoteControlPanel, RL Morgan's RS Agent, and TND Industries' Remote-Anything. (For an extensive list of third-party tools, go to the Windows 95/98 Remote Computing Tools page at http://winfiles.cnet.com/
apps/98/remote.html.) Although these tools require you to first install a server-side component, most of them are fairly inexpensive—or free, in some cases.