Monthly Archives: July 2010

SCOM 2007 R2 Agent Reporting Issues with DISA/FDCC

We are in the middle of developing a new XP SP3 image for SCCM deployment to newly added workstations.  One of the applications we install with the deployment sequence is the SCOM 2007 R2 Agent.  Recently, I discovered that our test machines with the new image were not reporting to the Operations Manager Server.  Inspecting the log, I noticed a number of 21405 errors:

The process stated at <time> failed to create System.Discovery.Data, no errors detected in the output. The process exited with 1 Command executed: “C:WINDOWSsystem32cscript.exe” /nologo “DiscoverWindowsComputerProperties.js”…

Well, it turns out that the DISA Desktop Application STIG (pages 4 and 5) requires systems to have the default actions for JS and VBS files altered.

To fix this issue, both filetypes must be reassociated to run using either cscript or wscript.  There are a number of resouces on the Interweb to do this type of task.  In our case, I created a WSF script and put it into an SCCM software package to deploy to the affected computers.  I will post the script files if there is interest in them.

Special thanks to Graham’s blog post in aiding our troubleshooting of the issue.

Advertisements

WMI Query for an Installed Application

Last night, I was reading an excellent blog post by Darren Mar-Elia on why the Win32_Product class sucks.  This got me asking the question: If you wanted to create a WMI query to determine whether or not a particular application was installed on a machine, how would you do it?  A quick Google search turned up nothing useful.  Not one to shy away from a puzzle, I set out to figure a solution.

My initial approach was to try StdRegProv, but alas, the class contains only methods.  While such a class could be used in a script, it is an automatic no-go for queries (since a query only reads properties).  Now this is starting to look like the evil Sudoku puzzle I agonized over last week… 

Others on the Interweb suggested using Win32_RegistryAction class.  This is a bad idea, since the class enumerates across the ENTIRE registry.  Wanna talk slow?  Hell, you’re better off using Win32_ProductClass over this dog.  Besides, I couldn’t ever get the damn thing to work.

So instead, query the file system.  The advantage to this method is that it’s fast.  Oh, did I mention that it’s fast?  Speed cannot be underappreciated, especially if your query is tied to a GPO.  Nothing says admin-hater like a user who has to wait ten minutes to log on.

As an example, if you want to see if Office 2007 is installed (in this case, Word).  Easy enough.  Create a query as follows:

Namespace: root\cimv2
Query: SELECT * FROM CIM_Datafile WHERE Name = ‘C:\\Program Files\\Microsoft Office\\Office12\\WINWORD.EXE’

Be sure to note that you need double whacks!  If you’re really rambunctious, you can also specify that you’re looking for a particular version by adding a

AND Version = ‘X.X.X.X’

which is useful if you checking for a patch.  Of course, you have to know where the application is installed.  You DID standardize your install packages, didn’t you?

Oh and one more thing… don’t get too crazy with WMI queries in your GPOs… these suckers get eval’d EVERY refresh cycle.  So use them as little as possible and tear them down when you don’t need them anymore.

Don’t say I never helped you out…

Server Core/Hyper-V Server specific Group Policies

In our little digital wonderland, we are compelled encouraged by our security department to apply some rather draconian Group Policy Objects.  It’s a PITA, but security doesn’t care.  Since I’ve been doing these for a while, I can usually see whether or not a particular setting will f*** us before it’s implemented.  But considering there’s like three quadrillon settings, sometimes even I can’t always predict what will happen.  Here’s a little ditty about one of those times:

I was logged in on a remote session to one of our Server Core installs.  If I remember correctly, I was trying to install an unsigned driver (it was a DSM for MPIO to our SANs, for all you standard nerds).  Well, just like that hot chick you bumped into at the bar last week… the promised call never came.  No error, no freeze, nothing.  Just a new command prompt line.

After much heartache, we found that the culprit was two UAC policy settings:
– User Account Control: Admin Approval Mode for the Built-in Administrator Account (Enabled)
– User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode (3)
(Both of these are found in Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Security Options | User Account Control)

Now I can’t say whether it was the fact that the exe was unsigned, or that it expected UAC, but the installer was blocked from starting.  So how to fix this?  Easy!  With another GPO that overrides the offending settings to Disabled and Elevate without prompting, respectively.  Scope this GPO to apply only to the Server Core machine and you’ll make your SAs AND security happy!

Not content to leave well enough alone, I wasn’t satisfied with listing every single Server Core machine in the GPO scope.  Nope.  If you know me, you know I don’t like to half-ass anything; I’m a whole-ass kind of guy.  This is where WMI (where have you been all my life? I love you!) comes in.

In Group Policy Management, create a new WMI filter in the WMI filters node.  In this filter, give it a clever name (like Server Core Only).  For the query, use the default root\CIMv2 namespace and the following for the query text:

SELECT * FROM Win32_OperatingSystem
WHERE OperatingSystemSKU = 12
OR OperatingSystemSKU = 13
OR OperatingSystemSKU = 14
OR OperatingSystemSKU = 42

Assign this filter to your GPO and you can fuggedaboutit.  In case you’re wondering where I got the SKUs, they can be found here: http://msdn.microsoft.com/en-us/library/aa394239(v=VS.85).aspx (search for OperatingSystemSKU).  Note that SKU 42 is not listed; this is for Hyper-V Server.

Don’t say I never helped you out…

Need a startup/boot delay for your Windows Server?

Try and do a search on this and what you’ll get is a huge list of people bitching about how long it takes for their server to start, load group policy, login, zzzzzz.  Whatever, these SAs are losers; they have no idea why their network sucks and they’re too lazy to get under the hood and troubleshoot.

What I’m talking about are those situations where you want to intentionally delay the start of one or more servers.  A good reason for this would be if you use a SAN and said servers are expecting their LUNs to be online before they are.  In my particular case, if the SAN is not available by the time the server wants to bring them online, then they are joined in an offline state.  This just creates additional a**pain for me, which I always like to avoid.  Another situation to avoid is starting more than one node of a cluster at the same time, which can result in a deadlock situation (the bubbas at M$ say that this is no longer an issue beginning in Server 2008… let me know if anyone has first hand experience).

So in Windows Server 2003, this is pretty easy.  Just go into your System Properties | Advanced | Startup and Recovery and modify your boot.ini to give yourself an identical option (just with a different name).  This turns on the boot selection screen with the delay selected.

In Server 2008, the concept is the same, just a little trickier.  This time, you have to run it through the command line, using a tool called BCDEdit.  The advantage to this is that it works in both full install AND server core!

So here’s how you do it:

  1. Open an elevated command prompt (you forgot about UAC again, didn’t you)
  2. Enter: bcdedit /copy {current} /d “Boot Delay Placeholder” (you can call it whatever you like… and that {current} is literal.  This gives you a second option in the boot configuration.
  3. Enter: bcdedit /timeout xx where xx is the number of seconds to leave the selection menu displayed.  Personally, I use a number like 300, but feel free to use 167 instead.

Now, when the system reboots (say, after a power failure), the machine will sit there fat, dumb, and happy for the time you indicated.

Don’t say I never helped you out…