In the Windows realm, command-line utilities never seem to garner the attention that graphic utilities do. Even though command-line tools have experienced a myriad of improvements over the years, you still have to dig around to find them. Not only does Windows Server 2003 boast a wealth of new command-line utilities, but Microsoft has also enhanced a number of mainstay Windows 2000 (and even Windows NT 4.0) tools. In addition, Microsoft has added or enhanced many of the tools at its Download Center.
Indeed, valuable command-line stuff is out there, but it remains scattered and poorly advertised. The sidebar "Get Your Command-Line Utilities Here!" gives you the five premier locations at which you'll find Windows command-line utilities. In the following discussion, I talk about all kinds of tools, from the generally useful to more specific server-troubleshooting and Active Directory (AD)-troubleshooting utilities. I break the discussion down according to the origins of the tools, beginning with the base OS and continuing through Support Tools, the Microsoft Download Center, the Microsoft Windows Server 2003 Resource Kit, and even some third-party resources.
The Base OS
Utilities installed with the OS are the most fundamental of all the tools in this article. Nonetheless, you might not be aware of some of these essential utilities.
Ds- tools. No discussion of Windows 2003 command-line tools would be complete without at least a mention of the Ds- directory service tools—Dsquery, Dsget, Dsadd, Dsmod, Dsmove, and Dsrm—that come with the OS. Dsquery and Dsget, which come with Windows 2003, perform slightly different functions that are confusing at first but complementary when you combine the tools. Dsquery returns lists of AD objects in distinguished name (DN) format by specifying search parameters with a combination of keywords and search filters. Dsget uses the same method to return the attributes of a specific AD object. Dsget also accepts output from Dsquery via the pipe (|) command, allowing Dsget to return only certain attributes or otherwise format the output of a list of objects. Figure 1 shows the output of Dsquery to return all domain controllers (DCs) in the deubynet domain, and also shows the output after the output is run through Dsget to return only the DNS name and site information for each.
Dsadd (add objects), Dsmod (modify attributes of existing objects), Dsmove (move objects within a domain), and Dsrm (remove objects) have syntax that's similar to that of Dsquery and Dsget. You can find detailed information about how to use these commands in "Windows Server 2003 Directory Service Tools," October 2004, InstantDoc ID 43753.
In deference to the complexity of the AD hierarchy, the first parameter of Dsquery, Dsget, Dsadd, and Dsmod is a keyword that specifies the type of object you're operating on. This parameter avoids the requirement of knowing exactly where in AD the objects reside. For example, with the third-party AdFind tool, an efficient search of sites would set the base DN with which to begin the search to cn=sites,cn=configuration,cn=yourdomain,cn=com. With Dsquery, you simply need to specify dsquery sites in the command string. I would argue, however, that to truly understand AD, you need to know the location of these objects. Also, the Ds suite doesn't provide the full range of operations you might need. For example, you can't programmatically manipulate site configuration. When you're comfortable with the Ds tools, step up to AdFind and AdMod, which I discuss in a moment.
Where. Have you ever tried to run a utility, found it wasn't on your current system, but couldn't remember whether it was a resource kit tool, a Support Tools utility, a server-specific command, or a downloaded tool? When I face this situation, I go to the system and run the command
where
where name.extension is the tool's filename. This command tells you the tool's directory location. Better yet, to perform this task on a remote system without leaving your chair, run this command in conjunction with the Sysinternals tool PsExec, which I describe later:
psexec \\
%windir%\system32where.exe
Support Tools
If the base OS tools are your fundamental utilities, the Support Tools are a close second. Originally intended to help Microsoft support professionals diagnose problems, the Support Tools have become an essential part of any administrator's toolkit and should be installed on all systems.
DcDiag. The Support Tools' DcDiag tool is the first utility you should run if you suspect a DC problem. The tool's basic functionality, without options, is to run 27 tests against a target DC (five more than in Win2K). If you use the /s switch to specify a target DC, you can then use the /a switch to test all DCs in the target DC's site. If doing so doesn't provide a broad enough scope, you can use the /e switch to test all DCs in your forest. (Obviously, in a large forest, you should wait to run the /e switch at an off-peak time.) The /dcpromo switch is a useful new option that tests a member server's configuration for readiness to become a DC. The /dcpromo switch is the only one that doesn't actually work on a DC.
DNSLint. The Support Tools utility DNSLint is a little-known tool that lets you diagnose common DNS problems related to incorrect delegation or incorrect or missing DNS records for a domain. If you choose, DNSLint can traverse the entire domain and all DNS servers within it to check for errors in the DNS structure. As with most of the utilities in this article, DNSLint offers unique options. In many situations in which you have a test (or otherwise internal) domain, you'll want to use the /s DNS server IP address option because it bypasses an Internet lookup of the domain. DNSLint creates an output HTML report called dnslint.htm. If you want text output instead of the default HTML format (perhaps because you want to use a script to process the output), you can specify the /t and /no_open options.
DNSLint reveals its true power, however, when you use the /ad option to run AD DNS tests. The /ad option runs a battery of AD-related queries about proper GUID registrations for the forest's DCs, Start of Authority (SOA) and Name Server (NS) records, and SRV record registration. With this option, you must specify the IP address of a DC that's authoritative for the root domain of the forest. You also have to use the /s option to bypass InterNIC lookup—usually, you'll use the same IP address of the server you're using for the /ad option, so the command will look like
dnslint /ad 192.168.1.51 /s 192.168.1.51
The option also checks for DNS glue records, which are A records in the root domain that locate the DNS servers that are authoritative for the child domains. If you want to customize DNSLint by specifying certain DNS servers and certain tests, you can use the /ql option. If you add autocreate after /ql, DNSLint will create a sample input file named in-dnslint.txt for you to build on.
Previous
Register
Ken
kibbage July 09, 2005 (Article Rating: