Microsoft's Windows OSs owe much of their early success to their GUI, a dramatic departure from the text-oriented OSs of the day. I can still remember the effect the Windows 3.0 interface had on me after years of working with 24 * 80 green-screen systems. As the OS has matured, however, Microsoft has realized that a command-line utility is superior to a graphical one in many situations. Automation is the most obvious area. You can use a few command-line utilities and a batch file to create a scheduled task that's just about impossible to create by using a Microsoft Management Console (MMC) snap-in. A rich set of scripting resources, including languages such as VBScript and interfaces such as Active Directory Service Interfaces (ADSI) and Windows Management Instrumentation (WMI), are available to the administrator.
Unfortunately, the average administrator doesn't usually have the time to get comfortable enough with these tools to build useful utilities. Administrators need powerful, already-built utilities that they can throw into a batch file, and they usually need them yesterday. Because administrators need to figure out how to use the programs quickly, decent documentation is important. Consistent syntax across the utilities and informative error messages, both sorely lacking in the past, are important in helping administrators learn utilities quickly.
Microsoft formed Command Line Management, a distinct program office in the Windows Server 2003 development project, to address these administrator needs. Let's take a high-level look at nine significant command-line utilities for Windows 2003 that the Command Line Management program team either created or improved from existing tools.
Preliminaries
One of the goals of the Command Line Management program is to provide administrators with command-line utilities to perform their top management tasks. Not only are these utilities flexible and powerful enough for any administrator to use them to whip up useful scripts, they also improve on previous tools in several much-appreciated ways:
- The utilities have a standard syntax to reduce the amount of time administrators need to learn each one.
- You can execute the utilities remotely against a server so that you don't have to log on directly to the console.
- The utilities support alternate credentials, so they easily work in a secure environment in which you're not typically logged on as a privileged account.
- The utilities are described in Windows 2003's Help system (search for command line reference) and an upcoming Windows 2003 resource kit. If you want to study these utilities' Help information, you can copy \%windir%\help\ntcmds.chm to your local system and open it there.
As I mentioned earlier, not all of the utilities are new. Many, such as Shutdown, are from the resource kit or Windows 2003 Support Tools, and are now more robust and standardized.
To be proficient with many of these tools, you have to become comfortable with the distinguished name (DN) convention of describing Active Directory (AD) objects. The DN of an AD object describes the object and where it sits in the AD hierarchy. A domain is prefaced with DC= (domain component); an organizational unit (OU), with OU=; and other objects, with CN= (common name). You start the DN with the object itself, then climb to the top of the AD hierarchy. For example, the DN of a DC in the BigTex.net domain would be CN=firstdomcont,OU=domain controllers,DC=bigtex,DC=net. If the DC were in the Sales child domain of BigTex.net, its DN would be CN=firstdomcont,OU=domain controllers,DC=sales,DC=bigtex,DC=net. Remember to enclose the DN in quotes if any of the object names include a space. Don't put a space between the comma and the following object name. I tend to capitalize CN, OU, and DC for clarity, but that practice isn't required.
Be careful if you build command-line utility scripts with anything other than Notepad. By default, Microsoft Word adds smart quotes, replaces double hyphens with em dashes, and uses all sorts of other symbols to make the text look better. As a result, you can spend an hour or two discovering that your command syntax is indeed correct but that the utility is rejecting a few nondisplayable symbols in your code.
The Adprep Utility
Adprep should come first in any discussion of new AD-related command-line utilities because as you might guess from its name, you use Adprep to prepare your existing Windows 2000 AD for upgrade to Windows 2003. If you've planned or installed Microsoft Exchange 2000 Server and Active Directory Connector (ADC) in your enterprise, you'll have worked with an earlier version of Adprep. Although upgrading a Win2K DC to Windows 2003 is straightforward, the Adprep process is a significant new step in this and future upgrades of Windows server OSs.
Adprep has two command switches: /forestprep and /domainprep. You use /forestprep to update the AD schema from the Win2K version 13 to the Windows 2003 version 30. To perform the update, /forestprep does the equivalent of running the Ldifde utility against each of 17 .ldf files (sch14.ldf through sch30.ldf). (For more information about the Ldifde utility, see the Microsoft article "Using LDIFDE to Import and Export Directory Objects to Active Directory" (http://support.microsoft.com/?kbid=237677). Each .ldf file contains schema updates (new object classes or attributes, or changes to existing ones) that Microsoft developers created during the course of the beta program. If you want to see the updates, you can view the .ldf files in the \i386 directory on the Windows 2003 CD-ROM. You run /forestprep once for the entire forest, and its schema updates must have replicated to every DC in the forest before you can continue with the next step: running /domainprep. Figure 1 shows /forestprep updating the schema from version 29 to version 30.
Previous
)
)
Register
For instance: adding an ou as in your first example of the DSADD utility, dsadd failed, A referrel was returned from the server.
What does this mean? I certainly don't know.
Brian April 11, 2004