The document discusses 10 remote administration tools from the Microsoft Windows 2000 and NT Server resource kits that are useful for managing remote systems. It provides descriptions of 5 tools for Windows 2000, including Addiag for diagnosing software installations, Gpresult for viewing Group Policy settings, Inuse for replacing in-use files, Moveuser for moving user profiles between domains, and Rpcdump for checking availability of network protocols. It also describes 5 useful tools for NT 4.0, such as Getsid for comparing security IDs, and Nltest for troubleshooting trusts and domain controllers.

1. 10 Resource Kit Remote Administration Tools
Advertisement
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

2. 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

3. 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 distributionrelated 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 <newfile.dll> <oldfile.dll> /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 <olddomainolduser> <newdomainnewuser> /c
<workstationA>
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., user@mydomain.tld) instead of the domainuser
form, if you wish.
Behind the scenes, Moveuser modifies the
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT CurrentVersionProfileList

4. 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

5. 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 <machine1> <account1> <machine2> <account2>
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

6. 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:<workstation name> /sc_query:<domain name>
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

7. nltest /dcname:<domain name>
where <domain name> 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

8. 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 NewYork
newyork /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 browser
sc 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.

9. 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:ntreskit 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

10. 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.