ConfigMgr Inventory of Powershell Versions

If you happen to be curious about what versions of Powershell are installed/available on your clients, here's one way to pull out the information.  Note that the regkey locations for some of this information has changed from version 2 to higher versions, so it's completely possible that a future update to Powershell and the regkey location will change again; so if that happens a modification to these .mof files will be necessary.  As of Windows 8.1; these worked to report versions of Powershell installed.

Take the --> attached <-- and inside are two .mof files.  If you are ConfigMgr 2012, place the contents of the 'posh-configuration.mof.txt' at the bottom of your <inbox location>\clifiles.src \hinv\configuration.mof file.  In your configMgr 2012 console, in Client Settings, Default Agent Settings, Hardware Inventory, Classes... Import the 'posh-to-be-imported.mof'

Wait for clients to start reporting, once you get some clients reporting, the below sql query should get you started:

;with CTE as (
  select distinct resourceid
   ,RTRIM(substring(ISNULL((select ','+PSCompatibleVersion0  
        from v_GS_PowerShell0 p1
        where p1.ResourceID=t2.resourceid for XML path ('')),' '),2,2000)) as PSCompatibleVersions0
   ,RTRIM(substring(ISNULL((select ','+PowerShellVersion0
        from v_GS_PowerShell0 p1  where p1.ResourceID=t2.resourceid for XML path ('')),' '),2,2000)) as PowerShellVersions0
   ,RTRIM(substring(ISNULL((select ','+RuntimeVersion0
        from v_GS_PowerShell0 p1  where p1.ResourceID=t2.resourceid for XML path ('')),' '),2,2000)) as RunTimeVersions0
 from v_R_System t2
)
   select distinct sys1.netbios_name0 [ComputerName]
 ,cte.RunTimeVersions0 [RunTime Versions]
 ,cte.PSCompatibleVersions0 [PS Compatible Versions]
 ,cte.PowerShellVersions0 [PowerShell Versions]
 from v_R_System sys1
 left join CTE on cte.ResourceID=sys1.ResourceID

 

 

  • Created on .

Compliance Setting to Enable WinRM

The Situation:  ConfigMgr 2012 clients can be managed remotely (and troubleshooting remotely) quite handily... if only Powershell were installed and Remote Management via Powershell (WinRM) were enabled.

This article presumes you are deploying Powershell via other means, and this routine is just 1 of several ways to get WinRM enabled, if Powershell is installed.  Note you don't have to use this at all; by far the most popular method is to simply have a GPO, or if you must, interactively login to a computer and run   winrm quickconfig -q  from a command prompt (if you have the rights).

This situation may or may not be an edge case for you... but in our environment there are a few workstations, which are ConfigMgr Clients, but which for whatever reason are not candidates for the GPO, and to have a human interactively connect to each of those machines and run the winrm config (with our settings) is cumbersome. 

I grabbed Roger Zander's Baseline from here: http://myitforum.com/cs2/blogs/rzander/archive/2013/06/21/configure-winrm-by-using-cm12-settings-management.aspx, and found that there were a few things inside that just weren't working in my environment--some old clients, or older versions of Powershell just were not being detected or remediated well.  So I tweaked it to work in my environment.  The tweaking I did may or may not work for your environment--only you can determine that.

The baseline attached is just a SAMPLE of a Configuration Item; using the settings as created if you were to run winrm quickconfig; however you or your security team may have determined not to use those defaults--you may need to modify the port used, or change the ipv4 or ipv6 listening ports.  So take the attached as-is ONLY if you know you are using the defaults, and they are acceptable in your environment.  If you've modified how WinRM is configured in your company, you will definitely need to either modify the ConfigItem detection and remediation, or not use this at all.

How to use:

  1. Import the --> Attached <--  baseline into your Compliance Settings, Baselines 
  2. PARANOIA: Deploy the Baseline to a collection withOUT checking the box about remediation.  
    1. Monitor, and for the machines which say "non-compliant", check that you really cannot remotely connect to them with Powershell Remote Management.  
    2. To a collection of those non-compliants, Deploy the baseline again, but DO check the remediation box.  
    3. Confirm that the remediation Baseline runs, and that you now can remotely connect to them with Powershell remote management. 
  3. Repeat the Paranoia steps as many times as you need to until you are comfortable that it's doing what you think it should be doing. 
  4. Once you've passed your own internal Paranoia Steps (above), you can remove the test deployments, and deploy it again to your 'main' collection, with the remediation checkbox checked.

Again, to repeat... this is just a sample.  and this sample will only be logical to use in your environment if you simply can't use a GPO to enable WinRM on all of your CM clients.  If you CAN use a GPO against your entire environment; then perhaps all you'd maybe, and I mean MAYBE want this for is to Monitor only (no remediation) and just check if the GPO is in fact getting to all your clients.  I wouldn't bother, personally; if I had a GPO that could get to every client.

Puzzling Behavior: When I was testing, more often than I was comfortable with (when using remediation enabled), client computers would report "Failed"--but at re-run they would report Compliant, and forever after report compliant.  What I suspect is happening (but couldn't verify, because a rerun was compliant) was that during Remediation, AS it was remediating one of the 1st non-compliant results... other tests would fail.  But by the time of a human (me) following up on it, WinRM was all enabled and configured and a re-run of the Baseline would indicate absolutely nothing wrong.  So... if you get a lot of failures in Remediation... just wait for your next cycle or re-run the baseline manually.  I suspect it's fine; just a timing issue.

CM12

  • Created on .

Use Compliance Settings to Disable Firefox AutoUpdates in ConfigMgr 2012

This is very much an "edge case" type of situation... but this came up internally where I work, so I thought I'd put this out there for public consumption, in case this isn't as much of an edge case as I think it is.

The -->attached<-- has only had a brief life in pilot... so if you do need this, PLEASE test thoroughly. 

The scenario / issue to be solved was this... Firefox releases updates frequently, and internally the goal was to use SCUP (System Center Updates Publisher) to deploy those updates, just like any other security update--and here's the fun part--using the exact download from mozilla (no modifications).  This tested great, but then they also didn't want the end users to get those reminders about updates... the instant Mozilla releases an update.  If the plan is to manage them with SCUP-offered updates, then they wanted the client-side Update Prompts to go away.

Unfortunately, not quite that easy with Firefox.  It's not registry keys, it's not WMI, it's two files, with specific lines inside those files, to disable updates.

What the attached Baseline will do, if you target it to your machines, is a) first look if firefox is installed (looking for firefox.exe in program files).  b) If it's there, then it'll check, and if you have "remediate" checked when you deploy the baseline, optionally create the 2 files, with the required data inside those two files.

How To Implement:

  1. Take the Attached, and import into your CM12 console (Assets and Compliance, Compliance Settings, Configuration Baselines) the Firefox Disable AutoUpdates-Baseline.cab.
  2. Once Imported, Deploy that baseline to a test collection; I recommend one with at least two boxes: one with firefox and one without; so you can confirm for yourself that it doesn't do anything when firefox is not there.

How to Check if it's working:

  1. Interactively from Firefox itself:    
    1. before deployment, in Firefox, if you go to the pull-down for Firefox (on the left), then the -> arrow by Help, then About FireFox, in the middle-ish will be a message about whether or not you are up to date.    
    2. After deployment, (and after you restart Firefox, if the Compliance Setting ran while Firefox was already open), when you go to About Firefox it will now say "Updates disabled by your system administrator"
  2. Remotely:   
    1. there are two files, and those two files need very specific things inside:  
      1. File #1: In the same folder as firefox.exe, mozilla.cfg with these exact lines:  
        lockPref("app.update.auto",false);  
        lockPref("app.update.enabled",false;
      2. file #2:  In the subfolder \Defaults\Pref, local-settings.js with these exact lines:  
        pref("general.config.filename", "mozilla.cfg");  
        pref("general.config.obscure_value", 0); // use this to disable the byte-shift

Naturally... the assumption is that you'll be forever after vigilent about deploying firefox updates using SCUP, or somehow else managing firefox deployments.  Because just like any other browser... occasionally "bad" people decide to release trojans or viruses or something else that can cause harm to your computer or company via a unpatched or old browser.  So... just because you no longer see popups about "new version is available" doesn't mean you are safe! 

  • Created on .

Local Policy Override to Disable Inventory Throttling

Although the default for Software Inventory is disabled in ConfigMgr 2012; you perhaps have enabled Software Inventory for file inventory.  If you've done so... have you noticed that on some clients it can take hours and hours and HOURS before it finishes?  Or even on some clients it never finishes; just exits with a message that it will retry later? "The system cannot continue. Cycle will be aborted and retried."  will be in the inventoryagent.log .

There's a local policy override that you can set, on each of your clients, to change the default of inventory throttling from TRUE to FALSE.  Inventory throttling, in this case, is when you have multiple software inventory rules, like perhaps... to inventory *.exe from %programfiles%, and then another one for *.exe from c:\SomeLocalFolder.  and inbetween rule 1 and rule 2 it waits several hours to move from rule 1 to rule 2 in the inventoryagent.log

Here's a way to quickly implement (and quickly undo, if you need to) this local policy override.

-->Attached<-- are two baselines you can import into your Console.  The only one you actually need is the one called "Local Policy Override to Disable Inventory Throttling". In your CM12 Console, Assets and Compliance, Compliance Settings, Compliance Baselines, import that .cab file.  Now that you have it, deploy it to a test collection.  You may want to target a group of computers which you know are exhibiting the behavior in their local inventoryagent.log as mentioned above.  Make sure when you deploy the baseline, that you DO check the box about remediate.

Because software inventory is (in general) slow... you may want to wait a few days to see that this baseline does what you expect it to do.  Once you are satisfied with the results, it is up to you if you want to deploy this Local Policy Override to all of your Windows systems in CM12.

If, at some future time, you want to take away this local policy override, import the baseline "Delete The LPO for Inventory throttling Disabling".  Obviously remove the deployment of the original; and deploy the Delete baseline.  (if both are deployed at the same time to the same machines...  those machines will get and remove, remove and then get, the local policy override... just messy.)

Thanks to Robert Hastings and Microsoft for the local policy override syntax!

  • Created on .

Configuration Manager 2012: Inventory Customizations when you use Distributed Views

I suspect few ConfigMgr 2012 environments will encounter this potential issue.  You have to have 3 very unique circumstances.  a) you are a big enough environment that you have a CAS and Primaries to begin with.  b) You are a big enough environment to leverage Distributed Views.  c) You've previously customized inventory, and then you've decided to ADD to that customization instead of creating a new one (very few environments do that, even if they have a CAS and they use distributed views).  So maybe I'm the only one that would ever encounter this issue.  But just in case I'm not... putting this out there in a blog for others to find in case they are just as strange as I am. 

 

The Issue: you see something like this in your dataldr.log:

*** exec dbo.spRenewChangedInvViews

*** [42S22][207][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name 'Supported00'. : v_GS_MoreInfo0

 

You have a CAS and a Primary, and you have enabled Distributed Views for Hardware Inventory (you can check by going to Administration, Hierarchy Configuration, Database Replication, for each Parent Site to Child Site replication link, right-click, and go to "Link Properties" If you have a checkbox next to "Enable the following types of site data for distributed views" for Hardware Inventory, then this applies.

 

How to resolve:

One way, I guess… would be to turn off distributed views for hardware inventory, wait a day or so, then turn it back on. (but who wants to do that).

 

These instructions aren't exactly um… supported. But it seemed to work for me.

 

The reason for the error is that the local table which was changed as part of the process of adding an attribute to a pre-existing custom import isn't what is actually being referenced by the new view. There's a View, which uses Union All; to grab info from the child site and the CAS site database, so that it looks like just 1 view (when you do reports)

 

So… the fix is to update that Distributed View. For Each of the 4 views that are there for that custom inventory.

 

For whatever reason, you can't see the Distributed Views from a remote SQL Management Studio connection.  So you have to RDP into your Server which houses the Database for your CAS.  Launch SQL Management Studio from there, then go to your CAS site, database, views, and go find the dbo.<TableName0> ; In my case it was dbo.MoreInfo_data. Right-click Design on that.

 

If you're a deep down sql geek, you'll see that it's just 2 select statements with a union all in there--and guess what's missing? Yep, that new attribute you just added. So in both select statements, add in the missing attribute (in my example,   ,Supported00, exactly what the error message is whining about), and hit save.

 

Go back and watch dataldr.log. I'll bet it continues past that error (for v_gs_moreInfo0) and now is whining about v_hs_moreinfo0. I'm Right, aren't I? Ok, now you have to right-click design on the _HIST view; same thing, 2 select statements with a Union All; and you add in the missing attribute and hit save.

 

Continue doing that until dataldr.log stops whining.

  • Created on .
Copyright © 2018 - The Minnesota System Center User Group