MBAM 2.0 SP1 - Things Learned + MBAM Supported Computer Query

Has been a while since I last posted here, but it just seems like all the things that I come across are usually SCCM related or desktop related, even though I am a server guy, but here it is.

We have been using Microsoft Bitlocker Administration and Monitoring (MBAM) 2.0  for a while now and it has been working just fine, however the new SP1 came out not too long ago, and it was time for the update. If you have worked with MBAM before, you will know that it isn't a simple upgrade process, and is actually a full uninstall and reinstall, but you can keep your database, which is a good thing obviously as it contains all of your recovery information. I struggled for 2 days with the upgrade, and I figure I best post here all the places where I went wrong, and all the things learned.

First, I will explain our environment. Our initial MBAM 2.0 configuration was split over two servers, server1 was the web interface for all of the MBAM functions, and server2 was actually out SCCM 2012 SP1 CU3 server, where we installed all of the other features, including the reports which used the same SSRS instance as SCCM did. During the upgrade we wanted to consolidate MBAM onto the same server as SCCM only, so that made things a little bit more interesting. In our small environment we have a single SCCM server and a few distribution points, and we DO NOT use SSL communication for our SCCM clients.

So first things first, installing MBAM 2.0 SP1 on the same server is very much possible, and you can even use the same port number as you had used for other functions, as long as you add a hostname during the installation that is different than what you have previously used, and ofcourse create a DNS alias for the hostname. I used the default port 443 for our configuration as we were using SSL for MBAM Client to MBAM server communication, and a hostname of mbam.domain.com

During the installation, one of the items that is installed is the Audit Reports, which allow you to track who has retrieved which key for which machine for auditing purposes. I have a service account that I use for all things SCCM, which is a domain admin to make things easier, so during the prompt for a username and password for Audit Reports section of the install, I used the same account just mentioned; however, the install always failed, with this line being found in the logs:

CustomAction InstallReportsDeferred returned actual error code 1603


If I chose not to install the reports, the installed always went through the process without any errors. I battled with this for almost two days, trying to figure out what is going on. I remembered that we had this issue before when upgrading from MBAM 1.0 to 2.0, and I remembered that it had something to do with permissions, so I tried all kinds of things to get this service account greater permissions then what it already had, with multiple changes in ADSI edit, changes to the computer account of SCCM, you name it, all to no avail. I tried to research as much as I could, and at one point, I found a thread where someone mentioned that the account used here should be an account dedicated just for MBAM reports. I created a new run of the mill account, entered that information during the prompt, and whola, the installed went without any issues! I think this problem may be specific to our environment as SSRS is already aware of our SCCM service account I was always trying to use, and since I am using the same SSRS server for MBAM, perhaps it tried to modify permissions for that account and SCCM wouldn't let it, I will never know, or care, as I got it working.

During the install I picked the default port 443 for communication and instead of server2.domain.com I entered mbam.domain.com for the hostname as that's the alias I wanted to use to access my MBAM webpages. When I tried to first login to MBAM helpdesk webpage, it would give me this error on the right frame of the page:

I did a quick search online which lead me to this KB from Microsoft. I commented out the DNS entry as explained in the example and restarted IIS and the error went away. I think this error has something to do with using hostname that doesn't match the actual server name, but regardless, this was the fix.

 

The final hurdle I had to face was to do with the MBAM Supported Computers Query. In MBAM 2.0 the query worked very well and only had the physical boxes which supported TMP listed in there, however, with SP1, it started showing all kinds of strange things, like our thin clients and virtual machines, despite the query saying to exclude those things. I compared the query from 2.0 to 2.0 SP1 and noticed that the placement of the TPM check was in a different location in the query, so I moved it to the same location as it used to be on the older version of MBAM and it fixed the problem, so I think it's a bug. This query also takes into account windows 8.1 for those who are using it.

 

This is the fixed query that worked for me:

 

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))        or NOT (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")        and SMS_G_System_TPM.SpecVersion >= "1.2"

Hope this helps someone if they are experiencing any of these issues, as the information out there is pretty slim.