MBAM Supported Computers - Including Windows 10 RRS feed

  • Question

  • Hi Guys, 

    I recently rolled out mbam and integrated it with sccm 2012 r2, i was looking at the Mbam Supported Computers collection that was automatically generated by the installer and noticed that my windows 10 machines were not present, it seems that the query maxes out at windows 6.1, i have tried to get this query working with 10 but have had no luck, can someone help?

    select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId  inner join SMS_G_System_OPERATING_SYSTEM_EXT on SMS_G_System_OPERATING_SYSTEM_EXT.ResourceID = SMS_R_System.ResourceId  inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId  left outer join SMS_G_System_TPM on SMS_G_System_TPM.ResourceID = SMS_R_System.ResourceId where ((SMS_G_System_OPERATING_SYSTEM.Version like "6.1.%" and SMS_G_System_OPERATING_SYSTEM_EXT.SKU in (1,4,27,28,70,71) and SMS_G_System_TPM.SpecVersion >= "1.2") or NOT (SMS_G_System_OPERATING_SYSTEM.Version like "6.1.%" or SMS_G_System_OPERATING_SYSTEM.Version like "6.0.%" or SMS_G_System_OPERATING_SYSTEM.Version like "5.%")) and SMS_G_System_COMPUTER_SYSTEM.DomainRole = 1 and (SMS_G_System_COMPUTER_SYSTEM.Model not in ("Virtual Machine", "VMware Virtual Platform", "VirtualBox") and SMS_G_System_COMPUTER_SYSTEM.Manufacturer not in ("Xen"))

    Wednesday, October 14, 2015 4:40 PM


  • Windows 10 reports the Operating System Name and Version as "Microsoft Windows NT Workstation 10.0".

    So I guess you'd need to add another statement into your query:

    or SMS_G_System_OPERATING_SYSTEM.Version like "10.0%"

    • Proposed as answer by Garth JonesMVP Saturday, October 24, 2015 2:13 PM
    • Marked as answer by Joyce L Thursday, November 5, 2015 5:15 AM
    Thursday, October 15, 2015 12:35 PM

All replies

  • Could you please share the original query that the integration created? Or is that the one above?

    Nickolaj Andersen | www.scconfigmgr.com | @NickolajA

    Wednesday, October 14, 2015 6:35 PM
  • it is the one above, unchanged. 
    Thursday, October 15, 2015 8:40 AM
  • Windows 10 reports the Operating System Name and Version as "Microsoft Windows NT Workstation 10.0".

    So I guess you'd need to add another statement into your query:

    or SMS_G_System_OPERATING_SYSTEM.Version like "10.0%"

    • Proposed as answer by Garth JonesMVP Saturday, October 24, 2015 2:13 PM
    • Marked as answer by Joyce L Thursday, November 5, 2015 5:15 AM
    Thursday, October 15, 2015 12:35 PM
  • Resurrecting an old post.

    I'm having some strange results trying to include Windows 10 machines.

    The default query seems to include SOME but not all of my Windows 10 machines.   If I add the above statement in it still doesn't include all of my machines.

    Details of the problem in this post.

    TLDR: if I create a new simplified query just for Windows 10 like:

    all of my Windows 10 machines with TPM enabled show up.  But if I simply try to add SMS_G_System_OPERATING_SYSTEM.Version like "10.0%" to the existing query:

    some of my Windows 10 machines show up but not all of them.  

    I can't figure out what I'm doing wrong with default collection query.

    Friday, June 3, 2016 1:19 PM
  • Friday, June 3, 2016 1:32 PM
  • That's the kicker.  I can find nothing different about a machine that appears in the default collection and one that doesn't.

    Originally the only difference I could find was that the ones that weren't showing up all were encrypted with XTS-AES 256.  But that shouldn't matter because the collection doesn't look at encryption method.  The only thing that would fail would be the compliance policy.

    I've since re-encrypted the machines with AES 256 just in case that was the reason and they still don't appear in the default collection while others do.  And of course as a result they don't show up in my compliance collections because they are being applied to the MBAM Supported Computers collection.

    Friday, June 3, 2016 2:26 PM
  • Look at the Where statement section and confirm each item.

    aka confirm that they have TPM 1.2 vs TPM 2.0+

    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Friday, June 3, 2016 2:30 PM
  • If I look at the TPM version of two machines, one that does appear in MBAM Supported Computers and one that doesn't, they both have TPM 1.2. They are the same model of laptops.

     Regardless, wouldn't the query pick up any version of TPM since the statement is 'greater than or equal to "1.2"'?

    Friday, June 3, 2016 2:34 PM
  • Ok, I have found the problem!  I still don't understand WHY it was a problem in the first place but here it goes.

    TLDR: Be careful when you upgrade SCCM because you may loose modifications to configuration.mof!

    I was trying to figure out which query criteria was causing some machines to show up and not show up.  So I started eliminating criteria from most to least restrictive.

    I found in the end that if I eliminated the SMS_G_System_OPERATING_SYSTEM_EXT.SKU in (1,4,27,28,70,71) criteria that ALL of my Windows 10 machines would show up.  Ok well why?  As far as I can tell the query isn't even applying that criteria to Windows 10 machines, just Windows 7.

    Well let's go with it anyways.  So where does that SMS_G_System_OPERATING_SYSTEM_EXT.SKU attribute come from?  I went back to basics for MBAM installation pre-requisites and re-read the info on extending configuration.mof and importing sms_def.mof.  That's where SCCM knows to inventory those attributes, including SMS_G_System_OPERATING_SYSTEM_EXT.SKU (which I think is supposed to be created when you install MBAM? along with Win_32BitlockerEncryptionDetails, etc).  I'd reinstalled MBAM several times on one of the problem machines and it didn't make that WMI namespace appear.

    Anyways, a quick check in Resource Explorer for the missing clients showed that the OPERATING_SYSTEM_EXT tree didn't exist on those clients! Nor did Win32_BitlockerEncryptionDetails in WMI.  This was also confirmed by errors in the InventoryAgent.log file when trying to inventory those namespaces.

    Now I went back to the configuration.mof file on the site server and what?  None of the MBAM extensions existed anymore!  They were gone!  Looking at the last modified date on the file I think what happened was that when I upgraded SCCM to either 1511 or 1602 it overwrote configuration.mof with the default file and all my MBAM configuration items were gone.

    I tried re-importing the sms_def.mof but it told me everything already existed no changes there.

    So I added the extensions back into configuration.mof, forced a machine policy refresh and full hardware inventory on the clients in question and WHAMMO!  They now appear in the default MBAM Support Computers collection. Win32_BitlockerEncryptionDetails exists in WMI and OPERATING_SYSTEM_EXT tree appears in Resource Explorer now!

    So it must have just been clients installed since that upgrade that were affected.

    I'm still scratching my head about a few things.  

    All of this was triggered by me removing the SMS_G_System_OPERATING_SYSTEM_EXT.SKU in (1,4,27,28,70,71) query from the collection.  But as far as I can tell that doesn't even apply to Windows 10 machines, only Windows 7.  

    Also, the act of adding the MBAM bits back into configuration.mof and sms_def should only tell SCCM to inventory those attributes, correct?  It has nothing to do with the creation of them in WMI, which I believe is supposed to happen when you install the MBAM client?

    But yet it appears that once I added them back into configuration.mof, refreshed policy and re-inventoried they got created as well.

    Do I have a misunderstanding of a) how that query is working and b) the mechanism by which those attributes are created in WMI?

    • Proposed as answer by D. Ziegler Thursday, September 29, 2016 12:00 PM
    Friday, June 3, 2016 5:10 PM
  • MBAM 2.5 SP1 is now available, which is supposed to provide "official" support for Windows 10 with MBAM. Did you update your MBAM infrastructure to 2.5 SP1?
    Friday, June 3, 2016 6:26 PM
  • No, have not.  That is on the list.
    Friday, June 3, 2016 6:27 PM
  • I would do that, as you need to uninstall the MBAM server-side components from everything to install the sp1 version which will update your MBAM database... so that collection will possibly be recreated with proper settings in place for you.  I would think as it is a "reinstall type update" you would be able to delete the collection and it would make a new one for you when you install the new version - but not sure there.  See if its still present when you uninstall the MBAM components from that primary or CAS, it might just remove it as part of the uninstall.  Perhaps someone else who has performed the update could chime in here (this is on my list to do as well).
    Friday, June 3, 2016 7:16 PM
  • I actually broke my Read Only Friday rule and took care of that.

    Doesn't look like the update changes anything on the collection.

    Bottom line is it was related to the OperatingSystem.Ex.SKU not being inventoried.  As a result machines weren't getting captured by the query.

    Now that I've fixed the configuration.mof the missing machines are slowly populating as their hardware inventory runs.

    Monday, June 6, 2016 6:21 PM
  • Good Post. This exact same thing happened to us.
    Thursday, November 10, 2016 10:30 PM
  • Good Post. This exact same thing happened to us.

    Just realized it was happening to us too since we updated our SCCM server recently. Added the missing MBAM parts to the configuration.mof (the client rules already had the parts to collect the data) and as machines are checking in, the missing OS Extended and Bitlocker fields are being repopulated, and machines are reporting as compliant.

    Looking at that collection, the reason it misses large groups of computers is because the JOIN it does to the "operating system extended" data is an inner join, so it won't match on NULLs where computers don't have an entry in there at all.  If you didn't care about the SKU value you could simply omit the part where it checks that (or modify it to an outer join and handle cases where an OS version 6.1 also has a null SKU value), but of course that wouldn't solve the real problem of your SCCM setup not collecting the data it should be collecting.

    I'm glad I stumbled on this... good info.

    Thursday, January 24, 2019 11:35 PM