Recently I'm working on deploying Dell's OpenManage Client Instrumentation (OMCI) to several hundred workstations via SMS. It's a relatively simple little thing: a few setup files and command-line switches for setup.exe to install silently. It installs a service (IAP) and adds the dellomci namespace to WMI. Easy, right?

Well, no. First of all, when reinstalling OMCI something goes horribly wrong and OMCI ditches the MOFs (by default at %programfiles%\Dell\OpenManage\Client\Mofs\), thus the WMI namespace doesn't exist. This is apparent by errors in %windir%\system32\wbem\logs\mofcomp.log, e.g., "File 'C:\Program Files\Dell\OpenManage\Client\Mofs\DellOMCI_WinPrep.mof' not found!" This isn't too hard to work-around, just setup SMS to only advertise the package to systems without OMCI. Moving on....

Then I notice that during the OMCI installation it shuts down the SMS Agent Host service (ccmexec). The service doesn't crash, but gracefully shuts down. This is apparent by comparing the Application event logs from MsiInstaller for OMCI installation with entries in %windir%\system32\ccm\logs\ccmexec.log (and others). E.g., on one target workstation SMS' execmgr.log shows that the package was executed at 3:45:32 PM (as well as raising a "program started" event). The Application event log on that system has event ID 11707 at 3:45:38 PM that ISScript installation operation completed successfully, event ID 0 at 3:46:02 PM that Iap service started, and event 11707 at 3:46:27 PM that OMCI installation operation completed successfully. Back at 3:45:51, ccmexec.log has several lines starting with "Shutting down CCMEXEC...." So with things as they are, I'd never get a status back from that workstation (and SMS is disabled!) until the system is restarted.

So I modify the package to use a simple batch file, install.cmd, with the following:

\\dpserver\packages\DELL_OMCI_7.1\setup.exe /s /v/qn
net start ccmexec

This silently installs OMCI and then restarts the SMS Agent Host service. Initial testing shows that it works, CcmExec comes back after setup.exe finishes. Cool, right?

Not really. Since SMS is shutdown during installation of a package, it can't provide a clean status report. All workstations report an error status, ID 10021, "The program for advertisement "ABC2000A" failed ("ABC0000E" - "Install"). The program was able to be executed but the system was restarted unexpectedly before the program could be completed or before status could be recorded. No installation status MIF was found after the system restarted. Possible cause: The program performs a restart of the client computer when it completes, but the 'After running' setting in the program's properties is not set to Program restarts computer, or the client machine was restarted while the program was running. Solution: Verify the above. If the program does a restart when it completes, even if it only requires a restart in some cases, modify the program's properties and set 'After running' to 'Program restarts computer'."

As is often the case the status message is spot-on. It's as if OMCI asks SMS to leave a meeting and as it's walking out the door it let's everyone know it's leaving. When it comes back OMCI is no longer there, so it assumes the worst: OMCI is dead. From execmgr.log after the service is restarted: "Can not continue monitoring the program after service restart because the process exited. Assume failed." It then logs that it looks for a MIF and then raises a "program unexpected reboot" event.

Writing a MIF for this seems a bit much, but I changed the properties on the program so that SMS knows that OMCI will initiate a restart. Even though it's not initiating a system restart, since the SMS service is restarted it's effectively the same thing to SMS.

Oh PortQry, how I love thee!

I came across this little util back in July and have been using the hell out of it since. It's especially great for testing firewall configs - a quick way to test whether a specific port on a specific IP is listening.

Two things I came across recently that have been useful:

PortQry Return Code

This might be documented someplace, but I found that portqry uses the following return codes:

0 = Listening
1 = Not Listening
2 = Filtered

Those are the only three status messages that I've ever seen. An easy way to check the return code from the command line:


C:\Documents and Settings\Aaron>portqry -n www.google.com -e 80

Querying target system called:

www.google.com

Attempting to resolve name to IP address...


Name resolved to 64.233.161.147

querying...

TCP port 80 (http service): LISTENING

C:\Documents and Settings\Aaron>echo %errorlevel%
0

C:\Documents and Settings\Aaron>


So you can use portqry in another script, not worry about it's output, and just check the resultant errorlevel for the outcome. Kudos to Microsoft for coding it correctly!

PortQry Local Mode

A developer came to me today asking on what ports a specific server is listening, specifically the Apache web server. My first thought was to find some app to do a port scan. Then I remembered something from the portqry man entry:

portqry -local > portqry.txt

Run that from the server in question, then open portqry.txt. Open Task Mangler and view PIDs. I was then able to match the PIDs and find that Apache was listening on 80, 443 and 3339 - which was the port he wanted. Done and done.