Get IT Done: Powerful scripting commands in the Windows NT Resource Kit

Scripting commands available in Microsoft Windows NT

In “Scripting with the NT Resource Kit, part 3: Commands for local and remote services,” I discussed some commands that performed the same tasks as the commands that I described in “Scripting with the NT Resource Kit, part 1: The essentials” and “Scripting with the NT Resource Kit, part 2: More simple commands.” However, the commands in part 3 acted on both remote and local servers. I also covered a couple of the less demanding commands in the Windows NT Resource Kit. This week, I’ll take a look at some complicated and powerful commands that will allow you to carry out tasks in a script that you previously could perform only in the GUI applications of the Administrator menu. Netdom manages the domain. Nltest performs network administrative tasks. Autologon, which helps you get your scripts to logon automatically, isn’t a command but a how-to.

This utility enables administrators to manage domains from the command line. I won’t describe all of the commands and options that are associated with Netdom—just the ones that may prove useful in script writing. With Netdom, you can:
  • Join a domain.
  • Manage computer accounts for members (by adding, deleting, listing, and querying members).
  • Manage computer accounts for BDCs (by adding, deleting, listing, and querying BDCs).
  • Reset BDC secure channels.
  • Establish trust relationships.
  • Manage resource-domain computer accounts (by adding, deleting, listing, and querying resource domains).
In order for Netdom to work, the PDC for any domain that you’re targeting must be accessible.
Managing computer accounts is useful for building a list of servers before you run automated administration tasks. Netdom has one command for BDCs and another command for Member servers. To create a list of all of the servers in a domain, you need to issue the following two Netdom commands:
netdom /Noverbose /Domain:DomainName Member > server.lst
netdom /Noverbose /Domain:DomainName bdc >> server.lst
The above commands will produce a text file with contents similar to this:
\\BDC2The BDC list doesn’t include the PDC.
Joining a domain is useful when you’re writing an auto-installation script to bring a new server online. If you want to automate the task, you need to add the computer account for that server and then join the domain. To add a member server to the domain, use the following code:
netdom {/Domain:DomainName} {/User:AdminAccount} {/Password:AdminPassword} Member ComputerName /Add

netdom {/Domain:DomainName} {/User:AdminAccount} {/Password:AdminPassword} Member ComputerName /Joindomain
If you’re replacing a member server with a new server of the same name, you’ll need to delete the computer account of the original from the domain because the SID will be different. To do so, run the following:
netdom {/Domain:DomainName} {/User:AdminAccount} {/Password:AdminPassword} Member ComputerName /Delete
If you’re adding a server to the domain that you’re logged onto, you can omit the /Domain: option. If you’ve already logged on with an account that has administrator privileges in the domain that you’re targeting, you won’t need to worry about the /User: and /Password: options.

If you’re adding a BDC to a domain in which you don’t need the /Joindomain line, the server will join the domain automatically when the BDC is added. However, you’ll probably have to reset the secure channel.

Resetting the secure channel is useful when you’re bringing a server back online and the server hasn’t been connected to the domain for a long time. With a member server, /Joindomain will reset the secure channel. For the BDC, use the following code:
netdom {/Domain:DomainName} {/User:AdminAccount} {/Password:AdminPassword} BDC ComputerName /Reset
This command-line tool performs such network administrative tasks as:
  • Getting a list of primary domain controllers (PDCs).
  • Forcing a shutdown.
  • Querying and checking on the status of trust.
  • Testing trust relationships and the state of domain controller (DC) replication in a Windows domain.
  • Forcing a user-account database into sync on Windows NT 4.0 or 3.x DCs.

Trust describes a relationship between two Windows domains. Each domain in the relationship can become either the trusting domain or the trusted domain. For any given trust relationship, there’s a single discreet communication channel between each domain controller in the trusting domain and a domain controller in the trusted domain.

For example, if Domain A trusts Domain B, then B is the trusted domain, and A is the trusting domain. This is an example of a one-way trust. However, if Domain B also trusts Domain A, then they enter what’s called the Complete Trust mode (a two-way trust). In secure channel terms, it’s best to think of them as two separate secure channels (between each domain controller in the trusting domain and a domain controller in the trusted domain).

Trust relationships are not transitive. If Domain A trusts Domain B, which in turn trusts Domain C, Domain A doesn’t necessarily trust Domain C. The administrator in each domain must grant explicit permission on either side of the trust relationship for the relationship to begin.

Another form of trust relationship is sometimes referred to as an implicit trust. In a single domain model or in an environment where there are no explicit trust relationships between any two domains, the implicit trust relationship is functionally needed and active. This implicit trust exists between each Windows computer that’s a member of a domain and a domain controller in that domain. Explicit trust relationships are established through User Manager For Domains. Implicit trust relationships are established when a Windows computer becomes a member of a domain.

Nltest can be used to test the trust relationship between a Windows machine that’s a member of a domain and the domain controller where the Windows computer’s machine account resides. Nltest can verify the trust between any BDC in a domain and its PDC. In domains where an explicit trust has been defined, Nltest can test the trust relationship that exists between all domain controllers in the trusting domain and a domain controller in the trusted domain.

These sessions of communication are called secure channels. They’re used to authenticate Windows machine accounts and to authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. The second type of authentication is a pass-through authentication; it allows a Windows machine that has joined a domain to gain access to the User Account Database in its domain and in any trusted domains. All of these trust relationships (along with domain synchronization) can be monitored, tested, and verified by Nltest.

Nltest offers a plethora of options, but I’ll limit my introduction to this command to some of the more useful options. Nltest can be used similarly to Netdom; Nltest can obtain a list of domain controllers, including the PDC, in a given domain—like so:
nltest /Dclist:DomainNameUnlike Netdom, Nltest gets its information from a browser server. Therefore, it will fail if it can’t find a browser server.
Like Netdom, Nltest can be used to reset the secure channel on a server:
nltest /SC_RESET:DomainName /SERVER:Servername
Nltest also can check to see if the secure channel needs to be reset:
nltest /SC_QUERY:DomainName /SERVER:Servername
Other useful options are shown in Table A.

Table A
/REPL Forces a partial synchronisation of the local or specified BDC.
/SYNC Forces a full, immediate synchronisation of the local or specified BDC.
/QUERY Queries the local or specified server for a healthy secure channel to a Domain Controller;
queries the status of the directory services replication with the PDC.

Autologon isn’t really a command. I’ve included it here to demonstrate how you can use scripts in order to have non-admin personnel carry out administrator tasks. You won’t compromise security by giving out an admin password, by creating a special account that you must delete later, or by forcing an administrator to log on for these non-admin employees and then leaving them on their own. Here’s the code segment that will allow your scripts to log on automatically:
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon=1"

reg update "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName=FROST"
reg update "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName=AdminAccount"

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword=AdminPassword"
Add is used with some of the above registry values because update won’t work if the key or value name doesn’t exist already. However, add will fail if the key or value name already exists. So, unless you’re sure whether or not the key or value name exists, you’ll have to test for its existence. To do so, run:
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword=AdminPassword" ŠŠ reg update "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword=AdminPassword"
The logic of this test allows the reverse test to work, too (e.g., update first; if that fails, then add).

Using this feature, the engineer can log in normally, run the script with the above code, sit back and make sure that there are no errors, and (if necessary) respond to prompts. To activate the Autologon, however, the system must be logged off; it will log back on automatically with the account information that’s supplied in the above code. How do you continue the script once the system logs back on? To switch off Autologon, update the AutoLogon value to 0.

Continuing scripts across logoff/logon
To ensure that your script continues across the logoff/logon sequence, copy a batch file with your next scripting sequence(s) to the Startup folder of the account that will log in (AdminAccount in the above example). Of course, this procedure requires AdminAccount to log on previously so that the directory structure under C:\WINNT\Profiles will be present already. A safe alternative is to use the Startup folder under the All Users profile.

Place a one-line batch file, which is just a hook that calls a script, in your working directory. That way, you can delete the calling batch file in the first line of the script that it calls. If you need to pass parameters across logoff/logon, create a batch file with set commands and call it in each batch file that runs after logon. Before your final logoff, just be sure to remove any batch files that you place in the Startup folder.

An example
So, how would you put everything together? Well, I recently helped prepare a server rollout across 210 branch offices of a company for which I was working. We decided to build a server and ghost the image onto the other 209 servers. When the servers were installed, I had to give them unique names and IP addresses, and I had to add them to the domain—a single domain for all of the servers. I built a script that would automate the task and allow the company to hire people with only basic skills in NT. That way, the company could save quite a bit of money. Part of my initial script follows:
echo set Domain=CSG > d:\script\params.bat

echo set Computername1=Branch007 >> d:\script\params.bat

echo set oldcomputername=%Computername% >> d:\script\params.bat

echo set AdminAccount=Admin >> d:\script\params.bat

echo set AdminPassword=master900 >> d:\script\params.bat

reg update "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName=CSG"

reg update "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName=Admin"

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword=master900"

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon=1"

echo Changing Computername (%computername%) to %computername1%

reg update HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\ComputerName=Branch007

echo Changing IP address

reg update HKLM\SYSTEM\CurrentControlSet\Services\N1001\Parameters\Tcpip\IPAddress=

echo Changing Default Gateway address to %Gateway%

reg update HKLM\SYSTEM\CurrentControlSet\Services\N1001\Parameters\Tcpip\DefaultGateway=

echo Setting Subnet Mask to %SubnetMask%

reg update HKLM\SYSTEM\CurrentControlSet\Services\N1001\Parameters\Tcpip\SubnetMask=

echo Setting Secondary WINS to %WINS%

reg update HKLM\SYSTEM\ControlSet001\Services\NetBT\Adapters\N1001\NameServerBackup=

::> Creating batch file to auto run on logon
echo d:\scripts\Next.bat > "%systemroot%\profiles\All Users\Start

echo The Computer will now reboot.......
choice Ready

shutdown /L /R /t:5 /Y /C
As you can tell from the above code, the Autologon configuration is set, and some changes are made to the TCP/IP configuration. Then, a file called RUN.BAT is created in the Startup directory of the All Users profile. RUN.BAT contains a single line that will run NEXT.BAT in my scripts directory. NEXT.BAT contains something like the following lines:
del "%systemroot%\profiles\All Users\Start

::> Get the parameters
call d:\scripts\params

::> Add the BDC to the domain
netdom /D:%Domain% /u:%AdminAccount% /p:%AdminPassword% BDC \\%computername1% /ADD

::> Reset the secure channel
netdom /u:%AdminAccount% /p:%AdminPassword% BDC \\%computername1% /reset

echo Removing %ComputerName% from the domain
netdom /domain:%Domain% member \\%oldcomputername% /delete

::> Do a full sync
nltest /SYNC

::> Change some service startup parameters
sc config Replicator start= demand
sc config Schedule start= auto
sc start Schedule

::> Set the system clock
net time /set /y

::> Switch off AutoLogon
reg update "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon=0"

shutdown /L /R /t:5 /Y /C
In the first line, I deleted the calling batch file from the Startup directory. Then, I picked up the parameters that I needed. Finally, I switched off the Autologon feature and performed a shutdown and restart. With some additions and a little personalization, the above script will work.

Over the past few weeks, I’ve introduced you to some simple and some not-so-simple commands that are available in the Windows NT Resource Kit. I have found all of these commands useful—if not essential—in most of the automation scripts that I’ve written for my clients. There are many more commands that are included in the Resource Kit, and I recommend that you take a look at its documentation if you need to perform a certain task that this series of Daily Drill Downs didn’t cover.

Richard Charrington’s computer career began when he started working with PCs—back when they were known as microcomputers. Starting as a programmer, he worked his way up to the lofty heights of a Windows NT Systems Administrator, and he has done just about everything in between. Richard has been working with Windows since before it had a proper GUI and with Windows NT since it was LANManager. Now a contractor, he has slipped into script writing for Windows NT and has built some very useful auto-admin utilities.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox