How Can I Configure the System Failure Options on a Windows Server 2003 Computer?

ScriptingGuy1

Hey, Scripting Guy! Question

Hey, Scripting Guy! How can I configure the system failure options on a Windows Server 2003 computer? I’d like to configure the machine to do a small memory dump, and disable both the sending of an administrative alert and the automatic reboot.

— JS

SpacerHey, Scripting Guy! AnswerScript Center

Hey, JS. You know, the Scripting Guys happen to all be in a good mood today, so we’re going to go the extra mile here: not only are we going to show you how to configure system failure options on a Windows Server 2003 computer, but – for no extra charge – we’ll show you how to perform this task on a Windows XP computer or even on a Windows 2000 computer as well. Let’s see any other daily scripting column beat an offer like that!

OK, if you want to get technical we’re only making that offer because a script that sets system failure options on a Windows Server 2003 computer can – without any changes – do the exact same thing on a Windows XP or Windows 2000 computer as well. But maybe we could all just pretend that the Scripting Guys are doing some extra work out of the goodness of their hearts.

Besides, it’s still more than you get out of any other daily scripting column. Or at least any other daily scripting column found on TechNet.

As far as we know, that is.

But who cares about motivations anyway? After all, our guess is that you just want a script that changes the system failure options:

Const SMALL_MEMORY_DUMP = 3

strComputer = “.”

Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

Set colRecoveryOptions = objWMIService.ExecQuery _ (“Select * From Win32_OSRecoveryConfiguration”)

For Each objOption in colRecoveryOptions objOption.DebugInfoType = SMALL_MEMORY_DUMP objOption.AutoReboot = FALSE objOption.SendAdminAlert = FALSE objOption.Put_ Next

As you can see, even though this script works on Windows Server 2003 and Windows XP and Windows 2000 there really isn’t much to it. We start out by defining a constant named SMALL_MEMORY_DUMP and setting the value to 3; we’ll use this constant to specify how we want to write debugging information in case of a system failure (more popularly known as a “blue screen”). We can configure any of the debugging types shown in the following table:

Value

Meaning

0

None

1

Complete memory dump

2

Kernel memory dump

3

Small memory dump

After defining out constant we connect to the WMI service on the local computer (although, as is the case with almost all WMI scripts, we could also run this script against a remote computer). We then use this line of code to retrieve all the instances of the Win32_OSRecoveryConfiguration class, which just happens to be the class used for managing system failure options:

Set colRecoveryOptions = objWMIService.ExecQuery _
    (“Select * From Win32_OSRecoveryConfiguration”)

We should point out that, because we use the ExecQuery method, we’ll get back a collection and, because we have a collection, we need to set up a For Each loop to walk through all the items in that collection. However, there’s only one set of system failure options per computer, which means the collection will never have more than one item in it.

Speaking of For Each loops, that’s what we do next: we set up a For Each loop to walk through all the system failure options in the collection. (Again, we’ll have only one such set.) Inside that For Each loop we configure values for three different properties: DebugInfoType, AutoReboot, and SendAdminAlert. That’s what we do here:

objOption.DebugInfoType = SMALL_MEMORY_DUMP
objOption.AutoReboot = FALSE
objOption.SendAdminAlert = FALSE

That little block of code should be fairly straightforward. We start off by setting the value of the DebugInfoType property to our constant SMALL_MEMORY_DUMP. Because AutoReboot and SendAdminAlert are both Boolean values, we can disable sending an email and automatically rebooting the computer simply by setting these values to False. After configuring the property values we then use this line of code to write the changes back to the computer:

objOption.Put_

Whatever you do don’t leave out that line. The Put_ method is roughly equivalent to the Save command in Microsoft Word. If you don’t choose the Save command any changes you make in Word aren’t going to be saved. Likewise, if you don’t call the Put_ method any changes you make to WMI property values won’t be saved, either.

Scripting Guys anecdote. Right before the Microsoft Windows 2000 Scripting Guide went to press, an editor we had at the time ran a spell-check on the entire book and changed every instance of Put_ to Put. We never would have caught the mistake had she not pointed out the fact that we needed to be more careful with our spelling, lest the book end up riddled with errors.

As long as we’re on the subject, we should mention that the Scripting Guide actually includes a section on managing system failure options. We were going to keep that a secret but, seeing as how we’re feeling so chipper today, well, what the heck.

So there you have it, JS; aren’t you glad we were in a good mood today? And trust us, that doesn’t happen very often. For at least one of the Scripting Guys his good moods pretty much coincide with the life cycle of the 20-year locust. Fortunately, the other Scripting Guys all respect and admire him anyway, despite his occasional grumpiness.

Or at least he’s pretty sure that they respect and admire him. Hey, why wouldn’t they?

0 comments

Discussion is closed.

Feedback usabilla icon