Tech Line

Easy-Bake Disaster Inventories

Including system configuration information with backups is easier than you think.

In the coming weeks, MCPmag.com will give your most challenging Windows, Exchange and general networking questions to our esteemed contributing IT experts-in-residence. Contributing writer Chris Wolf steps up to the plate first, with this question on annotating backups with inventory information.

Chris: One aspect of disaster recovery that I have been burned by previously was not having accurate system hardware and software inventories prior to the disaster. We're a small non-profit with limited financial resources. I'm sure that there are enterprise-class tools that can do this, but are there any other alternatives?
— Anonymous

Tech Help—Just An
E-Mail Away

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to the MCPmag.com editors at mailto:[email protected]; the best questions get answered in this column; MCPmag.com baseball caps go to the published submitter.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Anonymous: Your problem is atypical of many organizations. One common problem many administrators endure following a complete server failure or disaster is rebuilding hard disk configurations. It's not usually just enough to know the physical configuration of each disk, but also how they're logically partitioned. If the partition sizes on a rebuilt server are not greater than or equal to the original sizes, your restore will fail once the server runs out of disk space on a given partition.

While disk information is crucial, rebuilding a system from scratch may also require knowledge of:

  • OS Installation path
  • Installed software and installation folder locations
  • Installed hardware devices
  • System services configuration
  • Network connection settings

Beginning with Windows NT, Microsoft included a tool with the OS called Winmsd.exe that was capable of collecting all of this information. With Windows 2000 the tool was renamed to Msinfo32.exe; however, it can still be launched by running Winmsd.

While many administrators are aware that Msinfo32 exists, few have discovered the useful switches that accompany it. You can find each switch at Microsoft Knowledge Base article 255713, "Windows 2000 Command-Line Parameters for Msinfo32.exe."

My favorite switch is the /nfo switch, which allows you to silently create the system information file and save the output to an .nfo file. With this file extension, the system information can be viewed in the Msinfo32 GUI by just double-clicking on the saved file in Windows Explorer. To create a file called systeminfo.nfo, for example, you just type:

msinfo32.exe /nfo D:\ConfigInfo\systeminfo.nfo

To run the command from within a batch file or directly from the command prompt, it should be preceded with the start command.

Here's an example of a simple batch file that saves a system information file using variables for both computer name and date. This allows you to save multiple system information files to the same folder and easily sort them by system and date saved.

:: Format date as mm-dd-yyyy and assign to
:: variable 'Today'
set Today=%Date:~4,2%-%Date:~7,2%-%Date:~10,4%

:: Check for existence of backup folder and
:: create if necessary
IF NOT EXIST D:\systeminfo md D:\systeminfo

:: Generate output as .nfo file (file name based on
:: computer name and date)
start msinfo32.exe /nfo "D:\systeminfo\%computername%_%Today%.nfo"

When run on a server named Redmond-FS1 on June 15, 2005, the output file would be named Redmond-FS1_06-15-2005.nfo.

Another switch that's pretty handy is the /report switch. It can be used to save the output file to a text file, which you may find useful if you want to use the command output with other scripts or third-party reporting tools.

My preference is to run Msinfo32 in a pre-backup script each time a server is backed up. I also prefer to store the output file for all servers on a single shared folder accessible via a UNC path. Of course, you'd want to back up the shared location for all of your system info files as well, to be prepared for a disaster that involved complete building loss. If a disaster happens, opening the most recent system information file for each server will give you a complete roadmap to help you rebuild each box.

When run without switches, Msinfo32's output is full of detailed system configuration information that you can view and save anytime. However, to automate system hardware, software, and configuration inventories across your network, Msinfo32's available switches are worth their weight in gold.

About the Author

Chris Wolf is a Microsoft MVP for Windows --Virtual Machine and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, storage and enterprise management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).learningstore-20/">Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).

comments powered by Disqus
Most   Popular