10 Resource Kit Remote Administration Tools

Work fast and smart with these Win2K and NT utilities

I'll wager that all systems administrators, and especially those who manage hundreds or thousands of remote systems, rely heavily on the Microsoft Windows 2000 Server Resource Kit or the Microsoft Windows NT Server 4.0 Resource Kit to help them do their jobs. I constantly find new and useful resource kit utilities for performing critical remote administration tasks. In fact, the resource kits contain so many helpful remote administration tools that I have trouble remembering them all. So, I've rounded up 10 of my favorite tools—5 each for Win2K and NT 4.0—that most remote administrators will find invaluable for performing their daily systems administration tasks.

I've chosen tools that I rely on heavily to administer a large Win2K-and-NT environment. I provide usage examples for each tool to give you a sense of its value and how you might use it in your environment. Although my discussion of the tools assumes that you've downloaded Microsoft Windows NT Server 4.0 Resource Kit Supplement One and Microsoft Windows NT Server 4.0 Resource Kit Supplement 4, most of the tools come with the base resource kits.

One point I want to make before I dive into the tools discussion is that the Win2K Server resource kit has raised the bar for the number of useful tools a resource kit provides. Some of these new tools work only with Win2K, but others work equally well with NT 4.0. None of the Win2K tools I mention work on NT, but other Win2K tools do. If you come across other Win2K resource kit tools that you'd like to use with NT, you might find that testing them for backward compatibility pays off.

5 Tools for Win2K
Here are the five tools I've found most useful for remotely managing Win2K systems. Many of these tools help you manage features such as the Windows Installer and Group Policy, which are new to Win2K. Some of the tools in my Win2K toolkit don't explicitly support an option to run against remote machines. However, you can use a variety of techniques to make local tools work remotely. For example, Win2K resource kit tools such as Rcmd and Rconsole let you install a remote shell capability on your Win2K devices. After you install the remote shell, you can use it to copy a tool to the remote machine and run that tool remotely.

1. Addiag. Addiag.exe is a multifaceted diagnostic tool that provides information about workstation or server applications that you've used Windows Installer technology to install. Addiag.exe also can tell you whether the current session is a Win2K Server Terminal Services (Terminal Services) session. You can instruct Addiag to return per-user or per-machine information. The tool also returns event-log entries related to Group Policy's software installation feature. Given the complexity of this Group Policy feature, Addiag is invaluable for helping you understand what's happening on a workstation that's subject to a software installation policy.

Figure 1 shows a command that generates a verbose log for a workstation that's in a Win2K domain and that uses Group Policy-based software installation. The command's /verbose:true option generates detailed output. The /user:false option generates machine-specific rather than user-specific information about the workstation. The /test option introduces a comma-delimited string of keywords that specify a set of tests. The Info test collects general information, such as the name of the workstation on which the command is running and the name and SID of the user who's logged on. The ServerApps test enumerates the applications that were installed using Group Policy. The ADHistory test queries the registry to determine the version number of the Group Policy Object (GPO) most recently applied to the machine. The MSILinks test queries the Windows Explorer shell to determine whether the installation distributed any shortcuts, and if so, which ones. The EventDump test dumps all software-related Application event-log entries, and the Check test determines whether an application that was installed on the local workstation contains all the GPO-defined components.

If you request a lot of data, and especially if you request the EventDump test and your event log contains many entries related to software installation, addiag.exe takes a while to run. I suggest that you send the command's output to a file to ensure that you don't miss anything.

You can also use Addiag to toggle several registry flags that control levels of debugging within the OS. For example, you can type

addiag /trace:MSIOn

to enable verbose logging to the msinnnn.log files. The Windows Installer application generates these log files in the %temp% folder when Windows Installer installs an application. You can type

addiag /trace:AppMgmtOn

to turn on detailed software installation logging in the Application event log. For this command to work, you need to create a registry key called HKEY_ LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionDiagnostics on the machine on which you run the command.

2. Gpresult. The gpresult.exe tool is also related to Group Policy. A poor man's version of a Resultant Set of Policies (RSoP) tool, Gpresult tells you which Group Policy settings are in effect for the user who's logged on to the machine on which you carry out the command. Gpresult also tells you which GPO nodes of functionality (e.g., security, software installation, administrative templates) the computer executes. In its most verbose mode, gpresult.exe provides more information, such as which registry entries an administrative template policy modifies and which applications a software installation policy deploys.

To run the command, simply type

gpresult

at a command line. You can add the /v option to turn on verbose mode or the /s option to use super-verbose mode. By default, gpresult.exe displays GPO information per user and per computer. The /u option instructs the tool to return only per-user information; the /c option lists only per-computer information. Figure 2 shows some sample output from gpresult.exe. Be aware that when Gpresult enumerates the groups that the user who's running the command belongs to, the utility enumerates group membership in only the domain in which the command is running. Gpresult doesn't show membership in groups outside the local domain, even though they might also affect GPO processing.

3. Inuse. Inuse.exe solves a common software distribution­related problem. Although you can update an application to a workstation while the user is logged on and running that application, the update can't replace files, such as DLL files, that are in use. Inuse takes advantage of a built-in OS feature that lets you replace in-use files after the next reboot.

Inuse.exe takes the form

inuse   /y

The /y option suppresses any confirmation prompting that inuse.exe provides. Although the file replacement doesn't occur until the next time the system is rebooted, Inuse registers the replacement operation in the registry's HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlSessionManagerPendingFile RenameOperations value. Inuse respects Windows File Protection (WFP) and doesn't replace a Microsoft-provided Win2K system file that WFP protects.

4. Moveuser. When you move user accounts to a new domain, you can have difficulty also moving the users' profiles, especially when you're moving users in remote locations across different machines where the user profile is cached. A Win2K user profile corresponds explicitly to a particular user's or group's SID. When you create a new account for the user in another domain, the user's SID changes and the user no longer has access to the user profile. A simple way to manage this problem is to use the resource kit's moveuser.exe tool. This tool has one function: It changes the security permissions on the user profile's ntuser.dat hive file to provide access to the profile from the new user account.

Moveuser's syntax is

moveuser   /c 

Moveuser.exe tells the system to reassociate the original user profile, which is cached on workstationA, to the new user account that you created on the new domain. You must create the new user account before you carry out the Moveuser command. Moveuser lets you use Win2K's user principal name (UPN) convention (e.g., [email protected]) instead of the domainuser form, if you wish.

Behind the scenes, Moveuser modifies the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT CurrentVersionProfileList registry subkey to change the SID associated with the old user profile and let the new user account access the new user profile. The /c option lets you run the command against a remote machine. The tool also modifies the ntuser.dat hive file's permissions within this profile to give the new user access to the user profile. When the user uses the new account to log on to workstationA, the user has the same user profile he or she had on the original domain.

Moveuser.exe can also move the profile for a local user account (i.e., an account defined on a workstation or member server SAM rather than on a domain). If you use the utility in this way, you need to specify the /k option to tell the tool not to delete the local account after moving its profile. Moveuser is comparable to the User State Migration Tool (USMT), but the two utilities solve slightly different problems. The USMT lets you save portions of the user and computer registry keys and restore those keys to the new machine and to a new user profile for the user.

5. Rpcdump. Many administrators rely heavily on ping to determine whether a particular server or workstation is available on the network. Ping is great for basic connectivity and network-delay checks, but it's somewhat limited. Ping uses the Internet Control Message Protocol (ICMP) to verify that a device is alive on the network. However, ping doesn't tell you whether a particular service on that device is available and listening. Another problem can occur when you try to ping a device through a security firewall, many of which block ICMP packets. If the ping is unsuccessful, you can't determine whether the firewall blocked the traffic or the remote device had a problem.

The Rpcdump utility lets you use a specific protocol to query a device and determine whether the device is listening on that protocol. Rpcdump is a great help when you're troubleshooting problems on remote systems that have become unresponsive to a particular type of request. Supported protocols include low-level network protocols, such as TCP, UDP, IPX, and SPX, as well as higher-level session and application protocols such as NetBIOS over TCP/IP (NetBT), NetBEUI, Microsoft Message Queue Services (MSMQ), and named pipes. Rpcdump can help you determine which ports a remote server is listening on and which ports let traffic cross the firewall.

The command

rpcdump /s servera /v /i  

uses the /s option to specify the remote server (i.e., servera) that I want to ping. The /v option requests verbose output, and the /i option tells Rpcdump to query all available endpoints (i.e., services) on servera. Using the /i option results in a kind of port scan on servera and tells me all ports that the server is listening on.

You can also specify protocols, such as named pipes, for Rpcdump to use. Named pipes are a Windows-specific application protocol for transmitting messages over Windows networks. The command

rpcdump /s servera /v /p ncacn_np

queries the server for the named pipes endpoints the server is listening on. In this example, the /p option replaces the /i option and tells the utility to query only the specified endpoint. The ncacn_np that follows the /p option specifies the named pipes protocol.

The /p option lets the command query only one protocol. If the protocol isn't installed on the target device, Rpcdump returns the ERROR:RpcNetworkIsProtseqValid:(The RPC protocol sequence is not supported) error message. However, if the protocol is installed but simply isn't listening on the standard port, the command runs successfully but doesn't return any endpoint information. This tool can query NT 4.0 systems as well as Win2K systems.

5 Tools for NT 4.0
Because NT 4.0 is a mature product, you can use resource kit and third-party tools to handle most of the problems you face. The resource kit tools I discuss below are those I turn to most frequently to manage a large NT 4.0 deployment.

1. Getsid. Getsid.exe is a simple tool that returns the SIDs for two user accounts that you specify and tells you whether the accounts' SIDs match. Getsid works on both local and remote machines and is valuable for comparing SIDs between local and remote machines.

When you carry out Getsid, you must provide two account names. If you want to determine the SID for only one account, the simplest solution is to specify the same account twice. The syntax for Getsid is

getsid \  \ 

I most frequently use Getsid to determine whether an NT 4.0 workstation that I've used a disk-cloning package, such as Symantec's Ghost or PowerQuest's Drive Image, to create has a unique SID. To create user-account SIDs, NT 4.0 concatenates the machine SID and a Relative Identifier (RID). For example, in the SID S-1-5-21-971243749-1317886497-1329147602-500, everything except the last set of digits (i.e., 500) is the machine SID. The final set of digits is the RID, and 500 happens to be a well-known RID that NT always assigns to the device's administrator account. When the source and target machines' SIDs are identical, all built-in accounts and many user-created accounts on the cloned machine have the same SID as the corresponding account on the source machine. And because NT uses the SID, rather than the username, to determine the user's security rights for accessing resources such as files and printers, duplicate-account SIDs on different machines can cause serious access-control problems.

To avoid these problems, cloning-software vendors developed SID-changing utilities that typically run after the cloning software runs. A SID-changing utility generates a unique machine SID on the cloned machine. Microsoft also got into the act by creating the Sysprep utility, which generates unique SIDs.

Getsid lets you verify that the SID changing you've done on a cloned workstation worked and that the clone's SID is different from the source workstation's SID. The command

getsid \workstationa administrator \workstationb administrator

compares the administrator account SIDs of two NT workstations. Figure 3 shows an example of Getsid's output.

Win2K supports the concept of a security principal having multiple SIDs, and the Win2K resource kit contains a version of Getsid. Nevertheless, the Win2K version of getsid.exe also returns only the primary SID for a given user.

2. Nltest. Nltest is a versatile tool for troubleshooting trust and machine-account problems in NT 4.0 domains. You can use it to query remote workstations and servers and even to perform some remote-configuration tasks against those devices.

Nltest queries the Netlogon service on NT workstations and servers for useful information. Netlogon is responsible for maintaining secure-channel connections between workstations and servers within a domain and between domain controllers (DCs) across trusted domains. Nltest.exe has more than 20 command-line options; I discuss only some of the more useful options.

Nltest.exe lets you query a local or remote workstation or server to determine which DC that machine uses for its secure-channel connection to the domain. The DC that a workstation uses for its secure-channel connection is the same DC that handles logons from users who log on at that workstation. A workstation's secure-channel DC can be useful information to have when you're having a problem with logons. If you know which DC handles a workstation's logon requests, you can narrow your troubleshooting to problems between the workstation and that DC.

You can use the following syntax to query a workstation's secure-channel DC:

nltest /server: /sc_query:

The /server option specifies the name of the workstation or server that you want to query, and the /sc_query option specifies that workstation's or server's domain. For example, to determine the DC that authenticates workstationA to the NewYork domain, you would type the command

nltest /server:workstationA /sc_query:NewYork

Figure 4 shows sample output for this command. The Trusted DC Name field contains the DC name that we're looking for—NYDC_5, in the sample output.

Nltest's /dcname option returns the name of a domain's PDC. Using Nltest to retrieve the PDC name is useful when you're working in an unfamiliar domain and you need to quickly determine which box is serving the PDC role. Although you can use the Server Manager administrative tool to determine the PDC, in a domain that has many servers, you'll find that using Nltest to determine the PDC is quicker and easier. The syntax is

nltest /dcname:

where is the name of the domain whose PDC you're looking for.

Finally, Nltest's /trusted_domains option returns the names of all domains that your workstation or server trusts. I periodically generate a list of trusted domains to ensure that all configured trust relationships are operational. To list the domains that domain NYDC_5 trusts, you would type the command

nltest /server:NYDC_5 /trusted_domains

Figure 5 shows a sample command and output for the /trusted_domains option.

The Win2K resource kit includes a version of Nltest. The Win2K version of the command contains additional options related to Win2K domains, such as the ability to query the Active Directory (AD) site that a particular workstation or server resides in.

3. Netdom. Netdom lets you write a script that creates a new workstation or server machine account in the domain and joins the workstation to the domain. Each of Netdom's numerous keywords supports several options and lets you perform multiple tasks. For example, the member keyword lets you add machine accounts to a domain SAM and reset secure-channel connections between domain machine accounts and the SAM. The master keyword lets you set up trust relationships between domains. Without Netdom or a similar command, you'd have difficulty using a script to join a workstation to a domain.

The following command creates a new machine account for workstation WS_1 in a domain called NewYork:

netdom /domain:NewYork member  \WS_1 /add

The member keyword tells Netdom to create a new machine account. Because this command runs Netdom against the PDC of the domain in which you create the machine account, you can run the command from any machine in the domain as long as you have the right to create machine accounts in the domain.

The member keyword's /joindomain option lets you join the machine to the domain after you create the machine account. You can run this command from anywhere in the domain, but you must be authenticated as an administrator on the workstation that you're joining to the domain. The command

netdom /domain:NewYork /user:NewYorkAdministrator /password: RE#122 member \WS_1/joindomain

joins workstation WS_1 to the NewYork domain. This command also specifies a domain administrator user account and password. You need to provide these credentials if the workstation on which you're running the Netdom command isn't part of the domain and if you're not logged on to that workstation using a domain administrative account. If you use the /joindomain option on a workstation that is a member of the domain, Netdom simply validates and resets that workstation's secure-channel connection.

To build trust relationships between NT 4.0 domains, you typically need to use User Manager for Domains once to create an entry for the master domain on the resource domain (aka trusting domain), then once more to create an entry for the resource domain on the master domain. Netdom's master option lets you combine these steps into one command.

The following command sets up a complete one-way trust relationship in which NYResource is a trusting or resource domain to the NewYork master domain:

netdom /domain:NYResource /user:NYResourceadministrator /password:R44ryt52 master NewYorknewyork /trust

The /domain option specifies the name of the resource domain. The /user and /password options specify the username and password, respectively, for an administrative user in the resource domain. The master keyword precedes the name of the master domain to which you're establishing the trust. An initial password for the trust creation follows the name of the master domain. (If you omit this password, NT provides a default password.) Finally, the /trust option tells Netdom to build a new trust. For this command to work, you must be authenticated as an administrator against the master domain.

Netdom also ships with the Support Tools on the Win2K installation CD-ROM. The Win2K version of the tool uses a different syntax than the NT 4.0 version does but provides similar functionality.

4. Sc. Sc.exe lets you query and manipulate NT services on local or remote machines. NT typically stores service configurations in the registry under the HKEY_ LOCAL_MACHINESYSTEMCurrent ControlSetServices subkey. Because NT treats device drivers as a type of service, you can use sc.exe to query and manipulate device-driver configurations. However, because device drivers are kernel-mode processes, your system can easily crash or hang if you change a device-driver configuration in an unexpected way. Figure 6 shows sample Sc commands that query the Atdisk driver and Browser service and illustrates the type of information that Sc provides.

You can use the following syntax to stop and start services, respectively:

sc \workstationA stop browsersc \workstationA start browser

To execute these commands, you need to have sufficient rights on workstationA. By default, NT 4.0 requires you to have administrative rights to stop and start services on a workstation or server.

Sc's config option provides additional useful capabilities. Suppose you want to change a particular service's start mode from automatic to manual. You can use the Control Panel Services applet to make the change, but that approach is inconvenient if you want to change many workstations in your environment. You can use the Sc command in a script to easily change the start mode on as many workstations as necessary. The command

sc \%1 config browser start= demand

changes a workstation's browser service start mode to manual. Note that the example provides the workstation's name as a replaceable parameter, %1. You can use this command in a batch file that loops through a list of workstations and replaces the %1 parameter with a workstation name at each iteration. The command tells sc.exe which service to configure (i.e., browser) and sets the start mode to demand to specify manual startup. If you don't insert a space after the equal sign and before the startup mode, the command will fail.

As with the other NT tools I discuss, the Win2K resource kit contains an updated version of sc.exe. Win2K's version of the tool includes more options for querying and manipulating services.

5. Rmtshare. I always use rmtshare.exe when I need to create a share point on a local or remote device. You would think that something as simple as creating a share would be easy to do through the Windows UI, but NT hasn't provided a nice way to accomplish this task since File Manager was in vogue.

Rmtshare lets you create shares on remote or local machines. The command

rmtshare \sauternesreskit=g:ntreskit /remark:"NT 4.0 Resource Kit" /grant everyone:read/grant administrators:"full control"

creates a share named reskit on a machine named sauternes. The new share points to the G:treskit directory on that machine. The /remark option displays a remark when the user views the available server shares (e.g., when the user carries out the Net View \sauternes command). I use the /grant option to set share permissions so that the Everyone group has Read access and the local administrators group has Full Control access.

Other Rmtshare options let you set user limits on shares, remove permissions, and even delete a share. You can also use Rmtshare to share printers:

rmtshare \sauternesBroLaser="Brother HL-1040"/printer /remark:"Brother laser printer"

This command shares a Brother laser printer on a share named BroLaser. The command contains the printer name (i.e., "Brother HL-1040") in quotation marks because the name contains spaces. The /printer option causes the server to share the printer, and the remark helps identify the printer to the user. Unfortunately, Rmtshare doesn't ship with the Win2K resource kit. However, I've found that the NT 4.0 version of the tool runs just fine on a Win2K machine.

Remotely Possible
The 10 resource kit tools I discuss here are the ones I use most often. I tried to choose utilities that are valuable for the widest range of remote-system administration troubleshooting tasks. But I would be remiss if I said that I couldn't have mentioned many others.

When you have some time, I recommend sitting down in front of a Win2K or NT 4.0 workstation and running each tool in the resource kit just to see what it does. You might find a tool that solves an intractable or persistent problem.