Alright, so my metaphor is off, but it is frustrating to find that, after hours of troubleshooting, that pesky application performance or availability issue was caused by a missing exception in a firewall somewhere between Host A and Host B. So more often than not, testing for a blocked port is on my troubleshooting short list these days.

So how does one test for a blocked port between two hosts? For TCP/IP ports, there are many options available, including nmap. But assuming the listener is running, I usually use a telnet client to attempt to connect to the port. An elegant test, it is not. But in most cases, it does the job just fine (as long as you have a telnet client installed).

But what about UDP ports? UDP is a different beast because it is a connectionless protocol. In other words, you can send something to the client, but don’t expect to receive a response indication of success in return. It’s true that you can sometimes determine whether a UDP port is open through alternate means, but isn’t necessarily fool-proof. Instead, the method I use is to set up a listener on the UDP port in question on the receiving host and then UDP packets to that host and port from the sending host (that is, the host that typically does the sending the UDP packets). The best part is, I can do it all using two very simple PowerShell scripts. Below are the scripts, followed by instructions.

 Receive-UDPMessage.ps1

#Waits for a UDP message on a particular port.
Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host UDP port to send the message to')]
[Int]$Port,
[parameter(Mandatory=$False,Position=1, HelpMessage='If set, the function will continue listening for messages instead of exiting after the first one it receives. ')]
[switch]$Loop=$False
)

function Receive-UDPMessage{
[CmdletBinding(
    DefaultParameterSetName='Relevance',
    SupportsShouldProcess=$False 
)]
Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host UDP port to send the message to')]
[Int]$Port,
[parameter(Mandatory=$False,Position=1, HelpMessage='If set, the function will continue listening for messages instead of exiting after the first one it receives. ')]
[switch]$Loop=$False
)
    try {
        $endpoint = new-object System.Net.IPEndPoint ([IPAddress]::Any,$port)
        $udpclient=new-Object System.Net.Sockets.UdpClient $port
        do  {

            Write-Host "Waiting for message on UDP port $Port..."
            Write-Host ""
            $content=$udpclient.Receive([ref]$endpoint)        
            Write-Host "Received: $content" 
            write-host "Received message: $([Text.Encoding]::ASCII.GetString($content))"
            Write-Host "Received from: $($endpoint.address.toString()):$($endpoint.Port)"

        } while($Loop)
    }catch [system.exception] {
        throw $error[0]

    } finally {
        $udpclient.Close()
    }

}

Receive-UDPMessage -Port $Port $Loop

Send-UDPMessage.ps1

#Sends a message to a host on a particular port.

Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host to send the message to')]
[String]$Hostname,

[parameter(Mandatory=$True,Position=1, HelpMessage='The message to send')]
[String]$Message,

[parameter(Mandatory=$True,Position=2, HelpMessage='The host UDP port to send the message to')]
[Int]$Port
)

function Send-UDPMessage{
[CmdletBinding(
    DefaultParameterSetName='Relevance',
    SupportsShouldProcess=$False 
)]
Param(
[parameter(Mandatory=$True,Position=0, HelpMessage='The host to send the message to')]
[String]$Hostname,

[parameter(Mandatory=$True,Position=1, HelpMessage='The message to send')]
[String]$Message,

[parameter(Mandatory=$True,Position=2, HelpMessage='The host UDP port to send the message to')]
[Int]$Port
)
Write-Host "Message to send: $Message"
$udpclient=new-Object System.Net.Sockets.UdpClient
$b=[Text.Encoding]::ASCII.GetBytes($Message)
$bytesSent=$udpclient.Send($b,$b.length,$Hostname, $Port)
write-host "Sent: $b"
$udpclient.Close()

}

Send-UDPMessage -Hostname $Hostname -Message $Message -Port $Port

Using these scripts is simple:

• First, you run Receive-UDPMessage.ps1 on the receiving host like so:
  
  Note: If the script can’t bind to the port because it is being used by another application, it will throw an error. If that happens, you will need to temporarily stop that application.
• Next, you run Send-UDPMessage.ps1 on the sending host like so:
  
• If UDP port isn’t blocked, the receiving host should get the message the script will end. If it is blocked, you’ll get nothing.
  

For a sanity check, you can also  try running both scripts on the same host to confirm it works (use localhost for the Hostname parameter).

Before I run off and claim sole credit for these scripts, I need to say that the original idea for them came from this page. I merely refined things a bit. Best of luck with your UDP troubleshooting!

Windows could not configure one or more system components. To install Windows, restart the computer and then restart the installation.

Bummer. Fortunately, since the image was serviced offline and nothing else had changed, I could reasonably assume that one of the patches was the culprit. But which one? To find out, I rebooted the system into Windows PE and opened C:\Windows\Panther\setuperr.log. Here’s what I found…

2013-01-03 18:11:12, Error                 CSI    000000fb (F) Done with generic command 8; CreateProcess returned 0, CPAW returned S_OK
    Process exit code 4294967295 (0xffffffff) resulted in success? FALSE
    Process output: [l:117 [117]"ERROR - .NET 4.0 is not installedERROR - CLRCreateInstance call failed, 0x80004001.
ERROR - Initialization failed.
"][gle=0x80004005]
2013-01-03 18:11:12, Error      [0x018007] CSI    000000fd (F) Failed execution of queue item Installer: Generic Command ({81a34a10-4256-436a-89d6-794b97ca407c}) with HRESULT HRESULT_FROM_WIN32(14109).  Failure will not be ignored: A rollback will be initiated after all the operations in the installer queue are completed; installer is reliable (2)[gle=0x80004005]
2013-01-03 18:11:14, Error                 CSI    00000107 (F) Done with generic command 9; CreateProcess returned 0, CPAW returned S_OK
    Process exit code 4294967295 (0xffffffff) resulted in success? FALSE
    Process output: [l:117 [117]"ERROR - .NET 4.0 is not installedERROR - CLRCreateInstance call failed, 0x80004001.
ERROR - Initialization failed.
"][gle=0x80004005]

It turns out that one of the updates that was installed in the offline WIM had a .NET 4.0 dependency, but the base Windows 7 SP1 image does not have .NET 4.0 installed. I would have expected the DISM utility to simply detect that .NET 4.0 was a prerequisite and skip over the update, but apparently it didn’t, or maybe there’s an issue with the update itself. At any rate, there’s no way to inject .NET 4.0 into an offline image – it requires unsealing, installing .NET 4.0, and resealing. Instead, I opted to remove the misbehaving update. To figure out which one it was, I opened setupact.log and looked for additional details that weren’t in the error log. I found these lines prior to one of the errors:

2013-01-03 18:11:12, Info                  CSI    000000f2 Begin executing advanced installer phase 38 (0x00000026) index 59 (0x0000003b) (sequence 98)
    Old component: [l:0]""
    New component: [ml:344{172},l:342{171}]"Microsoft.PowerShell.Commands.Utility-Gac.Resources, Culture=en-US, Version=7.1.7601.16398, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=x86, versionScope=NonSxS"
    Install mode: install
    Installer ID: {81a34a10-4256-436a-89d6-794b97ca407c}
    Installer name: [15]"Generic Command"

Using Google-fu, I was able to determine that the failing component was part of KB2506143: Windows Management Framework 3.0 for Windows 7 SP1 and Windows Server 2008 R2 SP1. From there, I just needed to mount the WIM and remove the update using DISM:

dism /image:TEMP\entx64mount /remove-package /packagepath:Updates\x64\Windows6.1-KB2506143-x64.cab

After that, Windows Setup continued happily ever after

Normally, to recover files from a failing drive that still has its filesystem intact, I would pull the drive, hook it up to a working system, and start copying files, skipping over files and directories that I didn’t need or that produced IO errors. With this drive, things were a bit different. The drive is Bitlocker enabled, which meant that in ordre to retrieve files, the drive needed to be unlocked or decrypted on a Bitlocker-aware system (i.e. one with Windows 7), using the Bitlocker recovery key to decrypt the data.

The good news is that I didn’t have anything important on the drive that wasn’t backed up, so I wasn’t desperate to recover its contents. But this was the first failed Bitlocker-enabled drive I’d encountered, and I thought it was a great opportunity to experiment to see how data on an encrypted drive can be recovered. It turns out that this can be a bit challenging on a failing drive where the success of IO operations isn’t always consistent, but it’s certainly possible to do.

Using the Explorer GUI

After removing the dying drive from the laptop, I connected it to another Windows 7 workstation using a USB-to-SATA adapter. The drive appeared in My Computer and even had the “Lock” icon next to it, indicating that it was a BitLocker drive:

Double-clicking the drive icon in My Computer launched Wizard to unlock/decrypt the drive, which then prompted me to enter my BitLocker recovery key (if you don’t have this, I think you’re screwed).

I proceeded to enter the key and hit Next. At that point, the interface stopped responding and I was unable to kill the process through task manager, or even by initiating a system restart. Disconnecting the drive didn’t help either. Eventually, I used the power button on the workstation to power cycle the system. After the power cycle, I tried again and encountered the same behavior. At this point, it seemed like the failing drive was too damaged to use this method, so I went searching for other ways that I might unlock or decrypt the drive.

Manage-bde

After some searching, I found the Windows command line utility, Manage-bde. Among other things, this utility can be used to unlock a Bitlocker drive. To do so, I launched PowerShell with administrative rights and enterred the following command:

manage-bde -unlock I: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456

The result looked promising:

Unfortunately, when I went to access the drive from My Computer, explorer froze and the contents of the root folder never appeared. Once again, it took a power cycle to get things working correctly. Why might this be? My guess is that there is a kernel-mode driver that’s used when mounting Bitlocker drives and doesn’t handle disk read timeouts very well, but I didn’t go into any in-depth debugging to confirm this. After all, strange things are expected to happen when a drive begins to fail.

Repair-bde

Since Manage-bde failed, I decided to try another command line utility for Bitlocker disks, Repair-bde. Unlike Manage-bde, Repair-bde appears to be specifically designed for accessing data from a damaged Bitlocker disk:

Accesses encrypted data on a severely damaged hard disk if the drive was encrypted by using BitLocker. Repair-bde can reconstruct critical parts of the drive and salvage recoverable data as long as a valid recovery password or recovery key is used to decrypt the data.

Unlike Manage-bde, the Repair-bde utility does not include a command to unlock the drive. Instead, the contents of the drive are sequentially decrypted and copied to a separate volume or image. you can also write the decrypted contents back to the source disk itself, but this is definitely not recommended if the drive is damaged and/or failing. Below is the Repair-bde command I used:

repair-bde I: C:\Recovered.img -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456 -Force

At first, this looked like it was going to work. The drive decryption process proceeded at a steady rate until it reached 17%, where the reads began to fail. With this particular drive, the read timeouts were excessive, taking 2+ minutes for each failed read to timeout. I tried changing the disk timeout, but the read timeout performance did not improve. Although I couldn’t find any definitive answers through online research, it seems like many SATA drives have have a firmware-based timeout. It turns out that some hard disk drives enforce a timeout in their firmware. In some cases, the firmware timeout can be adjusted (possibly through the ERC/TLER/CCTL setting?). For this disk, it wasn’t possible.

I let repair-bde run overnight, but the next morning it was still at 17%. Since I had no idea how many bad or unreadable sectors were on the disk, I imagine it would have taken weeks to complete at this pace. It would be ideal if Repair-bde could skip over sections of the disk, but I could not find an option for doing so.

RIPLinux and ddrescue

At this point, I decided it was time to change my strategy. The main problem was that disk timeouts were making it impossible to recover data using Repair-bde, and were probably factoring into to the issues I had when unlocking the drive with Manage-bde. I reasoned that, if I could capture recoverable parts of the disk into an image, I should be able to mount it in Windows and then unlock it. I started looking at ways to capture the raw (encrypted) data from the disk. I came across a wiki page that contained information about a Linux distribution called RIPLinux, which included a tool named ddrescue. Ddrescue performs a sector-by-sector copy of a disk. This is something that many other imaging utilities are capable of doing. However, ddrescue is much more resilient. Where other imaging tools will choke and die on bad sectors (*cough* Ghost), ddrescue gracefully recovers from an encounter with an unreadable sector, and skips ahead to another group of sectors. After an initial pass, it can then go back and retry the skipped sectors in smaller groups, maximizing the amount data that is recovered.  The more passes performed, the more data retrieved (and the more time it takes to run – days or even weeks depending on state of the drive). Even better, ddrescue is restartable. If your capture is interrupted, simply type the same command as before (pointing to the associated ddrescue log), and it picks up right where it left off.

In brief, here are the steps you can follow to use this tool:

1. Download the RIPLinux ISO and the Universal USB Installer (alternatively, you can skip step 2 and burn the ISO to CD instead)
2. Connect an empty USB drive (it will be formatted), launch Universal USB Installer, select RIPLinux as the distribution, browse to the RIPLinux ISO you downloaded, then click Create
3. Connect the bad drive, and an empty good drive of equal or greater size to your “recovery system” and boot from the USB drive or CD containing RIP Linux.
4. At the login prompt, type ‘root’ and press enter. You’ll need to identify and drives now, which is arguably the most difficult part of this process if you’re a Linux novice.
   1. At the shell prompt, type: fdisk -l
   2. Identify and write down the device names for the bad drive and the good drive based on output of fdisk – l. For example, the first disk is usually /dev/sda and the second disk might be /dev/sdb. Ignore the partition names (i.e. /dev/sda1), if there are any.  Tip: To scroll up and down in the console: Shift + Page Up and Shift + Page Dn
   3. Check, double check. It is very important that you correctly identify these disks!  Getting them mixed up could mean accidentally overwriting data on the bad drive! If you’re unsure, you can use the parted -l command, which lists the model of each drive in addition to its partitions.
5. Run ddrescue:

   ddrescue /bad/drive /good/drive rescue.log -r -1 -a 10000 -d

   -r -1 = Retry infinity times
   -a 10000  = Sets minimum read rate to 10,000 bytes. If the read rate goes below this, ddrescue will skip ahead a variable amount, and mark that area for retry on the next pass (if you choose to do one)
   -d = Use direct disk access
   There are many other options, so feel free to change things up a bit.

6. Wait for ddrescue to complete a pass – this will take a while. After the pass completes, you can see how much data ddrescue has recovered. If you’re satisfied, you might stop here. Otherwise, you can perform another pass, and ddrescue will try to recover as much of the parts it skipped over as possible. The more passes run, the more data that should be recovered – though the returns will usually be lower with each pass.

With ddrescue finished, connect the good drive to a Windows 7 system. If all goes well, Windows should detect that the drive is BitLocker-encrypted, and you should be able to unlock it by double clicking the drive in My Computer and supplying your recovery key. You can also try the repair-bde commands mentioned above if this doesn’t work.

Achievement Unlocked.

If you’d prefer to write the recovered contents of the disk to a disk image, you can do that. In fact, that’s actually what I did in my case so that I could also write the ddrescue log file to the same disk and transfer the image to other storage. To do so, there’s a few Linux-specific commands involved. I forgot to save the specific commands (doh!), but here are the general steps:

1. Format the good drive with the Linux EXT3 filesystem, then mount it. I originally tried to write the image to an NTFS-formatted drive, but the Linux NTFS driver was slow and maxed out the CPU when I tried it initially – it doesn’t handle writing to large sparse files very well.
2. Run ddrescue, pointing to a non-existent file on the mounted drive. For example:

   ddrescue /dev/sdc /mnt/sdb1/disk.img /mnt/sdb1/rescue.log -r -1 -a 10000 -d --extend-outfile=150G

3. After ddrescue runs, mount the good drive on a Windows 7 system. Since Windows doesn’t recognize EXT filesystems natively, you’ll need to grab Ext2Fsd to mount it.
4. Use VHD tool to convert the the raw disk image to a VHD.
5. Mount the VHD using Diskpart. From a command prompt, type Diskpart.exe to run diskpart, then run these commands:

   select vdisk file=disk.vhd
   attach vdisk
   assign letter=Z

6. If everything worked, the drive should appear in My Computer and you can unlock it and recover your files.

Other Thoughts

• I prefer to remove failing drives from their enclosure and either place a fan on them or put them in a cooler with ice to keep them cool. A hot failing drive is bad. Obviously, if you put the drive on ice, be sure to come up with a way to keep it dry. A wet failing drive is bad.
• You may have heard that putting drives in the freezer overnight can sometimes revive them just long enough. This may be true, but in my case it wasn’t. It’s probably moot if you’re trying to capture an image of the entire drive, since the drive won’t stay cool long enough to complete the image capture. It might work better if you could keep the drive in the freezer while recovering data, but I’ve never tried this.
• Remember, when you’re working on any failing drive, you’re on borrowed time. Chances are good that the drive’s health will continue to deteriorate, so get as much data as you can, then get out. In many cases, it makes sense to capture the contents of the drive with something like ddrescue BEFORE trying any of the other methods, in case the drive becomes completely unresponsive to IO requests during subsequent recovery attempts or additional sectors go bad.
• I would not run chkdsk /r on a failing drive, or use any software that will attempt to write to the drive.  Writing to a failing drive = bad.

RIPLinux and Ddrescue are fantastic tools to have in your data recovery arsenal, and proved crucial in the recovery of data from my dying BitLocker drive. It is not a substitute for backing up your data, but you already knew that. Hopefully, this writeup will be useful to others that need to rescue their data!

Scripting the cookies and passing them is probably possible, but I felt it was stretching the solution too far, so I adapted the script to use the undocumented SOAP web service instead. The script is below.

There are several things that I dislike about Dell’s AssetService web service:

1. It’s completely undocumented, and no one really knows what the guid and applicationName parameters are meant to do. I haven’t found anything indicating that it’s even a production service.
2. The descriptions returned for each entitlement (warranty record) aren’t as well formatted.
3. Sometimes, it doesn’t return the list of entitlements, so the script needs to be run again until it does.

Alas, this is going to have to work for now until a better solution presents itself. If you’ve found a better solution, please share in the comments.

'=====================================================================
'    Dell Warranty Grabber
'    Author:     Matthew Boyd (iboyd.net)
'    Date:        2/14/2012
'
'    This is  an example of how to query the Dell asset information
'    web service for warranty information and parse the XML result.
'    values are then written to the registry of the local
'    computer. FYI: Sometimes, the web service doesn't return any
'    entitlements (warranties), but then returns them after
'    subsequent requests.
'
'    Usage:    cscript.exe DellWarrantyGrabber.vbs
'
'    Note: This must be run under an account with admin rights.
'    This script is provided AS IS with no support or warranties.
'    Use at your own risk!
'=====================================================================
Option Explicit
Dim SoapRequest
Dim url, regkey, svctag
Dim warrantyRows, warrantyCols
Dim objShell, objXML, objWMI, objHTTP, NodeList
Dim i, result

SoapRequest = "<?xml version=""1.0"" encoding=""utf-8""?> <soap:Envelope xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope/""> <soap:Body> <GetAssetInformation xmlns=""http://support.dell.com/JigsawWebServices/""> <guid>11111111-1111-1111-1111-111111111111</guid> <applicationName>Warranty Information Lookup</applicationName> <serviceTags>!SERVICETAG!</serviceTags> </GetAssetInformation> </soap:Body></soap:Envelope>"

url = "http://xserv.dell.com/jigsawwebservices/AssetService.asmx"
regkey = "HKEY_LOCAL_MACHINE\Software\DellWarrantyInfo"
set objShell = WScript.CreateObject("WScript.Shell")
set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")

If InStr(UCase(objWMI.ExecQuery("Select Manufacturer From Win32_ComputerSystem").ItemIndex(0).Manufacturer), "DELL") = 0 then Err.Raise 2, "This is not a Dell dude!", "No Service Tag"

svctag = Trim(objWMI.ExecQuery  ("Select SerialNumber from Win32_BIOS").ItemIndex(0).SerialNumber)

wscript.echo "Service Tag: " & svctag
SoapRequest = Replace(SoapRequest, "!SERVICETAG!", svctag)
result = objShell.Run("reg.exe delete '" & regkey & "' /f", true)
If not result = 0 then Err.Raise result, "Unable to delete registry key!", "Code " & result

result = objShell.Run("reg.exe create '" & regkey & "' /ve", true)
If not result = 0 then Err.Raise result, "Unable to delete registry key!", "Code " & result

Set objHTTP = CreateObject("Msxml2.XMLHTTP")
objHTTP.open "POST", URL, false
objHTTP.setRequestHeader "Content-Type", "text/xml"
objHTTP.setRequestHeader "SOAPAction", "http://support.dell.com/JigsawWebServices/GetAssetInformation"
objHTTP.send SoapRequest

result = objHTTP.responseText

Set objXML = CreateObject ("Msxml2.DOMDocument")
objXML.LoadXml result

If not objXML.SelectSinglenode ("//faultstring") is nothing then
    Err.Raise 1,  "Error:" & objXML.SelectSingleNode("//faultcode").text, Trim(objXML.SelectSingleNode("//faultstring").text)
End If
wscript.echo objXML.xml
Set NodeList = objXML.SelectNodes("//Asset/Entitlements/EntitlementData")
 wscript.echo NodeList.length & " results returned: "

For i = 0 to NodeList.length - 1
set warrantyCols = NodeList.item(i)
wscript.echo Mid(warrantyCols.SelectSingleNode("ServiceLevelDescription").text,4)

objShell.regWrite regkey & "\" & i & "\", ""
objShell.regWrite regkey & "\" & i & "\Description", Mid(warrantyCols.SelectSingleNode("ServiceLevelDescription").text, 4)
objShell.regWrite regkey & "\" & i & "\Provider", warrantyCols.SelectSingleNode("Provider").text
objShell.regWrite regkey & "\" & i & "\Entitlement Type", warrantyCols.SelectSingleNode("EntitlementType").text
objShell.regWrite regkey & "\" & i & "\Start Date", Left(warrantyCols.SelectSingleNode("StartDate").text, 10)
objShell.regWrite regkey & "\" & i & "\End Date", Left(warrantyCols.SelectSingleNode("EndDate").text, 10)
objShell.regWrite regkey & "\" & i & "\Days Left", warrantyCols.SelectSingleNode("DaysLeft").text

Next

Well, some people will tell you that Wake-on-LAN (WoL) is the solution. It’s true that, with WoL, you should be able to wake machines overnight to perform tasks — in theory at least. I say in theory because, any sysadmin that has tried to use WoL to wake and manage many workstations (100+) over multiple subnets will tell you that Wake-on-LAN is no magic bullet. There are several reasons for this:

1. To wake up a workstation with Wake-on-LAN, the workstation’s network adapter must be properly configured to receive WoL’s Magic Packets (trust me, these packets are much less magical than their name implies). This can be a lot more difficult than it sounds, especially if you need to script these settings for automated configuration.
2. In most environments, WoL packets will not work across subnets, so you need at least one device on each subnet that can send WoL packets. You’ll also need some sort of mechanism (usually software) to tell sender devices to send packets on their subnet to wake them up.
3. Many wireless network adapters do not support WoL, and the ones that do tend to have inconsistent results with receiving WoL packets. If you have workstations that only connect to the network via wireless, this is a problem.
4. If the workstation is disconnected from the LAN, the WoL packet won’t make it.

Scheduled Wakeups

WoL is very useful for many situations, especially for impromptu wakeups. But if you want your workstations to wake from standby at night, or any time, you may not want to depend soley on WoL. What you really need is something that tells Windows to resume from standby on a schedule. But how? Well, Microsoft Windows actually includes the capability to resume from standby at certain times. This functionality is a part of the Task Scheduler service, and it can be enabled by simply clicking a check box:

With the “Wake the computer to run this task” checkbox set on a scheduled task, the system will resume from standby at whatever time interval has been configured on the Triggers tab. It is important to note, however, that this won’t work if the system is completely powered off.

The next question is, what should the task do once it has woken up the system? The answer is, just about anything. For example, it could run a script that starts Windows Update, run a virus scan, or start a backup. If you can script it or call it from the command line, you can do it. Here’s a simple example of how you might keep the system awake for at ~10 minutes by using the ping command:

Scripting Wakeups

Alright, we can use a scheduled task to wake workstations. That’s great, but not very useful unless we can use a script to automate the creation of a task that does this. As you may already know, a scheduled task can be created with the command line utility: SCHTASKS.EXE. This is a relatively powerful utility for creating tasks, and once you understand all of the command line options, creating a task with this utility is fairly straightforward:

schtasks /create /TN "My Wakeup Task" /SC DAILY /ST 23:00 /TR "ping.exe 169.1.1.1 -n 600 -i 1 -w 1000" /RU "SYSTEM"

Unfortunately, it appears as though there’s no way to set “Wake the computer to run this task” via SCHTASKS. However, Windows Vista and 7 come with a robust Task Scheduler API that can configure this setting. I wrote a VB script that does just that:

'  Name:    ScheduledTaskSetWakeToRun.vbs
'  Author:    Matthew Boyd (iboyd.net)
'  Date:    10/13/2010
'  Purpose:    Enables or disables the "Wake the computer to run this task" setting on Windows Vista and Windows 7 systems.
'        It seems that in order to do this successfully, both in the GUI or via this script,the task compatibility
'        mode must be set to "2.0" or else the setting gets reverted.
'  Usage:    cscript.exe ScheduledTaskSetWakeToRun.vbs "" [enable | disable]
'  Example:    cscript.exe ScheduledTaskSetWakeToRun.vbs "My Scheduled Task" enable
'        The command above would set "Wake the computer to run this task" to enabled.

Option Explicit

Const TASK_UPDATE = &H4
Const TASK_DONT_ADD_PRINCIPAL_ACE = &H10

Dim TaskName, EnableWakeToRun, objTaskService, objRootFolder, objTask, objDefinition

If Wscript.Arguments.Count < 1 Then
 Err.Raise 1, "Invalid command line arguments!"
Else
 TaskName = Wscript.Arguments.Item(0)
End If

Wscript.echo "Task Name: " & TaskName
If Wscript.Arguments.Count < 2 Then 'Set EnableWakeToRun to true by default if enable/disable was not specified.
 EnableWakeToRun = true
 wscript.echo "Action: ENABLE 'Wake the computer to run this task'"
ElseIf UCase(Wscript.Arguments.Item(1)) = "ENABLE" Then
 wscript.echo "Action: ENABLE 'Wake the computer to run this task'"
 EnableWakeToRun = true
Else
 wscript.echo "Action: DISABLE 'Wake the computer to run this task'"
 EnableWakeToRun = false
End If

Set objTaskService = CreateObject("Schedule.Service")
objTaskService.Connect
Set objRootFolder = objTaskService.GetFolder("\")
Set objTask = objRootFolder.GetTask ("\" & TaskName)

Set objDefinition = objTask.Definition
wscript.echo "Current WakeToRun Setting: " & CStr(objDefinition.Settings.WakeToRun)
wscript.echo "Current Compatibility Setting: " & objDefinition.Settings.Compatibility
wscript.echo "---"
objDefinition.Settings.WakeToRun = EnableWakeToRun
objDefinition.Settings.Compatibility = 2
objRootFolder.RegisterTaskDefinition objTask.Name, objDefinition, TASK_UPDATE or  TASK_DONT_ADD_PRINCIPAL_ACE, , , objDefinition.Principal.LogonType

Set objTaskService = CreateObject("Schedule.Service")
objTaskService.Connect
Set objRootFolder = objTaskService.GetFolder("\")
Set objTask = objRootFolder.GetTask (TaskName)
wscript.echo "New WakeToRun Setting: " & CStr(objTask.Definition.Settings.WakeToRun)
wscript.echo "New Compatibility Setting: " & objDefinition.Settings.Compatibility

To use this script, create a task first by using SCHTASKS. Then, run a command similar to this:

cscript.exe ScheduledTaskSetWakeToRun.vbs "My Scheduled Task" enable

The script will output both the previous and new values of the “WakeToRun” setting. You can verify that it worked by opening the Task Scheduler GUI and verifying that “Wake the computer to run this task” is set. This script can also be used to disable this setting.

You may also notice that the code in this script sets the “task compatibility mode” version to 2. I found issues with tasks that were using a different compatibility mode. It seems that “Wake the computer to run this task” would always be reverted, even if it was set through the Task Scheduler GUI. I believe the only disadvantage to changing the compatibility mode is that the task will not be backwards compatible with Windows XP.

By using a combination of Wake-on-LAN and scheduled wakeups, it’s much easier to successfully manage and maintain workstations in standby with better precision and accuracy. Also, by performing maintenance tasks overnight, you can keep workstations reliable without impacting the end user. It’s a win-win situation!

Since our users don’t have administrative rights they couldn’t complete this this operation, and the UAC prompt would continue to occur at every logon.  If I entered administrator credentials or logged in as an administrator, the UAC prompt went away for all users. But if I uninstalled the display adapter via Device Manager and scanned for hardware changes, the prompt came back. I proceeded to troubleshoot, but without much success:

• Everything in Setupapi.offline.log indicated that the driver was successfully added to the offline image.
• The issue affected any system that had an ATI Radeon HD display adapter, regardless of the model.
• I had used previous versions of ATI Catalyst display drivers, including 9.12, without any problems. As it turns out, the UAC prompt began to appear beginning with Catalyst 10.1 and continued through the current version (10.6).
• According to Device Manager, the display adapter was already installed and working properly. If I entered administrator credentials at the UAC prompt, no additional or new devices appeared in Device Manager.

Maybe the UAC prompt doesn’t seem like a big deal, but when you have 5000+ computers that displaying this annoying prompt at every logon, going around to each one and entering administrator credentials isn’t an option. I opened a support case with our system vendor, but after a month without much progress, I started digging deeper on my own.

One thing that I had overlooked originally was setupapi.dev.log, which tracks hardware device installs. I opened this log on a system that exhibited the UAC prompt behavior and began sifting through the entries. I found the install section for the ATI Radeon device. At first, it looked liked everything was fine. The driver installed successfully and the section closed with [Exit status: SUCCESS]. I then began to read through every line to see if there were any other clues. Finally, I found something:

 dvi:      {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 13:58:19.543
 dvi:           CoInstaller 1: Enter 13:58:19.543
 dvi:           CoInstaller 1: Exit
 dvi:           Class installer: Enter 13:58:19.543
 dvi:           Class installer: Exit
 dvi:           Default installer: Enter 13:58:19.606
 dvi:           Default installer: Exit
 dvi:      {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 13:58:19.606
 ndv:      Device has a Finish Install Action that needs to be run.

The last line is what caught my attention. I searched through the rest of the log for the entry Device has a Finish Install Action that needs to be run. Sure enough, the ATI display adapter was the only device that had this status. I began looking for more information about DIF_NEWDEVICEWIZARD_FINISHINSTALL. This eventually led me to the Windows DDK documentation, where I learned about Finish-Install Actions:

After core device installation is complete for a device, Windows checks whether the CONFIGFLAG_FINISHINSTALL_ACTION flag or the CONFIGFLAG_FINISHINSTALL_UI flag is set for the device. If either of these flags is set for a device, Windows queues a finish-install process that performs the finish-install actions specific to the device. The process executes in the user’s context.

The finish-install process runs only in the context of a user with administrator credentials at one of the following times:

• The next time that a user who has administrator credentials logs on while the device is attached.
• When the device is reattached.
• When the user selects Scan for hardware changes in Device Manager.

If a user is logged on without administrative privileges, Windows prompts the user for consent and credentials to run the finish-install actions in an administrator context.

Arrrrrgh! It seems that this behavior is by design!? I’m not sure why I haven’t come across another driver that exhibits this behavior, or why ATI decided to implement this behavior beginning in Catalyst 10.1.

The Finish-Install Action

Next, I decided to use Process Monitor to figure out what the Finish-Install action was doing. With Process Monitor running, I entered administrative credentials into the UAC prompt and let the install complete. I then began filtering out irrelevant Process Monitor entries to find out what what was happening during the Finish-Install action. As far as I could tell, it was setting the registry value INFName under HKLM\SOFTWARE\ATI Technologies\Co-installer to the name of the INF that was used to install the driver. That’s it.

Goodbye, Finish-Install Action

Since this seems to have little, if any, impact on the functionality of the display driver, I began searching for a way to skip or disable the Finish-Install actions. I searched through the Windows DDK documentation and came up with nothing. I also had Google searches coming out the wazoo.

Finally, I used Process Monitor again to see if I had missed anything during the first try. It turns out I did: The registry value ConfigFlags under HKLM\System\CurrentControlSet\Enum\PCI\VEN_1002&DEV_9540&SUBSYS_00021028&REV_00\4&10ef49db&0&0008 was being set to 0×0.  I went back and looked found that, after the display adapter is installed and before the UAC prompt, ConfigFlags is set to 0×00020000. As it turns out, this is the enumerated value for CONFIGFLAG_FINISHINSTALL_ACTION. I tried to modify the ConfigFlags value, but it turned out that only the SYSTEM account had permissions to do that. So I grabbed PSExec and ran this command:

PSEXEC -s REG ADD HKLM\System\CurrentControlSet\Enum\PCI\VEN_1002&DEV_9540&SUBSYS_00021028&REV_00\4&10ef49db&0&0008 /v "ConfigFlags" /t REG_DWORD /d 0 /f

Finally, the UAC prompt went away.

Note: If decide to try the command above, be aware that the registry path referenced will probably differ from yours. The names of the registry keys vary depending on what ATI video card you are using. VEN_1002&DEV_9540&SUBSYS_00021028&REV_00\4&10ef49db&0&0008 refers to the Radeon HD 4550 video card on the machine that I was using to troubleshoot. One way to solve this is by writing a VBScript that searches for ATI display adapters under HKLM\System\CurrentControlSet\Enum\PCI and verifies that ConfigFlags is set to 0×0.

Important: Due to changes to Dell’s website, the script below no longer works. An updated script is available on this page.

Updated: 2/14/2012

This is a VBScript that I wrote a few months ago as an example of how to retrieve warranty information from the Dell website. The script writes warranty information to subkeys under HKLM\Software\DellWarrantyInfo in the registry.

Dell doesn’t provide a web service for querying warranty information (that I know of), so I had to scrape the HTML. That means this script may stop working properly if Dell makes changes to the layout of their warranty information page. I wish Dell provided a more reliable method for retrieving warranty information.

Update 1/3/2011: Thanks to Patrick for letting me know that dell added a new column to the warranty information table. I updated the script to reflect this.

'=====================================================================
'	Dell Warranty Grabber
'	Author: 	Matthew Boyd (iboyd.net)
'	Date:		3/25/2010
'
'	This is  an example of how to query the Dell website for
'	Warranty Information and parse the HTML source.
'	values are then written to the registry of the local
'	computer.
'
'	Usage:	cscript.exe DellWarrantyGrabber.vbs
'
'	Note: This must be run under an account with admin rights.
'	This script is provided AS IS with no support or warranties.
'	Use at your own risk!
'=====================================================================
Option Explicit

Dim url, regkey, svctag
Dim warrantyRows, warrantyCols
Dim objShell, objIE, objWMI
Dim i, result

url = "http://support.dell.com/support/topics/global.aspx/support/my_systems_info/details?c=us&cs=RC956904&l=en&s=hied&~lt=bodyonly&~wsf=tabs&servicetag="
regkey = "HKEY_LOCAL_MACHINE\Software\DellWarrantyInfo"
set objIE=createobject("internetexplorer.application")
set objShell = WScript.CreateObject("WScript.Shell")
set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")

If InStr(UCase(objWMI.ExecQuery("Select Manufacturer From Win32_ComputerSystem").ItemIndex(0).Manufacturer), "DELL") = 0 then Err.Raise 2, "This is not a Dell dude!", "No Service Tag"

svctag = objWMI.ExecQuery  ("Select SerialNumber from Win32_BIOS").ItemIndex(0).SerialNumber

result = objShell.Run("reg.exe delete '" & regkey & "' /f", true)
If not result = 0 then Err.Raise result, "Unable to delete registry key!", "Code " & result

result = objShell.Run("reg.exe create '" & regkey & "' /ve", true)
If not result = 0 then Err.Raise result, "Unable to delete registry key!", "Code " & result

objIE.navigate url & svctag
do while objIE.readystate<>4 : wscript.sleep 50 : loop

set warrantyRows = objIE.document.getElementsByTagName("table").item(1).getElementsByTagName("table").item(2).getElementsByTagName("table").item(0).getElementsByTagName("tr")

For i = 1 to warrantyRows.length - 1
set warrantyCols = warrantyRows.item(i).getElementsByTagName("td")

wscript.echo warrantyrows.item(i).innerText

objShell.regWrite regkey & "\" & i & "\", ""
objShell.regWrite regkey & "\" & i & "\Description", warrantyCols.item(0).innerText
objShell.regWrite regkey & "\" & i & "\Provider", warrantyCols.item(1).innerText
objShell.regWrite regkey & "\" & i & "\Warranty Extension Notice", warrantyCols.item(2).innerText
objShell.regWrite regkey & "\" & i & "\Start Date", warrantyCols.item(3).innerText
objShell.regWrite regkey & "\" & i & "\End Date", warrantyCols.item(4).innerText
objShell.regWrite regkey & "\" & i & "\Days Left", warrantyCols.item(5).innerText

Next

There were many scenarios in past versions of Windows where workstations configured to enter standby after a certain period of idle time would refuse to do so, often without many clues as to why. This behavior is commonly (and cleverly) referred to as PC insomnia. While Windows 7 computers can still suffer from insomnia, the latest Windows OS now includes new tools and settings to troubleshoot and resolve it.  There are a variety of things that may prevent a computer from properly entering standby when idle. Common reasons include hardware driver issues, service issues, and open file shares. Windows XP did not include any tools that could help pinpoint what was keeping the system awake, which often made finding the culprit a guessing game. Thankfully, the command line utility POWERCFG.EXE was updated in Windows 7 to include two new options that assist with tracking down insomnia issues.

If you haven’t already, you should check out my previous article about power management in Windows 7 in order to learn about power profiles and POWERCFG.EXE commands.

POWERCFG -REQUESTS

One way to troubleshoot Windows 7 insomnia issues, is the POWERCFG.EXE -REQUESTS command. This command can be used to display a list of applications and drivers that have made requests to prevent the computer from entering standby.

In the example above, there are actually two Windows components that are preventing the system from entering standby. The first issue is that Windows wants to keep this particular computer awake because a remote host is connected to a share on the computer . If this computer was acting as a network file server, that would probably be a good thing. But it’s not, so we either need to prevent the computer from sharing files at all, or allow it to enter standby regardless of whether a remote host is connected to a file share. The other issue is that Windows wants to keep this computer awake because it’s connected to a remote file share. While there are probably cases where this behavior is desired, I want Windows to enter standby regardless of whether or not the computer is connected to a remote network share. Otherwise, most workstations would never enter standby! Both of these issues can normally resolved by changing a few hidden power options, which is covered later in this article.

POWERCFG -ENERGY

In a some cases, it may also be useful run POWERCFG.EXE -ENERGY. This command performs a more thorough investigation  in order find potential power management issues, such as those that may be preventing standby. When POWERCFG -ENERGY is run, it detects common issues by monitoring the system for a period of time and capturing system settings and events that may be preventing Windows power management from working properly. When done, the results are written to a HTML file.

By default, POWERCFG.EXE -ENERGY analyzes the system for 60 seconds. However,  the analysis duration can be be set to a larger period of time to detect more sporadic events that are preventing standby. To perform an analysis for 10 minutes, run POWERCFG -ENERGY -DURATION 600. When finished, the results are written to energy-report.html,  or the filename specified with -OUTPUT <FILENAME>.

While this report is more thorough that POWERCFG -REQUESTS, it may include items that aren’t necessarily related to issues with standby. For example, the report above shows the error USB Suspend:USB Device not Entering Suspend for several USB devices on this computer. While this may affect the computer’s power efficiency at some level,  it’s not the reason that this computer was entering standby. In this case, the standby was being blocked by the  System Required Request initiated by the driver \FileSystem\srvnet. This is related to the Windows network shares, and indicated to me that that standby was  being blocked because a remote host was trying to connect to a share on the client computer. I wasn’t able to see this when running POWERCFG -REQUESTS alone.

Manually Checking Services

If neither of the tools mentioned above help pinpointthe cause of insomnia, you may want to try manually verifying that Windows Services aren’t preventing standby. This troubleshooting method is simple, but a bit tedious:

1. First, go to Start > Control Panel > Power Options and configure the current power profile so that the system enters standby after 1 minute.
2. Go to Start > Control Panel > Administrative Tools > Services. Sort the services by the status column.
3. One by one, stop services that are running. Each time you stop a service, let the computer idle for at least 2 minutes to see if it enters standby. Continue doing this until the computer enters standby. It’s probably best to begin with non-Windows services.
4. If/when the computer finally enters standby after you’ve stopped a service, make note of that service. Restart the computer so that all services are running again. Stop that particular service again and wait for the computer to idle into standby.
5. If the computer idles to standby, you have found the service that is preventing system standby.

What services could be causing insomnia? Some anti-virus applications have been known to prevent the system from entering standby for various reasons. Older or poorly-written services may also be the cause of PC insomnia.

Treating Insomnia

Windows 7 includes several power settings that may be useful for resolving PC insomnia. Interestingly, some of them are hidden and must be enabled in the system registry. Below are some common settings and methods for treating insomnia.

Allow Standby with Remote Opens

By default, Windows 7 will attempt to prevent system standby when connected to a  a remote share or file. Presumably, this is to prevent any ongoing file transfers over the network from failing due to the system unexpectedly entering standby. But there are many cases where the system is connected to a remote share and it is okay to enter standby. Windows 7 includes a setting to allow the computer to enter standby, but it may be missing from the advanced power options dialog box. This .reg file will unhide the “Allow sleep with remote opens” option AND set it to Yes for three default power profiles (Balanced, High Performance, and Power Saver) in Windows 7:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d]
"Attributes"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d\DefaultPowerSchemeValues\381b4222-f694-41f0-9685-ff5bb260df2e]
"ACSettingIndex"=dword:00000001
"DCSettingIndex"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d\DefaultPowerSchemeValues\8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c]
"ACSettingIndex"=dword:00000001
"DCSettingIndex"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d\DefaultPowerSchemeValues\a1841308-3541-4fab-bc81-f71556f20b4a]
"ACSettingIndex"=dword:00000001
"DCSettingIndex"=dword:00000001

Although the registry entries above will configure the three default power profiles, it won’t apply the settings to custom power profiles. To do that, you’ll need to find the Power Scheme GUID of the power profile you created by using POWERCFG.EXE /LIST and then run these commands:

POWERCFG.EXE /SETACVALUEINDEX <POWER SCHEME GUID> 238c9fa8-0aad-41ed-83f4-97be242c8f20 d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d 1
POWERCFG.EXE /SETDCVALUEINDEX <POWER SCHEME GUID> 238c9fa8-0aad-41ed-83f4-97be242c8f20 d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d 1

Allow Standby when Sharing Media

If the system is configured with file or media sharing enabled, Windows 7 may prevent the system from entering standby while users are connected to files or shares hosted on the system in order to prevent file transfers from being interrupted. Sometimes, media, file, and printer sharing may be enabled on the workstation without the user or the sysadmin knowing it. To make matters worse, there are some network applications installed that tend to scan network shares at regular intervals, which may prevent standby.

This behavior can be disabled by setting  “When sharing media” to “Allow Computer to Sleep” within the advanced settings of a power profile. The setting shouldn’t be hidden by default. To apply this setting to a custom Windows 7 power profile, these commands can be used:

POWERCFG.EXE /SETACVALUEINDEX <POWER SCHEME GUID> 9596fb26-9850-41fd-ac3e-f7c3c00afd4b 03680956-93bc-4294-bba6-4e0f09bb717f 0
POWERCFG.EXE /SETDCVALUEINDEX <POWER SCHEME GUID> 9596fb26-9850-41fd-ac3e-f7c3c00afd4b 03680956-93bc-4294-bba6-4e0f09bb717f 0

Add Power Request Override

While applications can request that Windows to keep the system awake, that doesn’t mean that the OS should always listen. Applications make power requests like this for several reasons. For example, Windows Update may make a request keep to computer awake while updates are being installed or a reboot is pending. It’s actually very easy to implement a power request that blocks standby, which means it could be abused by a service or process that thinks it knows what’s good for it. If the results from POWERCFG -REQUESTS or POWERCONFIG -ENERGY show that a particular service or process is making a lot of unnecessary power requests, there is a way in Windows 7 to ignore those requests. To learn more about overriding a power requests, browse to the “Overriding a Power Request” section of this Microsoft paper.

Don’t Allow System Required Policy

If you’ve tried everything but still can’t get that  insomniac system to enter standby when idle, there is one last setting that you can use in a last ditch attempt.

However,the “Allow System Required Policy” power setting may also cause Windows to ignore valid requests to keep the computer awake. Therefore, this setting should only be used if nothing else works and you’ve tried using a Power Request Override to ignore specific drivers, processes, and services. This registry entry will unhide the setting:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\A4B195F5-8225-47D8-8012-9D41369786E2]
"Attributes"=dword:00000000

To disable power request overrides for a power profile, these commands can be used:

POWERCFG.EXE /SETACVALUEINDEX <POWER SCHEME GUID> 238C9FA8-0AAD-41ED-83F4-97BE242C8F20 A4B195F5-8225-47D8-8012-9D41369786E2 0
POWERCFG.EXE /SETDCVALUEINDEX <POWER SCHEME GUID> 238C9FA8-0AAD-41ED-83F4-97BE242C8F20 A4B195F5-8225-47D8-8012-9D41369786E2 0

What about Narcolepsy?

Another common issue with Windows systems that enter standby is PC Narcolepsy.  PC Narcolepsy refers to a behavior of the Windows Operating System, where a computer that resumes standby from a Wake-on-LAN (WOL) or scheduled wakeup event will enter standby again after 2 minutes unless there is user interaction, such as pressing a key on the mouse or keyboard. In Windows XP, there wasn’t any way to change this behavior. Fortunately, Windows 7 introduces a new power option that can change the amount of time that the computer resumes from standby:  System unattended sleep timeout. However this setting is hidden in the power profile by default. Why is it hidden? I’m not quite sure. Perhaps because it could be confused with the standby timeout setting. It can be unhidden using this reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\7bc4a2f9-d8fc-4469-b07b-33eb785aaca0]
"Attributes"=dword:00000000

Once unhidden, this setting will be visible in the advanced power options dialog. However, most sysadmins need a way to automate the configuration of this setting. Like several of the settings above, this can be done if you know the GUID of the power profile that you want to set this setting on:

POWERCFG.EXE /SETACVALUEINDEX <POWER SCHEME GUID> 238c9fa8-0aad-41ed-83f4-97be242c8f20 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 <DURATION IN SECONDS>
POWERCFG.EXE /SETDCVALUEINDEX <POWER SCHEME GUID> 238c9fa8-0aad-41ed-83f4-97be242c8f20 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 <DURATION IN SECONDS>

Standby Me

Before we dive into the guts of power management in Windows 7, let’s discuss the value of taking the time to configure power management settings.  Since going green is a hot trend right now, many companies are starting to put pressure on sysadmins to find ways to squeeze power savings from a major offender to the energy grid: Computers. At many companies, workstations are left running 24×7, even when not in use. If the work week is only 40 hours, that means that many of these computers are in a Powered On with Nothing to Do (POND) state for 100+ hours per week.  As Ford recently discovered, turning computers off when they are not in use is a great way to reduce energy waste and save some serious coin!

One disadvantage to turning off computers completely when not in use is that, when a user needs to use the computer again, they have to wait for the computer to start up, then log in, then load applications and documents again. Admittedly, this a bit time consuming and frustrating for an end user.  Therefore, many sysadmins opt to put computers into a low power standby mode as a fair compromise between user experience and energy savings. Standby mode, which powers down most system components as suspends the system state to RAM, allows the user instantly resume where they left off when they last used the computer. In modern computers, standby only consumes slightly more power than when in a powered off state.

Applying Settings with POWERCFG

If you’ve used the POWERCFG utility in Windows XP, you’ll probably find one major difference in Windows 7: GUIDs. In Windows XP, a power scheme could be configured by specifying the name of the scheme in the POWERCFG command line syntax. In Windows 7, that is no longer an option. Instead, you must specify the GUID associated with a particular power scheme when configuring and activating a scheme. While POWERCFG in Windows 7 still includes a way to change the monitor, disk, and standby timeouts of the active scheme, it takes some understanding of the Windows 7 power management GUIDs to do anything beyond that. Not only are the power schemes themselves identified by GUIDs, Windows 7 uses GUIDs to uniquely identify settings and groups of settings as well. While the idea of working with GUIDs may seem like a daunting task, it’s actually pretty easy to wrap your head around once you know how to find and use these GUIDs.

The most straightforward way to get a list of power scheme, group, and setting GUIDs is to run POWERCFG -QUERY. As a side note, this command tends to generate a lot of output, so it may be wise to pipe the output to a file like this:

POWERCFG.EXE -QUERY > powercfg.txt

After running the command, the current directory should contain the powercfg.txt file with the output from POWERCFG – QUERY inside of it. Here’s what it looks like:

As you can see from the example above, POWERCFG -QUERY provides very detailed information about every power scheme and setting set in power options in a nicely indented format. At the top is the GUID associated with the power scheme (High Performance). Directly below that is the GUID that identifies the first subgroup of settings (settings belonging to no subgroup). The GUIDs that identify each setting are directly below that, with information about possible setting values.

Example

Let’s say we wanted to change the setting Require a Password on Wakeup to No within the High Performance power scheme. First, we need to use the output from POWERCFG -QUERY to find the associated GUIDs and setting index:

These values are then plugged into commands POWERCFG -SETACVALUEINDEX and POWERCFG -SETDCVALUEINDEX:

POWERCFG -SETACVALUEINDEX 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c fea3413e-7e05-4911-9a71-700331f1c294 0e796bdb-100d-47d6-a2d5-f7d2daa51f51 0
POWERCFG -SETDCVALUEINDEX 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c fea3413e-7e05-4911-9a71-700331f1c294 0e796bdb-100d-47d6-a2d5-f7d2daa51f51 0

As you may have guessed, the first command affects the computer while it’s plugged in. The second affects the computer while on battery. There’s a few things that have been implied in this example, but are worth covering in case you plan to script power settings for a fleet of computers:

• Windows includes three built-in power schemes: Balanced, High Performance, and Power Saver. These schemes are identified by the same GUID on every Windows 7 computer.
• The GUIDs that identify subgroups and power settings are the same on every Windows 7 computer.
• To create a new scheme, use this command:

  POWERCFG -DUPLICATESCHEME <POWER SCHEME GUID> <NEW GUID>
  

  The <NEW GUID> parameter is optional. If it is not specified, POWERCFG will automatically generate a new GUID.

• Remember that if <NEW GUID> is omitted, the GUID that identifies your new scheme will be different on each computer that you run this command on.

In recent years, it has become evident that Microsoft needs to port their office suite to the Word Wide Web in order to compete with Google Apps. For Office 2010, Microsoft has stepped up to the challenge by releasing a free online Office suite, appropriately named Office Web Applications. Despite being a bit rough around the edges, the applications provide an excellent idea of what direction Microsoft is headed in, and it certainly looks good.

The Word Viewer Web App provides a read-only version of the Word document inside of the browser.

In my opinion, there’s one huge advantage that Microsoft has over some (but not all) of the other competitors in the Online Office Suite market: Organizations have the option to host the Office Web Applications themselves. For organizations that can’t or don’t want to use a hosted solution, this could be huge. To get there, Microsoft has married the document management capabilities of Microsoft SharePoint with the new functionality that the Office Web Applications offer. As a system administrator, you must play the role of the priest in this wedding: Getting the Office Web Apps functionality requires a separate installation from SharePoint. The good news is that installing Office Web Apps feels relatively painless. As for the benefits? Well, imagine opening a Word document in SharePoint without ever opening Microsoft Word. Now imagine editing that document and saving it back to SharePoint without ever opening Word or even leaving your web browser. Daddy like.

From both an interface and functionality perspective, SharePoint and Office Web Apps integrate fairly well. By default, the Microsoft Word Web App opens documents in a read-only view. With this view, documents are displayed almost identically to how they look within the installed version Microsoft Word. Most text can be selected and copied to the clipboard. It’s like viewing a PDF document in a browser, but without the terrible Adobe Reader browser plug-in.

So how does the Word Web App do at actually editing documents? Well, it provides a lot of great functionality, but it does leave something to be desired.  A familiar ribbon is displayed at the top of the page, with basic tools for formatting text, inserting pictures, and creating tables. Just don’t expect all of the special features that you’re used to seeing in the installed version of Word. It is free, after all. A few of the documents I tested did not have certain formatting settings that were visible in the online editor, such as table backgrounds. I’m not surprised by that. Overall, I see this as a great way to generate quick documentation or take notes, but I wouldn’t recommend it for advanced publishing. In fact, I wouldn’t recommend any of the online document editors for advanced publishing. They just aren’t that robust.

The Word Web App provides a lot of basic document editing functionality. Just don't expect to do a mail merge through it.

One of the most significant features (if you want to call it that) of the Office Web Apps is that they work across browsers, just like SharePoint 2010. This has always been a huge pain point for me with SharePoint 2007 and a few other Microsoft web products, because they have traditionally catered to Internet Explorer, and I am a Firefox user. There is also better support for viewing SharePoint sites and Word documents from mobile devices. I’m glad that culture at Microsoft has shifted such that they realize that cross-browser (and cross-platform) support will be crucial to their success in the future and I hope they continue down that path.

I haven’t had a chance to try out the Excel Web App, or the PowerPoint Viewer. I’ll save those for another weekend. Some good news for those waiting for the production version of SharePoint and Office 2010: Microsoft just announced that these products will  launch on May 12, 2010 and RTM sometime in April. It will be interesting to see if there are any new features between the Betas and the RTMs. Regardless, I’m really looking forward to the latest iteration of these products.

If you’re looking for more information about Office Web Applications, be sure to check out the Office Web Apps blog on MSDN: http://blogs.msdn.com/officewebapps/ .