• subscribe
December 01, 1997 12:00 AM

Reader to Reader - December 1997

Windows IT Pro
InstantDoc ID #3550

In the rush to bring up the site, I inadvertently installed several NT 3.51 workstations with the wrong time zone configured. Software distribution applications were hard to run because of this mistake. So I used KiXtart to determine which workstations had the wrong configuration. The script, which is shown in Listing 3, performs three steps:

1. Scan the Registry for the time zone.

2. Log the machine name and the time zone setting if incorrect.

3. Log all machine names to a file that will ensure that incorrect machines are logged only once.

Since fixing the time zone problem, I have successfully used KiXtart for various other projects. KiXtart is a very useful tool for administering NT networks.


Save Effort­Use a Tab
I found a neat shortcut for people who often use the command prompt. In the Registry, go to HKEY_CURRENT_USER\Software\Microsoft\Command Processor and add or modify the value CompletionChar of data type REG_DWORD with a data value of 9. The data value (9) is the ASCII value for the Tab key (but you can easily change it to any other key on the keyboard).

Now, when you enter a command, you just need to type in part of the file or directory name and then press the Tab key. Windows NT will automatically complete the file or directory name. For example, if you enter CD C:\ Prog and then press Tab, NT will complete the case directory name to CD C:\Program Files.

If more than one file or directory matches the partial name, you can browse the retrieved list by pressing Tab several times. For example, suppose you type in back and the filename C:\backup appears, but you want the file C:\backup1 instead. Just keep pressing Tab until that filename appears. This procedure is especially useful for long filenames and filenames with spaces.


Don't Lose the Online Election
I'm impressed with the way NT 4.0 handles WANs. Marine Forces Pacific and its subordinate headquarters chose NT 4.0 as the network operating system for a recent joint exercise with the Republic

of South Korea. I was part of the team that built and then tore down the large network.

The WAN topology for this two-week exercise consisted of 20 Cisco Systems routers spanning the South Korean peninsula. About 20 class-C IP networks connected the routers. With the assistance of the LMHOSTS file and Windows Internet Name Service (WINS), the team connected six NT domains and established trusts among them. Liaison officers in two remote sites were able to connect to the domain and read their Microsoft Exchange email five routers away.

But then the trouble began. The initial symptoms appeared when I was trying to access the User Manager for Domains program from my Primary Domain Controller (PDC). The error read "Cannot access this domain, unable to locate domain controller." My first reaction was immediate panic. I shut the system down and then brought it back up again. When I logged on as the administrator, I noticed that some services didn't start. The severity of my problems became clear when I looked at the Server Manager program. In a single online election, my PDC had been demoted to a workstation.

I found the reason for the crisis in the Event Viewer: Another computer had the same name as my PDC. A computer hundreds of miles away on the other side of four routers was seriously affecting my PDC.

Fortunately, earlier in the week, I had convinced a fellow technician to stand his machine up as a classified Backup Domain Controller (BDC) and to load the last copy of Exchange onto it. With that BDC, the team managed to bring up the PDC's Microsoft Exchange System Attendant and Information Store services. The team then used these services to migrate the mailboxes from the bridgehead server to the backup server. With the mailboxes intact, the team promoted the BDC to the PDC.

To bring the downed server back up, the team needed to rename it and reload the operating system to stand up another BDC. The Help desk immediately mobilized the client workstations for a quick reconfiguring of the Exchange server's new location. With the machine renamed, the team reloaded WINS and added several other WINS servers. The team then began Exchange Directory Service replication. All was well.

The team's experience illustrates that details matter when planning the architecture of multidomain WAN systems. The team failed to plan naming conventions down to the node. The team now knows that a site-unique computer name must also be WAN-unique.



ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here