Send in your Unix questions today! |
See additional Unix tips and tricks
When one of only a handful of Windows servers that I manage dropped off my
radar for a while, I wasn't sure what to think. I had been running an application,
for which this system was the server and it stopped responding. When I tried
reconnecting, it was clearly not available. The system was rebooting, but it
took me a while to figure that out.
"How do I go about determining if a Windows server has rebooted?"
I asked myself. Unlike the hundreds of Solaris servers I manage, this one doesn't
respond to commands such as "uptime" that I've come to depend on.
On the other hand, even Windows is an operating system and this kind of information
should be available in some form, so I snooped around and found some useful
commands.
The one that works best for telling me how long a system has been up works
on my Windows XP laptop, but not on the Windows 2K server that had just rebooted.
For future use, I put this command in a batch file and stashed it in a directory
that I added to my search path long ago so that I can invoke my batch files
without having to move into the directory that houses them. Here's the batch
file I set up:
> type uptime.bat
systeminfo | find "Up Time"
|
As you can see from the lines shown above, I put the command I had learned
into a batch file (uptime.bat). Now, when I type "uptime" in a DOS
window on my laptop, I will see something like this:
> systeminfo | find "Up Time"
System Up Time: 2 Days, 2 Hours, 13 Minutes, 25 Seconds
|
A lot of lines overwrite each other before the "System Up Time" line
appears, but I quickly get the information I need. As you undoubtedly have recognized
without my saying, the DOS "find" command is similar to the grep command
we use on Unix systems. The systeminfo command provides quite a bit of information
on the system, starting with information like what is shown below and continuing
with hotfixes that have been applied, information on the boot disk, the time
zone and much more.
> systeminfo
Host Name: SHENRYSTOCKER
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600
OS Manufacturer: Microsoft Corporation
OS Configuration: Member Workstation
OS Build Type: Uniprocessor Free
Registered Owner: Sandra H-S
Registered Organization: Dragonfly Ditch
Product ID: 55555-654-4567890-12345
Original Install Date: 1/19/2005, 3:33:08 PM
System Up Time: 2 Days, 2 Hours, 15 Minutes, 13 Seconds
System Manufacturer: Dell Computer Corporation
System Model: Latitude D800>
System type: X86-based PC
Processor(s): 1 Processor(s) Installed.
[01]: x86 Family 6 Model 13 Stepping 6 GenuineIntel 1993 Mhz
BIOS Version: DELL - 27d40903
Windows Directory: C:\WINDOWS
System Directory: C:\WINDOWS\system32
Boot Device: \Device\HarddiskVolume1
System Locale: en-us;English (United States)
Input Locale: en-us;English (United States)
Time Zone: (GMT-05:00) Eastern Time (US & Canada)
Total Physical Memory: 1,023 MB
Available Physical Memory: 413 MB
Virtual Memory: Max Size: 2,048 MB
|
For older Windows systems, you can find out the date and time that the system
was last rebooted with this command:
> net statistics server | find "since"
Statistics since 11/13/2007 8:29 AM
|
For the rebooted Windows 2000 server, this command showed the server had rebooted
at 9:25 in the morning. This led me to discover that the server had rebooted
at almost precisely the same time every other week as far back as the event
log reported. Ironically, until this particular incident, the reboot had happened
in the middle of my group's weekly meeting. With the push back of the clock
on November 3rd, the reboot happened an hour earlier than usual.
Other useful commands to run in a DOS command window are "at" which
reports any at jobs and schtasks (Windows XP, Vista). Windows at jobs are similar
to at jobs on Unix systems. Scheduled tasks are similar to cron jobs. Unfortunately,
neither scheduled tasks nor at jobs (none set up) provided any clues regarding
these periodic reboots.
Another useful command for Windows XP and Vista is the tasklist command. It
works like the ps command on Unix. Yes, of course, this same kind of information
is available through the Windows GUI and I have been laughed at by Windows geeks
for insisting on command line options. At the same time, it's far easier to
collect information -- especially if I want to automate the process -- on the
command line.
With the log files only reporting the unexpected reboot after the fact, it
may be a long time (at least another two weeks!) before I have any additional
insights on what is going on with this particular Windows system, but at least
I've uncovered the DOS equivalents of what I would be doing on a Unix system
if the unexpected reboots were happening in the more familiar environment.
Part 2, Reboot mystery solved