Patch Testing

The gpresult.exe command in baseline.bat is specifically intended to produce different output in the before.txt and after.txt files. This tool gives the exact time that the machine last processed GPOs. This information will be helpful when you check whether Group Policy is operating properly (more about this later).

Another tool to notice in baseline.bat is netdiag.exe, a Support Tool that automatically performs more than a dozen networking tests. Try running it in verbose mode (by using the /v switch) to show a wealth of configuration and troubleshooting information when a bad patch causes connectivity problems.

After you run baseline.bat on your lab machine, run remote.bat, which Web Listing 1 (http//:www.winnetmag.com, InstantDoc ID 41979) shows, from a remote system to test the lab system's remote manageability. The remote system must be running Windows Server 2003 or Windows XP for all the tools in remote.bat to run, but the target system can be running Win2K. Remote.bat uses rpcdump.exe to verify remote access to all remote procedure call (RPC) endpoints, wmic.exe to test Distributed COM (DCOM) access to the Windows Management Instrumentation (WMI) service, schtasks.exe to interact with the Task Scheduler, net.exe to map a drive letter to the C$ administrative share, and mstsc.exe to connect to Terminal Services/Remote Desktop with RDP for a thin-client session. For the RDP thin client, create and save a file named target.rdp that contains the IP address of the target machine, a username, and a password, then pass the filename to the client as the first argument. When the batch file runs, visually confirm that you're automatically logging on to the remote desktop when the thin-client window appears. Then, as you did with baseline.bat, create before.txt and after.txt files on the remote system and use fc.exe to compare them.

Finally, if you use IP Security (IPSec) on your production LAN, you should also use it in your lab. For information about how to configure IPSec, see "IP Security in Windows 2000," March 2000, InstantDoc ID 7976. If you use IPSec for VPN access, make sure you install the Network Address Translation-Traversal (NAT-T) upgrade from Microsoft (as described in the Microsoft article "L2TP/IPSec NAT-T Update for Windows XP and Windows 2000,"http://support.microsoft.com/?kbid=818043). In addition to testing patches that might affect the IPSec driver, plan to test IPSec configuration changes in the lab before deploying them on your production LAN—making a configuration mistake that leaves hundreds of machines stranded (and you without a job) is all too easy.

Crucial Applications and Services
In addition to network connectivity and remote manageability, you must test your mission-critical applications and services, including Group Policy processing. Begin by enabling on the machines in your lab all the logging of which your applications and services are capable; for example, enable all audit policies and turn on debug logging in DNS, RRAS, Certificate Services, SQL Server, and Exchange Server. Enable this logging so that if a patch breaks something, you'll have searchable audit logs that you can use to detect and diagnose the problem.

To write extensive Group Policy information to the Application log, set a REG_DWORD value named RunDiagnosticLoggingGroupPolicy to 1 under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics registry subkey (you'll likely need to create both the value and the Diagnostics subkey), as the Microsoft white paper "Troubleshooting Group Policy In Windows 2000" (http://www.microsoft.com/windows2000/docs/gptshoot.doc) discusses. If you need to log even more detailed Group Policy information, you can also enable user environment logging, as the Microsoft article "How to Enable User Environment Debug Logging in Retail Builds of Windows" (http://support.microsoft.com/?kbid=221833) describes.

After enabling logging on all these services, check the logs to confirm that everything is working fine, then clear the logs and apply your patches. A quick way to erase a textual log file (not an event log) or to create a blank text file is to run the command

echo 1>nul 2>c:\logfile.txt 

in which 1>nul redirects the standard output of the Echo command to nothing and 2>c:\logfile.txt redirects the standard error output to the specified file, overwriting its contents if it already exists or creating the file if it doesn't exist.

To clear the Windows event logs, use a batch file to run the commands

cscript.exe ClearEventLog.vbs
  127.0.0.1 Application
cscript.exe ClearEventLog.vbs
  127.0.0.1 Security
cscript.exe ClearEventLog.vbs
  127.0.0.1 System

to invoke ClearEventLog.vbs, which Web Listing 2 shows. The first argument in each command is the IP address or name of the computer (local or remote) whose event log you want to clear, and the second argument is the log name. If you have event logs for DNS, AD, or other services, clear those as well.

Now that you've cleared the logs and have a clean slate, you can install the patches on the test machines and start running applications and stressing services to try to cause errors. Run all the features that users invoke as they work, with special emphasis on features that involve the network, printing, security controls, file system access, and anything else that's likely to break (perhaps because it's been fragile in the past).

For example, you could write a batch file that would execute the command

winword.exe C:\file.doc

to launch Microsoft Word and have the application automatically open file.doc. In file.doc, create a macro named AutoOpen that prints the document to a remote printer, saves a copy of the file to a shared or Web Distributed Authoring and Versioning (WebDAV) folder, renders the document to a local Adobe Systems' Adobe Acrobat .pdf file, and so on. Naming the macro AutoOpen forces Word to automatically run it when Word opens the file that contains it. Creating Microsoft Office macros typically requires no programming; for example, in Word XP and Word 2000, select Macro from the Tools menu, select Record New Macro, name the macro AutoOpen, store it in the current document (not in the template), then perform the desired tasks. Word will record your keystrokes and mouse clicks for you. In Microsoft Excel XP and Excel 2000, name the macro Auto_Open to have Excel run the macro when the application opens the file that contains the macro. Check whether your non-Microsoft applications have similar automation features.