You may want to achieve some power savings, but it turns out some services or programs misbehave.
One way around this issue is to run a script when the machine resumes. We can achieve this via two OS native methods:
Task Scheduler on Vista+
WMI Event consumer on Win2K+
I am going to only show my approach for the WMI Event, but I wanted to preempt the comments about task scheduler, yes – I am aware, but there are still two advantages to running it via WMI.
Works for all Windows flavors & it is embedding the script code within WMI, so no visibility to end users that they can modify or disable.
Both methods will run the script/code as SYSTEM, which can be a problem when your issues are related to GUI apps, such as Outlook/Exchange connectivity. This limitation does not exist with the excellent 1E NightWatchman that can run scripts as the logged in user. Without NightWatchman there is no way around programming WTSEnumerateSessions () -> WTSQueryUserToken() -> CreateEnvironmentBlock() -> CreateProcessAsUser() and actually compiling an executable that our script would have to call. Maybe I will post an actual example if some requests do come in.
The main obstacle I found with WMI scripts is the deployment. Likely you want to deploy this solution on a number of machines. The classical way would be to write a MOF file and compile that via mofcomp. I decided to actually create my instances via a VBS script. Note that no matter which approach, the Instances will have to be created while running in SYSTEM. Any consumers created as a regular user would only execute if that user is specifically logged in and is a local admin.
This script will restart a specified Service on your machine. As an example only I am restarting “Wireless Zero Configuration” or in short WZCSVC which exists on all XP machines.
Each time this service stops/starts it will write into the application event log as source EAPOL. This is how you can verify the process worked.
Interesting bits worth noting from the script:
The script will force to use the 64bit version of Wscript when available, even if this script is launched via 32bit process such as the SCCM client. I do this via the WMI method Win32_Process whilst forcing to connect to the 64 bit WMI.
The following code snippet is relevant: objCtx.Add “__ProviderArchitecture”, 64 ‘Load 64bit version of WMI if available. In fact I should create another blog post just on how to escape the bit-ness via WMI of a process.
Use of vbNewLine for the script text. This is needed as VBScript is line aware and I have to somehow add the new line command into WMI. Note that vbCrLf doesn’t work for this scenario.