Daily Answers

Do you know of a way to edit the routing table during a RAS PPTP connection to a remote network? I want to set the default route back to the Internet instead of to the new PPTP connection.

To resolve your problem, simply clear the Use default gateway on remote network check box in the Advanced TCP/IP Settings dialog box (which Figure 1, page 166, shows) in the PPTP connection's Properties of the Dial-Up Networking connection entry. Clearing this check box leaves the primary connection as the default gateway, so the system passes over that connection only the traffic destined for the remote PPTP-connected network; all other traffic goes to the default gateway on the primary RAS (i.e., Internet) connection.

This solution won't work if you've established multiple subnets on the PPTP-connected network, because the system won't use the default gateway on the PPTP connection. Therefore, the traffic will be unable to reach hosts on other networks. In such a scenario, to ensure that the system properly routes traffic to subnets on the remote network, you can use the Route command to add static routes on the local host. However, for a single-subnet VPN connection, the gateway-deselection method works well.

I recently installed Microsoft Remote Installation Services (RIS) and several RIS images on one of my servers; this process automatically installed the Single Instance Store (SIS) service. However, when I looked at the volume's disk space usage, I didn't see the space savings that I was expecting. Is my SIS service broken?

You might not have waited long enough before examining SIS's results. SIS, which is similar to Windows 2000's CPU-friendly Indexing Service, runs during off-peak times when the system CPU is fairly idle. In addition, the SIS Groveler service (which performs the redundant file-checking work) runs at a slower rate in the hours immediately following its installation. The reason for this initially slow performance is that the Groveler service needs to determine how much CPU time it can use without adversely affecting system performance. Eventually, the Groveler service will catch up and consolidate duplicated files.

You can accelerate this process by forcing the Groveler service to run in a more CPU-intensive mode of operation. To do so, use the Expand command to expand the grovctrl.ex_ file (which you'll find in the Win2K Server CD-ROM's \i386 folder) to grovctrl.exe, then place the file in a folder on your server's hard disk (e.g., \%systemroot%\system32). After you expand the file, launch it from the command line by typing

grovctrl f

Doing so forces the service to run in foreground mode until its initial operation is complete. Afterward, the service automatically returns to its CPU-friendly mode, so you don't need to issue an additional command.

My company uses Computer Associates' (CA's) Inoculate IT 4.53 antivirus software. CA claims that this utility works under Windows 2000, but we're experiencing some strange behavior on our Win2K machines and Microsoft Exchange Server 5.5 machine. For example, the realtime monitor won't restart or it generates a Dr. Watson error after a signature update, and Exchange Server is mysteriously skipping certain mailboxes. Have you encountered these problems?

I've used InoculateIT extensively. The cause of your problem is that the base version of InoculateIT 4.53 is a bit long in the tooth and therefore requires a significant amount of updating to work properly (regardless of whether you're running it under Win2K or Windows NT). The realtime monitor's Dr. Watson and restart-failure problems, as well as the Exchange Server mailbox-scanning problem, are known bugs. You can find patches at CA's Web site.

I face this upgrade task so often that I've created a list of steps to update a baseline InoculateIT installation. These steps will make InoculateIT work properly under Win2K, NT Service Pack 6a (SP6a), and the InoculateIT Exchange Option (antivirus agent):

1. Install InoculateIT from the software's CD-ROM. (The software will prompt you to reboot, but rebooting isn't technically necessary.)
2. Apply driver update drvupdi.exe (dated 8/17/2000).
3. Apply patch LO78522, which replaces the ntupdx86.exe, realmon.exe, and uninstall.exe files.
4. Apply the Autodownload manager patch LO71090, which replaces the csctrlu.dll, getbbs.exe, gtbbsmgr.exe, inojobsv.exe, and inores.dll files. This patch updates the Autodownload Manager component so that the component can update virus signatures more frequently (e.g., daily, weekly) than the once-per-month limitation inherent in the base InoculateIT 4.51 product.

If you're using NT 4.0, reboot your system now. If you're installing InoculateIT and the InoculateIT Exchange Option on an Exchange Server 5.5 system, take the following additional steps:

5. Install the InoculateIT Exchange Option from the InoculateIT CD-ROM. If the installation fails and an error message states that the software requires Exchange Client 4.0 or later, you'll need to navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange registry subkey and add the Version value of type DWORD with a value of 4.0.
6. When the software prompts you, don't let the Exchange Option restart the services.
7. Navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\InoculateIT\CurrentVersion\MAIL registry subkey and add the LS_MaxMessageCount value (of type DWORD with a binary value of 65536) and the LS_MaxMailboxCount value (of type DWORD with a binary value of 2500). The first value represents the maximum number of messages that can be present in a mailbox that InoculateIT scans; if the actual number is higher than the configured value, InoculateIT skips the mailbox. (The maximum allowed value is 65536.) The second value represents the maximum number of mailboxes that can reside on the Exchange Server machine; if the configured value is exceeded, InoculateIT won't scan any mailboxes.
8. Finally, reboot the system. InoculateIT should now work properly with both Win2K and Exchange Server.

Windows NT 4.0's WINS requires the most maintenance of any component in my company's NT 4.0 network. We often must delete or restore the WINS database because of corrupted database entries that render clients unable to resolve names. We've also experienced several WINS replication problems. Will Microsoft improve WINS in a future NT service pack update, or will we have to live with this problem until we migrate to Windows 2000?

Although Microsoft's past few NT 4.0 service pack releases have improved WINS, the service still faces some major challenges. Microsoft might fix the remaining problems in a future service pack, but I'm not holding my breath.

You can fix WINS under NT 4.0, but to do so, you'll need to install Win2K. Win2K's WINS is much improved from NT 4.0's WINS—for example, Win2K's WINS is far less prone to self-corruption or replication problems. In addition, Win2K's WINS supports several new and tantalizing features, including

• synchronous and permanent replication-partner connections (e.g., immediate synchronization of WINS database changes)
• advanced record-filtering and searching capabilities
• manual tombstoning of records (i.e., deleting a record on one WINS server ensures that the record is deleted from all servers)
• multirecord deletions
• Microsoft Manage- ment Console (MMC)-based administrative interface (Figure 2 shows the Win2K WINS MMC snap-in with an open Properties sheet)

You'll also find new features on the Win2K client side, including the WINS client's ability to dynamically reregister itself with its WINS servers. Also, the Win2K WINS client provides better fault tolerance by supporting more than two WINS servers.

If your network is heavily dependent on WINS, you can simply upgrade one or more of your network's member servers to Win2K and have them replace your existing WINS servers. That way, you can maintain your present NT 4.0 network environment and still benefit from the new and improved version of WINS.

   Previous  [1]  2  Next