Reader to Reader - October 1999

[Editor's Note: Share your NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.]

Take Advantage of Nbtstat
I recently discovered how useful the Nbtstat utility is. This utility, which is on all Windows NT machines that use TCP/IP, lets you gather information about remote workstations and servers. For example, Nbtstat can give you the hardware (i.e., media access control—MAC) addresses of NT machines on different subnets, tell you who is logged on to a remote machine, and report the NetBIOS names that a remote machine is using.

NT machines generally have several NetBIOS names that they use for a variety of purposes on the network. To obtain a list of names a machine is using, type

nbtstat -A 

The output is in columnar form; the first three columns are the most useful. The first column lists names, the second column contains numeric codes associated with the names, and the third column specifies whether the names are unique or associated with a group.

The Microsoft article "NetBIOS Suffixes (16th Character of the NetBIOS Name)" at http://support.microsoft.com/ support/kb/articles/q163/4/09.asp explains what the numeric codes in the second column mean. The most important codes to know are and . The code Unique refers to the workstation's name (i.e., the name that appears in Network Neighborhood). The code Group refers to the machine's workgroup or domain.

The messenger service uses names marked . You can use the Net Send command to reach these machines. Machines often have two messenger names—one name is a workstation name, whereas the other name is for the current user. (Thus, you can send a Net Send command to the workstation name or the username.) You can usually use messenger names to determine the current user on an NT workstation because the user's name is the messenger name that doesn't match the machine's name. However, this technique isn't foolproof because users can use the Net Name command to add or delete messenger names for their current sessions. In addition, if the current username appears on multiple machines on the network (e.g., Administrator), the name doesn't appear in all the machines' name tables.

Checking messenger names of remote machines can be useful. For example, I wrote a small set of scripts that use the names that the Nbtstat utility returns to construct and maintain a Web page that shows how busy Yale's public NT labs are. These scripts work because our users rarely use Net Name to modify name tables and because machines typically have two messenger names when a user is logged on but only one name when the machine is unused.

In addition to the remote machine's name table, Nbtstat returns the hardware address of the network card using the IP address you specify after the -A switch. This option is useful for machines on remote subnets whose hardware addresses are otherwise difficult to obtain.

—Shawn Bayern
[email protected]

Startup Sequencer
My company runs Windows NT 4.0 with Service Pack 3 (SP3) and SP4. We reboot our servers weekly. We recently had problems with products starting up in an inappropriate sequence, thereby causing Dr. Watson to launch. We could usually fix the problem by manually restarting the failed service, but I wanted to find an automated solution.

I wrote a simple .cmd file and discovered three Microsoft Windows NT Server 4.0 Resource Kit utilities that helped solve the problem. The resource kit's Install/Remove Services Wizard utility (SrvInstW) creates new NT services, the Run Application Programs as Services utility (SrvAny) lets you run .cmd files as an NT service, and the Soon command builds At commands for the NT Scheduler service.

To make order of the startup chaos, I started Server Manager and set all the involved services to start manually. (On a local machine, you can use the Services applet in Control Panel.) Next, I used SrvInstW to install a service I named $StartSqncr, and I defined the service's executable path as C:treskit srvany.exe and its service startup as automatic. SrvAny requires that you edit the Registry entry for the new service. I started regedt32, highlighted the new Registry entry (i.e., HKEY_LOCAL_MACHINE/SYSTEM/ CurrentControlSet/ Services/$StartSqncr), selected Edit, Add Value, and added a REG_MULTI_SZ value named DependOnService, with the value Schedule. You must add the DependOnService value because the Startup_sqncr .cmd file uses the NT Scheduler service. I also needed to select Edit, Add Key to add a Parameters entry and add the value Application, with the value C:binstartup_sqncr.cmd. SrvAny requires the Parameters entry. (For information about SrvAny, see the resource kit document Srvany.doc.)

Finally, I created the Startup_sqncr .cmd file that Listing 1 shows. This file uses the resource kit's Soon tool to schedule Net Start commands for each service that you've configured to start manually. The file also schedules a final command to stop itself.

—Paul Bruesch
[email protected]

Mapping Drives on Win9x Clients
A colleague and I recently migrated a client's Novell NetWare 3.12 server to Windows NT 4.0. This task is usually simple, but we wanted to make the migration transparent to users.

To make the migration transparent, we needed to match all the users' new drive mappings to their existing mappings to accommodate legacy DOS applications. The NetWare logon script used a series of IF statements to determine users' group membership, then map drives accordingly. We wanted to use system policies rather than logon scripts in the new NT platform. When we tried to implement the policies, we realized that we hadn't thought of a way to handle the drive mappings. Then, we stumbled across Larry Dragich's Reader to Reader article ("Map Your Drives with Policies," March 1998), which included a system policy that seemed to solve our problem.

When we applied Larry's policy, our smiles quickly turned to frowns as we realized that the script didn't work with Windows 9x clients. We compared Win95's Registry structure with NT's structure and discovered that Larry's NT policy contains information that confuses Win95's Registry. Thus, we altered the policy to conform to Win95's Registry and System Policy Editor (SPE). Listing 2 shows the modified policy. The new policy worked flawlessly for Win95 clients, the migration was transparent, and our job was a success.

—Jason Peterson
[email protected]

EPPTP and VPN Follow-up
My company uses PPTP and VPNs for email purposes because we routinely send budget spreadsheets and other sensitive attachments. Each of our field offices uses a proxy server on a Windows NT 4.0 machine with RRAS and PPTP for secure email. Thus, I read Paula Sharick's article "PPTP Provides Secure Connectivity to Your Corporate Network" (March 1999) with interest. One thing Paula neglected to mention is that although NT can use a DUN connection and a VPN over the same line, Windows 95 can't easily accommodate this setup. I believe readers will be interested in this information because a fair number of businesses use Win95 rather than NT Workstation on the desktop as clients.

In Win95, if you initiate a DUN connection and then a VPN connection, you see two sets of modem status indicators in the task tray, and the VPN connection appears to be functional. However, you encounter problems if you try to use an email client such as Microsoft Outlook to check email via the VPN connection. Win95 tells you that the ISP connection is using the line and asks whether you'd like to hang up and use the VPN connection instead. This query implies that you must terminate the ISP connection for the VPN to work. However, even if you decline, the VPN still checks the email. Conversely, if you agree to terminate the ISP connection, the VPN connection also terminates, and nothing works.

—Gerry O'Brien
[email protected]