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.