Run a script when windows resumes from suspend/sleep via WMI Event Consumer

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.

Remove SQL block comments via regex

My blog is a bit quiet sometimes, and this is because I usually want to post big projects.
However I think I should also post small code snippets as they may help somebody too.
Trevor just asked about how to detect SQL block statements via regex, and I remember I had to use such a regex in order to trim a massive SQL query into 8000 chars for a classic SCCM report.
Use this Perl regex to detect SQL block comments
/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/

This will not detect comments denoted by -- which you should not use anyway :)

My next bigger project is to show WMI Event Consumer driven scripts, run scripts on resume and on PC idle btw.

Side by Side assembly issues. Error 1935.

Affected OS: Vista, 2008, Win7

Error: When attempting to install redistributable (vcredist_x86.exe) we get:
Error 1935.An Error occurred during the installation of assembly ‘Microsoft.VC90.ATL,version=”9.0.30729.4148″,publicKeyToken=”1fc8b3b9a1e18e3b”,processorArchitecture=”x86″,type=”win32″‘. Please refer to Help and Support for more information. HRESULT: 0x8007054F

When attempting to install 1E Wakeup Server 6 we get:
Microsoft.VC90.CRT,processorArchitecture=”x86″,publicKeyToken=”1fc8b3b9a1e18e3b”,type=”win32″,version=”9.0.30729.4148″ could not be found. Please use sxstrace.exe for detailed diagnosis.

Further Details:
I have established that the actual DDL’s are here:
C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2
C:\Windows\winsxs\x86_microsoft.vc90.atl_1fc8b3b9a1e18e3b_9.0.30729.4148_none_51ca66a2bbe76806

The manifests are also present. I’ve created the sxstrace log file, however these does not indicate any errors.  I am unsure why these trace logs did not show any error – not helpful.

MS has a KB for error 1935: http://support.microsoft.com/kb/970652
This KB did not help: Under HKEY_LOCAL_MACHINE\COMPONENTS, the offending keys do not exist.

The resolution:
Windows has a further log file called CBS.log for the component -based servicing also known as the trusted installer, which managed the installation of SxS. This log file indicated the presence of the pending.xml file, however the CBS.log also complained that the action cannot be found in the registry in the path the above KB discussed. It appears this server had an issue were the registry was rolled back but the pending.xml file remained. Manually renaming/deleting this pending.xml brought the CBS back into action. As with any trusted installer files you first have to wrest control of the file via taking ownership and setting new DACLs.

CBS.log file extract:
2011-11-02 13:57:46, Error                 CSI    0000e320 (F) Could not find pending.xml identifier in registry.

2011-11-02 13:57:46, Error                 CSI    0000e321@2011/11/2:18:57:46.567 (F) d:\longhorn\base\wcp\componentstore\com\store.cpp(354): Store corruption detected in function `anonymous-namespace’::QueryPendingXmlIdentifier expression: 0
RegistryCorruption on resource [50]”\Registry\Machine\COMPONENTS\\PendingXmlIdentifier”[gle=0x80004005]

Maybe it helps someone, also interesting that the error text from the CBS.log showed no goggle results at the time, looks like this log file is not very well known when it’s clearly very helpful.

The first few steps – What will this be about

This is a Tech blog! I don’t want to make it too broad, but it will mostly be about these topics:
WMI, Scripting, T-SQL, SSRS, SCCM. I will probably also cover topics related to my employer 1E at some point – but the focus is on building things, or troubleshoot existing things if I encounter particular interesting ones :)

The blogs name comes from Fully Parameterized, which to me means a tool/framework that can be easily adapted to do different tasks without having to rewrite everything.

I am Reto Egeter, and this will now be the start, and let’s see where it will take me.