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
  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:  
      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 .

ConfigMgr Inventory: Who is using Outlook PST files, where are they, and how big are they?

I can't think of anyone who has been supporting Outlook for more than a few years where they *haven't* been asked that question.

Until now, the best answer we could come up with was "we can scan the local drives for *.pst".  But that doesn't necessarily tell us if people are connected to them.  Nor does it take into account if people are storing that outlook pst file on a network share.

With some clever scripting from different people, and stealing code from here, from 'robszar' (sorry, don't know his real name) as a base: , John Marcum and Sherry Kissinger, and we've got a routine that will, for the most part, answer those three questions.  The basics of how it works is this.  There are two vbscripts that run.  One runs as SYSTEM, and it's only purpose is to create a custom namespace in WMI, and grant permissions to all of your domain users to that custom namespace--so they can populate it with the results of script #2.  Script #2 runs, only when a user is logged in, with user rights.  That's because the majority of what the script needs to do is read information about that specific logged-in users Outlook configuration, and (potentially) any mapped drive information which may be referenced by the PST file location.

The results of the 2nd script end up in that custom WMI namespace, and will have the following information:

DateScriptRan = the exact date and time that the script ran to gather this user-specific information.
FileSizeinMB = If it could be detected, and the file size was 1mb or larger, the size of the PST.  If it's less than 1mb, or for whatever reason could not be detected, the value will be 0.
PSTFile = just the file.pst (the last value after the last \ in PSTLocation)
PSTLocation = The location as known to Outlook.  This could be c:\somewhere\file.pst, \\server\share\file.pst, or Q:\file.pst (where q: is a mapped network drive).
Type = If it could figure out that Q: was a mapped network drive, it'll say 'Remote', otherwise it'll say local
UserDomain = whomever is logged in, what their domain is.
UserName = whomever is logged in, what their username is.
NetworkLocation = This will almost always be NULL, but, if the PSTlocation was something like q:\file.pst, where q: was a mapped network drive for the user, this field will contain what Q: was mapped to.

End result:  After deploying these two scripts, you will be able to answer those pesky questions from your Exchange team about who, where, and how large, are referenced PST files.  Of course, the main limitation is this is per-user information.  If you have a lot of shared machines, or the same user has multiple computers (and connects to the same PST files on those multiple computers) you'll have to do some creative reporting to ensure you don't double-count the same PST files.

Ok, enough of how it works.  You really want to know *exactly* what to do, right?  Let's start!
Your Source folder for the package will contain 3 things:

The .vbs files are at this  -->link<--.  Note that WMISecurity.exe is not attached here; just search using your favorite search engine to find and download wmisecurity.exe.  The one I used was version --maybe there are later versions of this .exe; but that's the one I found, and it worked.

You will need to make 1 change to "WMINameSpaceAndSecurity.vbs", this line:
Modify that to be your domain (the domain your users are in that will be logging in and running script #2).

Create two programs; the first runs cscript.exe WMINameSpaceAndSecurity.vbs, whether or not a user is logged in, with Administrator rights.  The second runs cscript.exe PSTFinder.vbs, only when a user is logged in, with user rights.  The 2nd one; you want to "run another program first", and have it run the first one.  It only needs to run the 1st program once, per computer; it doesn't need to re-run.

Advertise the 2nd program to a collection (I recommend a test/pilot first), and confirm that it works as you expect.  If you want to confirm the data is there, look in root\CustomCMClasses  (not root\cimv2) for cm_PSTFileInfo, that there are instances there for any Outlook-attached PST files for that user.

If you are satisfied it's there locally, either add the below to sms_def.mof (if you are ConfigMgr07) or import it into Default Client Agent Settings, Hardware Inventory (if you are CM12)


class cm_pstfileinfo : SMS_Class_Template
  [SMS_Report(TRUE)] string DateScriptRan;
  [SMS_Report(TRUE)] uint32 FileSizeinMB;
  [SMS_Report(TRUE)] string NetworkLocation;
  [SMS_Report(TRUE)] string PSTFile;
  [SMS_Report(TRUE),key] string PSTLocation;
  [SMS_Report(TRUE)] string Type;
  [SMS_Report(TRUE)] string UserDomain;
  [SMS_Report(TRUE)] string UserName;

sit back, relax for a bit... then invoke a hardware inventory on your test boxes, and see if the data shows up in your database in v_gs_pstfileinfo0.  If so, deploy the advert to your real target collection of users or computers, and wait for the data to show up.  Depending upon your need for this information; you may or may not want to have the advert run on a recurring basis (weekly? monthly?) or just gather it for a week or so (just enough to answer the question) then delete the advert and change the Inventory from TRUE to FALSE (until the next time they ask).

Here's a potential sql report to get you started:

select sys.Name0 as [Computer Name],
pst.UserName0 as [User],
pst.PSTFile0 as [File Name],
pst.PSTLocation0 as [File Location],
pst.Type0 as [Local/Remote],
  when pst.NetworkLocation0 is not null then pst.NetworkLocation0
  else 'Local'
end as [Network Location],
pst.FileSizeinMB0 as [Size in MB],
pst.DateScriptRan0 as [Date Collected]
from v_R_System sys
Inner Join v_GS_PSTFileInfo0 pst on sys.ResourceID = pst.ResourceID
order by sys.Name0
which will look something like this:


  • Created on .

All Members of All Local Groups inventory for ConfigMgr 2012

All Members of All Local Groups inventory for ConfigMgr 2012

Report on all users in all local groups using Configuration Manager 2012

This is an update to , which was written with ConfigMgr 2007 in mind.

01/09/2017: Updated the mof for import with an additional ,key field; per a recommendation from Adam MacMurray, thanks Adam!

Basically, take the attached file--> WMI Framework for Local Groups with Logging <--, and in your ConfigMgr 12 console, on Assets and Compliance, Compliance Settings, right-click on "Configuration Baseline" and Import Configuration Data... the .cab file.

Once imported, Deploy the Baseline to an appropriate collection.  I recommend potentially two different deployments:  one to all Workstations, and one to all Member Servers.  I.e., don't even try to target your domain controllers.  The script is meant to skip a DC if it's attempted, but it's probably best not to tempt fate.

If this is the first time you've tried to get localgroupmembers, to get the information back, you'll need a custom hardware inventory import.  If you've already cm_localgroupmembers in your hardware inventory rules, skip this.

Save the below as "localgroupmembers.mof"

#pragma deleteclass ("LocalGroupMembers",NOFAIL)
[ SMS_Report     (TRUE),
  SMS_Group_Name ("LocalGroupMembers"),
  SMS_Class_ID   ("LocalGroupMembers") ]
class cm_LocalGroupMembers : SMS_Class_Template
    [SMS_Report (TRUE), key ] string Account;
    [SMS_Report (TRUE)      ] string Category;
    [SMS_Report (TRUE), key ] string Domain;
    [SMS_Report (TRUE), key ] string Name;
    [SMS_Report (TRUE)      ] string Type;

Then, in your console, Administration, Client Settings, right-click 'Default Client Settings', and go to properties.  Select Hardware Inventory, then on the right "Set Classes...", then "Import..."  and browse to the 'localgroupmembers.mof' file you saved.

A couple of OKs, later... then it's just sit and wait.  Remember, patience is a virtue.  Go get some lunch or a coffee break or something.  <grin>

If you want to confirm that the DCM is actually running, there's two ways.

  1. on a client, in root\cimv2, check if cm_localgroupmembers actually created and populated?
  2. The script inside the .cab file is different slightly from the one on the 2010 blog entry.  It includes a log file which will drop into the SYSTEM's temp folder, which is almost always %windir%\temp.  If it ran (or attempted to run) you should get a log file called "SCCMLocalGroupMembers.log".  If having it drop a log file is bothersome for some reason (it may be--it depends upon you own company's practices) open the ConfigItem, copy out the script, and edit it so that it no longer drops a log file.  test and put it back.  Remember, CI's are versions now; so if you mess up you can always go back to an older version.
  3. "In general" the view will end up being v_gs_localgroupmembers0 ; so a select * from v_gs_localgroupmembers0 against your ConfigMgr Database should let you know if it's being populated.  But there are of course exceptions to every rule.  you may have to browse through your views in your database to find the view if it's not that specific one.

Shameless plugs so that this blog post filters up to the top on web searches:

How to get the users in the local Administrators group
Local Administrators group on workstations getting the accounts inside
How do I get the accounts inside the local Administrators group

There? did I miss some key words?

Just a fun possible report:

Select sysv.Resourceid,
         sysv.Netbios_name0 as 'ComputerName',
               ',' + LGM.Account0
               v_gs_LocalGroupMembers0 LGM
                LGM.ResourceID = sysv.ResourceID
                AND LGM.Name0 = 'Administrators'
--Comment out the below if you want any type (Group, SystemAccount, UserAccount)
                AND LGM.Type0 = 'UserAccount'
              ORDER BY ',' + LGM.Account0
              FOR XML PATH('')),1,1,'') AS Admins
 v_R_System_Valid sysv 

  • Created on .
Copyright © 2020 - The Twin Cities Systems Management User Group