One way I like to use this blog is to post responses to questions I get from my customers.  However, I typically don’t look to post unless the question meets these two pieces of criteria:

  • It does not have a simple answer which can be found easily by more robust sites such as MyITForum or SystemCenterCentral.
  • The same question is asked twice by two different customers.

If it meets those criteria I feel it is worthy to blog about it as there is a good chance there might be a third, fourth, or fifth person wondering the same thing…  The bad news is that I have a pretty good stack of these that I never seem to find the time to write a quality post.  The good news is that at least this time, I DID find some time for one of these!

So one question I have received a few times is whether or not ConfigMgr has the ability to detect and report on if the desktops and/or servers in an environment have the intended members within the local Administrators group.  Can you enforce/control this with AD GPO?  Absolutely, however, some folks have said that for external reasons, they may not be able to do this and even if they do, they may need to allow changes to some systems but not others which may limit their ability to enforce this at all. 

Again, the answer is yes, ConfigMgr definitely does have this ability – in general, you can create a DCM Configuration Item to detect and compare the membership in the Local Administrators group in the system and then compare this to the desired list of groups/members you wish to have within the Local Administrators group.  If they check out, great – the system is compliant.  If not, you can show that system or systems as being non-Compliant in any number of DCM reports supplied by ConfigMgr.

Now the magic here is in how we do this detection.  ConfigMgr DCM has a lot of built-in ways to check files, registry keys, etc. but none of these really fit this scenario very easily so we need to utilize DCM’s capability to report on the results of some sort of script which returns whether or not compliance is met or not.  DCM can use VBScript or Powershell to determine validation results.  In this example, I have chosen to create a PS script to do this?  Why PS?  Because PS is awesome and besides, it is what all the cool kids are using these days! :)

Here is my script:

$strComputer = "."
$computer = [ADSI]("WinNT://" + $strComputer + ",computer")
$Group = $computer.psbase.children.find("Administrators")
$members= $Group.psbase.invoke("Members") | %{$_.GetType().InvokeMember("Name", 'GetProperty', $null, $_, $null)}
$membercount = 0
$illegalmember = 0

ForEach($member in $members)
    {
    switch ($member)
        {
           "Administrator" {$membercount = $membercount + 1}
            "Domain Admins" {$membercount = $membercount + 1}
            "juser" {$membercount = $membercount + 1}
            default {$illegalmember = 1}
        }
    }   

If (($membercount -eq 3) -and ($illegalmember -eq 0))
    {
        Write-Host "Compliant"
    }
Else
    {
        Write-Host "NotCompliant"
    }

The section highlighted in green in the ‘switch’ part is where the magic happens.  That is, you need to create a line for each and every user or group member you wish to be in the Local Administrators group of the target system.  With the logic of this script, the result will be compliant only if each and every member returned is found in this list.  The text highlighted in red will ensure that no other extraneous groups/members are found and needs to be set to the total number of entries you expect to come back (in this case, 3) so that if extra members are in the group, this will also flag non-compliance.  The result is to Write-host ‘Compliant’ or ‘NotCompliant’ – why we do this is explained below.

Now we need to create a DCM CI and attach it to an existing DCM Baseline or create a new Baseline and associate the CI with that baseline. We can then assign that baseline to one more more ConfigMgr Collections so that we can proactively keep tabs on compliancy.

We can create whatever type of CI we wish:

image

In my example, I am using the OS CI item as I want to strictly control the OS platform that it will apply to but you could also choose ‘General CI’ if you wanted.  You just have to make sure that whatever systems you assign this CI to has the ability to properly run the script.  In this example, we are using PowerShell so by default Vista and above should be fine.  XP and lower may need to have Powershell installed.  Or you use VBScript. 

So in the new CI dialog, we need to give it a descriptive name.  We then bypass adding any ‘Objects’ as they are not needed in this CI.  In the Settings dialog we add a New Script:

 

image

In this dialog we copy-paste our script and specify that it is a PS script:

image

Clicking the Validation tab, we can set how we check for compliance.  DCM can read in the value that is outputted from the Script (thus the reason for the ‘write-host’ lines in the script) and we can use the values that are coming back to determine if this item is considered Complaint or Not Compliant.  Now you can tweak this however you wish.  In this example, I decided to simply check to see if the result is a string value of ‘Compliant’ because that is what my script will return if it checks out.  Anything else will flag an Informational ‘non-Compliance’ state which will show up in a DCM report.  My validation configuration looks like this:

image

And that is it – if the returned value is anything else, we should flag as non-compliant.  So we take our CI, attach it to a baseline and assign that baseline to a Collection of systems we wish to check.  The result might look something like this if we have non-Compliance issues in the dashboard:

image

…And we can of course drill in on the report to see exactly which system is non-Compliant, etc:

image

And yes, you can get even more sophisticated.  For example, you can have the script return the actual membership to DCM so that the non-Compliant systems report will show the conflicting memberships from each Local Admin Group.  Plus, with PS, VBScript, WMI queries, registry queries, etc., there is not much you can’t detect and report upon making DCM VERY powerful.  Also keep in mind that SvcMgr when released will have the ability to create Incidents based on non-Compliant states as they happen from within ConfigMgr so you can know dynamically when items such as the above happen in an environment so that you can take the necessary corrective action.  Pretty cool stuff…