Always test new scripts and batch files using a test machine. Verify that the script or batch file works as anticipated before you test it on production machines. Even after you test scripts and batch files, provide additional monitoring while the script or batch file is new to allow potential bugs to surface.

Consider learning to use batch files for automation before you move on to scripts. Many automation tasks don't require scripts to succeed. Batch files are a very simple and easily understood way to add automation to the command line.

Third-party utilities are a tempting way to make the command line more accessible. However, it's usually a better idea to determine whether Windows provides a command or utility to accomplish the task first. Even if the Windows command or utility won't accomplish the task in the manner in which you want to accomplish it, the exercise of working with the command or utility will help you select third-party products with a greater potential for success.

Use the PushD and PopD utilities to save and restore directories as needed while working at the command line. These two utilities can save you considerable typing time. Use these utilities to create batch files that move between directories as needed to perform work. In many cases, you'll find that this feature makes it considerably easier to perform complex tasks with less typing because you don't have to type the full path to every file.

Environment variables come in three forms. The first is system variables that affect all computer users. The second is user variables that affect a single user permanently. You can find the first and second forms listed in the Environment Variables dialog box accessible by clicking Environment Variables on the Advanced tab of the System Properties dialog box. The third environment variable form is the temporary variables you create at the command line using the Set command.

Always use the most current version of a utility when possible. For example, even though many people are familiar with the older WinMSD utility, the MSInfo32 utility replaces it in Windows XP and above. Generally, you'll find that the newer utilities provide added functionality and reliability.

There aren't any absolutes when working at the command line. Sometimes you must break the rules in order to devise a reliable and secure method of automating a task. For example, even though the SchTasks utility is newer and more functional than the AT utility, you'll find that the AT utility often works better in batch files because of its simplicity. In this case, even though the SchTasks utility is more functional, the AT utility can produce a better batch file as long as you don't need the features the SchTasks utility provides.

Use after hours scripting carefully. Restrict after hours scripting to those tasks that actually require it. For example, an application, command, or utility that requires exclusive access to a database is a good candidate for after hours scripting. Don't use after hours scripting for any application, command, or utility that is unreliable or presents security risks.

Remember that a command is an internal feature of the command processor or another executable environment, such as the FTP application. A utility is an external, freestanding application. Even though commands and utilities are both executable code, commands depend on the resources of their enabling environment.

Even though a utility exists, that doesn't mean you should use it. For example, Microsoft disables the Messenger service by default in newer versions of Windows because crackers can use it to gain access to your system. However, the Msg utility requires access to the Messenger service. Unless you want to create a security hole in your system, refrain from using the Msg utility except where the network has no outside access.

Remember, this book documents a number of command and utility features that don't appear as part of the command or utility help, the local Windows help, or even the Windows Resource Kit. Some of these additions come from third-party Web sites (the sites appear in the book whenever possible). Some come from reader input for past books. Still other information comes from my personal experimentation. If you find a feature that doesn't work or you locate a feature that I should know about, contact me at JMueller@mwt.net.

More people use JavaScript than use VBScript. You can use both scripting languages (and many others) at the command line. However, if you're learning a new scripting language and want to obtain the maximum benefits from your efforts, JavaScript is by far the more popular of the two scripting languages. Not only can you use it with ease for work at the command line, you'll also find it in use on many Web sites. JavaScript is also standardized across multiple platforms, which means it's conceivable that an application you create can run equally well on a Macintosh or a Linux system as it does on your Windows system. Of course, you must use standards-based programming techniques to obtain this level of cross-platform support.

Always document your batch files using the REM command. The batch file you document might require modifications later and you don't want to spend hours relearning how the batch file works. Make things easier for yourself; use lots of comments to document your batch files.

The RunDll32 utility is possibly the most powerful single utility on your system because you can use it to access code within any DLL that provides a list of public calls. For example, you can use the RunDll32 utility to shut down the system or display a message box on screen. The number of tasks you can perform is only limited by the number of DLLs installed on the system.

Look in the \Windows\System32 folder for executables. These executables often provide helpful utilities that Microsoft or a third party installs for you. To check whether the executable is a usable utility, type ExecutableName /? and press Enter to see any help it provides. No help file usually means that it isn't a utility.

One focus of Microsoft with Server Core is improved security. Consequently, many commands and utilities that work fine with older versions of Windows appear with reduced functionality in Server Core. You may also find yourself using the RunAs utility more often to support command line development. Of course, Server Core includes many new commands and utilities as well.

Sometimes, it's hard to figure out how to change the registry to obtain a particular effect in Server Core. Having relied on graphical utilities for many years, most administrators don't know what's going on in the registry. In some cases, you can cheat by loading a hive from another system that has the configuration you want. Use the File Load Hive command to perform this task. Compare the registry on Server Core with the registry hive from the other machine to see which changes you need to make in order to obtain the desired result.

Microsoft continuously updates the commands and utilities for Windows. Make sure you perform regular system updates to ensure you have access to the latest command and utilities. When you do obtain an updated piece of software, spend time learning its new features. The time you spend will pay off in greater productivity later.

Always configure the command window to meet your viewing needs. In addition, you can change settings, such as color, to add aesthetic appeal to the command line. Always remember that the system saves your settings based on title, so a command window with a different title can have different settings.

The SET command is a powerful feature that many people don't use effectively. A SET command can store any data you require at the command prompt. For example, you can easily use it to store numeric information as well as paths to files and user information. Generally, you'll use the SET command to store short information sequences.

Use temporary files to store large amounts of cumbersome data. You can also use a temporary file as a kind of database. Parse through the temporary file using the FOR /F command format. For example, with the proper code, you can use a directory listing as a means for locating and deleting temporary files on your machine.

Because Server Core is a command line–only interface, you'll want to be sure that you configure your command line for optimum performance. Be sure you set scripting to use CScript, rather than WScript. Add color to the display to make it look nicer. Use fonts that are appealing and gentle on the eyes. Anything you can do to make the command prompt better is a real plus in Server Core.

Right-clicking doesn't accomplish much in Server Core. Remember that you'll access the built-in GUI items by pressing Ctrl+Alt+Del. When you want to try a graphical utility, make sure you start it using the command line. In many cases, you'll find that the utility has command line switches you can use to make the startup work better—such as loading files and configuring settings so you don't need to perform these tasks using the GUI every time you start the utility.

Always assume that every application, batch file, script, command, and utility on your system is going to fail. Try to list every possible failure mode, even when you think that such a failure mode is unlikely. Provide for the detection, recovery, and workaround for each failure mode so that the software continues to run, rather than failing gracefully.

The Microsoft Knowledge Base at http://support.microsoft.com/default.aspx?scid=fh;EN-US;KBHOWTO is the greatest help for the command line user. Often, Microsoft document changes and new software appear here long before you see them anywhere else. In fact, you can find material here that you won't find anywhere else.

The only good time to compile your script file is after you've tested it thoroughly. In most cases, you can use third-party utilities to obtain a native executable file.

The DS utilities, such as DSQuery, provide you with extensive access to Active Directory. Even though these utilities don't appear as part of a standard Windows installation, you can install them from a server that supports them. Using the various DS utilities, you can add, delete, query, edit, and get Active Directory objects.

Redirection is an important part of working at the command line at any time. You can redirect both input and output using the redirection symbols. For example, instead of displaying a directory listing at the command prompt, you can send it to a file instead. By placing the output in a file, you can perform sequential processing of the individual file entries.

The XCopy command is the most versatile method of copying bulk data from one location to another. If you need to copy just a few files in the same directory, use the Copy command for greater efficiency (it executes more quickly than XCopy does). Avoid using older commands such as DiskCopy because Microsoft designed them in an era when floppies were the main form of data transfer from one machine to another.

Rely on the TypePerf utility to track performance characteristics at the command line. Use PerfMon when you need to perform long-term performance tracking or require use of the graphical performance monitoring interface that Windows supplies.

Use automation with great care. Always test the applications, batch files, and scripts you intend to automate before you let them run unmonitored. Never automate unreliable applications, batch files, or scripts.

Remember to use the AutoExec.NT and Config.NT files to modify the application execution environment. You can perform any task in AutoExec.NT that you would with a standard batch file.

Many applications don't use the registry to store settings anymore. Look for files with extensions such as CONFIG and INI to locate the settings in these newer applications. In some cases, the file will simply have an XML extension or you may find it contains XML or textual information that looks like configuration settings. User-specific settings generally appear in the \Documents and Settings\ UserName\Application Data\ApplicationName directory (where UserName is the name of the user and ApplicationName is the name of the application).

Keep in mind that you have multiple methods for performing remote access tasks at the command line. Many people immediately think about using Terminal Server for remote tasks, but many utilities provide direct machine access through command line arguments. Use the direct access method when you only require the services of a single utility. Remember that newer versions of Windows also include Remote Desktop, but that you must make registry changes to systems in some cases to use this technique. You can also rely on older technologies to perform remote tasks, such as Telnet. In short, don't limit yourself to one technique for remote access; use the technique that works best for a particular scenario.

Killing tasks using utilities such as TaskKill might seem like a good idea when the system isn't responding as anticipated. However, a seemingly frozen application may simply be performing a task in the background, so it's important to wait before you kill the task. Always assume that killing a task will result in data loss of some kind. In addition, killing the task might not revive the system; you could still end up having to reboot the system to restore its responsiveness.

Assume that someone is going to break into your system and cause significant damage to it, because someone almost certainly will. Treat security as a barrier that keeps honest people honest. A determined cracker will always find a way in, so your only defense is to rely on monitoring and constant maintenance to detect the intrusions when they occur.

One of the essential issues to remember about working with scripts is that they can use any registered object on the machine. In addition to the special WScript object, a script can access any other object on the system, such as the media player. All you need to remember is the CreateObject() method used to create new objects based on existing system classes.

Make sure you use the OCList utility to determine which features are installed on Server Core. You don't have any other utility you can use for the task since Server Core doesn't provide a GUI. Use the OCSetup utility to add new roles and features to your server as needed. These utilities are new to Server Core, so you'll have to make special note of them.

Use wildcard characters to create file specifications when you need to process more than one file with a single command. Some commands and utilities don't support wildcard characters at all. However, most utilities support at least the asterisk (*) wildcard and many support the single character question mark (?) wildcard character as well. Some utilities support exotic string specification techniques and you should employ these wildcard character combinations whenever possible.

Most commands and utilities support the /? command line switch when you need help. However, some don't support this standard. When you find a utility that doesn't support the /? command line switch, try the /help command line switch instead. You can also try the Help command to obtain information about the command or utility.

Remember that using pipes to connect Active Directory utilities together is one of the most powerful techniques for working with Active Directory. Using a pipe makes it possible to perform tasks with Active Directory without knowing the names of the object in advance. In addition, you can perform tasks on object sets, such as a group of users.

Remember that you can only use static and scripted content when setting up a Web server with IIS 7 in Server Core. Because Server Core doesn't support the .NET Framework (at least as of this writing) you can't run ASP.NET applications directly in IIS. However, there are some interesting discussions taking place on using Mono (http://www.mono-project.com/), a .NET Framework substitute, to run ASP.NET applications on Server Core. You can find some helpful instructions here: http://www.gotmono.net/Default.aspx?pageindex=5&pageid=27 and here: http://ajaxwidgets.com/Blogs/thomas/how_to_run_an_asp_net_2_0_webs.bb.

Always consider the security issues of using any application, command, or utility. Never automate an application, command, or utility that presents a potential security problem. For example, applications, commands, or utilities that require administrative privileges often present a significant security risk that you won't want to leave open for crackers to exploit.

Never assume that users will perform any particular task. For example, even if you send a message across the network to close all open files on your system before you perform a maintenance task, you still need to verify that users have followed through by using the OpenFiles utility. The OpenFiles utility tells you about any open files on your system, giving you peace of mind when you perform the maintenance task.

Always run applications using the lowest number of rights that you can. Logging in with administrator rights for every task is an open invitation to cracker invasion. If you need to run a task that requires temporary extended rights, then use the RunAs utility to perform the task. The RunAs utility lets you execute just one command using Administrator rights, rather than using Administrator rights all of the time.

Remember that Server Core doesn't provide access to the common dialog boxes, which means that many of your favorite utilities won't work. You may be able to open a file with a particular utility and view it, but you won't be able to save any changes because the utility will lack the required common dialog box support. Applications that provide their own custom dialog boxes will work fine.

Scripting languages are more powerful than batch files because they include better flow control. In addition, you can possibly compile a script for better execution speed. However, with power comes complexity. Creating a script is an order of magnitude more complex than working with batch files.

Don't assume a limitation in a Windows graphical utility necessarily translates to the command line. For example, most people realize that Windows Explorer does a very poor job of finding content on your system. In fact, it does such a poor job that many people have resorted to third-party products to locate information on their systems. However, a combination of the Dir command and the FindStr utility can help you locate any information on your system for free and often faster than these third-party utilities can perform the task. Of course, you need to know how to use these command line utilities to take advantage of this command line feature that works far better than its Windows counterpart does.

The system creates a number of environment variables for you. For example, you'll find that the OS environment variable tells you whether you're using Windows as an operating system (preventing people from using batch files intended for the Windows environment on a DOS system). You can always list the environment variables on your system using the SET command. Simply type SET and press Enter to see the list.

Create custom versions of AutoExec.NT and Config.NT for applications that require them. The custom versions can use different settings to ensure that the application runs as anticipated. You specify these custom files using the Windows PIF Settings dialog box that you access by clicking Advanced on the Program tab of the application's Property dialog box.

Use the error level output of commands and utilities to detect errors in batch files. An IF ERRORLEVEL command can detect the error. A simple GoTo command can redirect the flow of the batch file to an error-handling section, and then redirect program flow for another attempt at the failed command or utility. Using this looping approach helps you create a certain level of error handling and fault tolerance even in batch files. Make sure you record all error information possible in an output file.

The command line is like the submerged part of an iceberg. Few people see it, many people don't know about it, yet it exists and it comprises the greater part of the Windows operating system. Every time you think that a graphical utility will replace the command line, look again because someone will find a way to automate it with a batch file or script.