Innovative Technology Weblog

I recently had to come up with a solution that will enable administrators to build reports for client’s bitlocker status. To do so i found a few articles on the web that pointed me in the right direction, however i didn’t found a complete howto for it so that’s a good reason for me to post a complete one.

To enable bitlocker status reporting in a centralised management environment with SCCM you need to follow some steps because bitlocker is not integrated that far (yet??) in the Windows OS. First, let’s first take a look at the status information that bitlocker provides:

• Volume name, example: C: [OSDisk]
• Disk size, example: 148,75 GB
• BitLocker Version, example: Windows 7
• Conversion Status, example: Fully Encrypted
• Percentage Encrypted, example: 100%
• Encryption Method, example: AES 128 with Diffuser
• Protection Status, example: Protection On
• Lock Status, example: Unlocked
• Identification Field, example: None
• Key Protectors (Note: multivalue), example: TPM, Numerical Password

You can check the above on clients using the commandline tool manage-bde.exe -status on Windows 7 clients. For Vista clients use cscript manage-bde.wsf -status.

Step 1. Modify and deploy SMS_DEF.MOF

We want bitlocker status information to be inventoried to SCCM. A proper way of doing that would be to add the bitlocker class to the SMS_DEF.MOF file on the management point (found in %SCCMinstallpath%\inboxes\clifiles.src\hinv). Make a copy of this file and edit with your favorite app. Add the following lines at the end of the file:

#pragma namespace (“\\\\.\\root\\cimv2\\SMS“)
#pragma deleteclass(“SCCM_BitLocker”,NOFAIL)

[ SMS_Report     (TRUE),
  SMS_Group_Name ("SCCM_BitLocker"),
  SMS_Class_ID   ("CUSTOM|SCCM_BitLocker|1.0") ]
class SCCM_BitLocker : SMS_Class_Template
{
  [SMS_Report (TRUE), key ] string Drive;
  [SMS_Report (TRUE)] string DriveLabel;
  [SMS_Report (TRUE)] string Size;
  [SMS_Report (TRUE)] string BitLocker_Version;
  [SMS_Report (TRUE)] string Conversion_Status;
  [SMS_Report (TRUE)] string Percentage_Encrypted;
  [SMS_Report (TRUE)] string Encryption_Method;
  [SMS_Report (TRUE)] string Protection_Status;
  [SMS_Report (TRUE)] string Lock_Status;
  [SMS_Report (TRUE)] string Identification_Field;
  [SMS_Report (TRUE)] string Key_Protectors;
  [SMS_Report (TRUE)] string Automatic_Unlock;
  [SMS_Report (TRUE)] string ScriptLastRan;
};

You should check the file for errors with mofcomp.exe -check SMS_DEF.MOF. To enable the MOF file on a single client run the following command on the client mofcomp -class:forceupdate %pathtofile%\SMS_DEF.MOF. Copy the edited file back to enable it on your ConfigMgr site. 

Step 2. Install Bitlocker

Create and link a GPO to apply on the bitlocker clients that contain the following settings (or similair based on your own requirements):

Enter the BIOS on your client or use tools like the Dell client configuration utility to turn on TPM, clear the TPM and activate it. After doing this enable bitlocker encryption on the machine. You can use any method to achive this.

Step 3. Add Bitlocker status to WMI & run hw inventory 

Although there are multiple ways of manipulating bitlocker through WMI you still need a script to read, update and store bitlocker status information in the WMI repository (see http://msdn.microsoft.com/en-us/library/aa376409.aspx). This is because Managed Object Format (MOF) files are not installed as part of the Windows SDK and therefore the included classes are not added to the WMI repository automatically by Windows itself.

The script:

• UpdateBitlockerStatus.vbs

Run the script and after that initiate a hardware inventory on the client. After a while you will find 2 new tables and 1 new view in the SCCM site database:

Step 4. Create the Report

The most simple report would be a report of the table containing the bitlocker inventory data. By joining other tables/views with SQL queries the possibilities are endless, however i placed that out of scope of this howto . The following tables and views are provided for this:

• dbo.SCCM_BitLocker_DATA
• dbo.SCCM_BitLocker_HIST
• dbo.v_GS_SCCM_BitLocker0

I created a report in SCCM with the following query using the SQL view:

• select * from v_GS_SCCM_BitLocker0

And there it is, the Bitlocker report:

Tested on SCCM R2 with a Windows 7 Enterprise bitlocker client.

Feel free to comment on this post.

Hi i’m Douwe van de Ruit, a new blogger at buit.org and right now i have some nice things to share about the upcoming System Center Configuration Manager.next. Microsoft released Beta 1 last Tuesday so i downloaded it from the Microsoft connect site and kicked it in a virtual testlab to dig through the new features and changes. I will show some new features from which i have great expectations. I will stick to the headlines only because covering all newly or changed features will be to much for a blogpost.

While installing SCCM.next i found out that the procedure was very similar to the way SCCM 2007 is installed. But when i started the Admin console i finally saw the “Outlook-styled” console for SCCM that is inline with consoles used for OpsMgr and VmMgr!

A good example of “do more with less” will be client settings, all settings are simplified by consolidating them in just one, simple and faste editable setting-interface:

So the interfacelifted GUI is a big change included in SCCM.next. But what about functionality and features? Well, Googling on vNext will return 3 main focus areas where Microsoft would deliver changed functionalities:

1. User centric application management  – Empowering Administrators to define intent, and end users flexible access to the right application at the right time
2. Infrastructure simplification – Simplify management infrastructure, processes and administrative overhead
3. Simplify Client Management – Daily tasks, model based configuration management and improvements over existing capabilities

User centric comes with so called user device affinity rules as you like, which can be used to define user’s devices and priorize them in a way that some deployments can depend on these affinity rules. Additionally, it will allow admins to create definitions of the relationship between the users and their applications in a way that the admins don’t have to worry about where that user is and what device it’s using .  They can trust the system that the user will have the right application at the right time in the right place suitable for the device they are on. Just a screenshot that relates to the user centric management functionality:

Just looking at the interface already shows that all administrative tasks just got easier and smarter and will achieve better overall performance in using ConfigMgr for all tasks. Infrastructure and Client Management simplifications will take more investigation to find out significant improvements as opposed to SCCM 2007. However, i do know that distribution points in SCCM.next will support scheduling and throttling. Imagining a branch office with a considerable amount of clients, you normally would create a secondary site if there was a concern about content distribution bandwidth consumption during office hours. With SCCM.next now you’re not bound to secondary sites because you can use distribution points with scheduling and throttling capabilities using the newly added ”Rate Limits” tab in distribution point settings.

By simplified client management Microsoft introduces the “Custom Client Setting”. With this feature you can create custom client agent settings which you can apply to collections containing devices, users or both. On top of the custom client settings you will still be able to configure the top-level client agent settings. The need for an extra Primary site will become unneccesary if the only reason would be driven out of other Client settings. Very nice.

To summarize some more new stuff i (quickly) found:

• added distribution groups for administrative purpose
• SCCM.next is 64 bit only
• SQL 2008 required
• added more than 300 extra SQL tables in the site database
• changed the term “Advertisements” into “Deployments”
• added Global Conditions settings which can be used to divide device types based on various parameters
• SQL Reporting service replaces standard reporting
• the “inboxes” system is still in use (and not transformed into SQL based communication as introduced before as a “wanna have”)
• “Create Report” function crashes in my test lab
• Help function returns white pixels
• SCCM 2007 DCM and Assett Intelligence nodes are integrated into a “Assets and Compliance” tab
• New System roles: Software Catalog Web Service Point, Software Catalog Web Site Point, Mobile device enrollment proxy point, Mobile device enrollment point

Nice stuff so far :-)

One of the most anticipated features of SCCM 2007 R2 is “App-V Integration”. We have recently tested the end-to-end scenario for this integration and we can say with confidence: it BLOWS . In a nutshell, by integrating App-V with SCCM you lose App-V’s best features and reduce the solution to something that’s even worse than SCCM by itself!

So what happens when you enable the App-V/SCCM integration feature in the SCCM Management Console?

• Control of the App-V client is seized by the SCCM client. If you had App-V running on its own before you enabled the integration, you’ll notice that all App-V apps that are published through App-V’s Publishing Server are now rendered invalid. On launch you’ll get a “Unable to initialize package information (0×00000000)” error.
• You must now publish your App-V apps through SCCM as “Virtual Application Packages”. This works by importing the .XML file of the App-V package. SCCM will distribute the packages to its Distribution Points and you can enable those Distribution Points for HTTP(S) streaming.
• To get the App-V apps to your clients, you’ll have to create SCCM advertisements. Basically SCCM advertisements replace the App-V Publishing Server. The behavior of getting App-V apps to your desktop now becomes eerily similar to SCCM’s way of installing applications. No more getting your shortcuts immediately upon logon (like you get with App-V); you will have to go get a cup of coffee and hope that SCCM is willing to give you your apps today.
• If you created non-mandatory assignments, then you’ll have to go to Add/Remove Programs yourself and click “Run” for all the apps that you want. However clicking “Run” doesn’t actually run your app, it only registers the App-V app with the local App-V client. Don’t expect to see any progress bar or visual feedback that the registration actually happened; just keep scouring around in your Start Menu in hope of finding the shortcuts for your new app.
• If you created mandatory assignments, you’ll get one or more notifications from SCCM (after some time ofcourse) that SCCM has App-V apps for you that it would like to register with the local App-V client. It will do that on *every* desktop you logon to. Prepare to spend quite a bit of quality time with the SCCM Client…
• If you’re using either Windows Terminal Services or Fast User Switching in Vista, you’re SOL because the SCCM Client is allergic to terminal sessions. You’ll get a message telling you that “No programs are available to run from a Terminal Services session”. How nice. If you happen to be running the console session, you won’t notice this limitation because at the console session, everything works just fine. So make sure you also test your solution via a terminal session so you won’t get caught by surprise.

As a result of the findings described above, we were pretty disappointed with the solution and decided to reverse our decision to integrate App-V with SCCM. However we did like the idea of using SCCM Distribution Points to stream App-V apps from. So we had a go at doing a manual integration of App-V with SCCM so that we could use just the SCCM parts we wanted. The idea was inspired by Tim Mangan’s article which included this diagram:

In his article he never got around to actually testing if it was possible to stream an application that was published by App-V’s Publishing Server from an SCCM Distribution Point. He only verified that is was possible to install the App-V app through an MSI with SCCM. So we ventured to get HTTP streaming working against SCCM Distribution Points, with the shortcuts still being provided by an App-V Publishing Server. In a nutshell: it works! You do have to setup a few mechanisms to get load balancing working though.

Here is how it works:

• First and foremost: disable the App-V integration with SCCM. To do this, go to the SCCM Console -> Site Database -> Site Management -> <Site> -> Site Settings -> Client Agents -> Advertised Programs Client Agent -> Properties and make sure “Allow virtual application package advertisement” is NOT selected.
• Enable your SCCM Distribution Points for BITS, HTTP and HTTPS content transfer. To do this, go to the SCCM Console -> Site Database -> Site Management -> <Site> -> Site Settings -> Site Systems -> <your DP> -> ConfigMgr distribution point -> Properties and select “Allow clients to transfer content from this distribution point using BITS, HTTP and HTTPS”.
• We found that (at least in the RTM version of SCCM 2007 R2) you don’t have to enable “virtual application streaming” on the “Virtual Applications” tab of the distribution point to be able to stream from a SCCM DP when using our manual integration. The added benefit of this is that you can now also use Secondary Site DP’s as streaming servers!
• Set up an App-V Management Server on any server you like. You can even set it up on a SCCM server, it doesn’t matter. Use the default installation settings for the entire installation. After installation, set the Default Content Path to the following: http://%SFT_SOFTGRIDSERVER%
• Add an App-V package to SCCM for distribution and streaming:
  • Go to the SCCM Console -> Site Database -> Computer Management -> Software Distribution -> Packages -> New -> Package. Enter the information about your package and click Next. Select “This package contains source files” and set the Source Directory to the location of your App-V package and click Finish. Note that you import the App-V package as a normal SCCM package and NOT as a Virtual Application Package. Importing it as a Virtual Application Package will cause the .SFT file in the App-V package to be renamed and cause the .SFT file to be added to not 1 but 2 locations on each SCCM Distribution Point, doubling storage requirements.
  • When the package is added to SCCM, find the Package ID and use it to update the streaming location in the App-V OSD files. For each OSD file in your App-V package, update the HREF statement to HTTP://%SFT_SOFTGRIDSERVER%/SMS_DP$/SMSPKG/<your SCCM Package ID>/<name of your SFT file>
    (If you are using a File Share Distribution Point, the IIS vdir may be different than SMS_DP$. Verify the vdir name in IIS Manager and ensure that all DP’s are either standard DP’s or File Share DP’s.)
  • Now add some SCCM Distribution Points to your package so that SCCM can distribute the App-V content
• Import the same App-V package into the App-V Management Server so that you can distribute the shortcuts and set permissions:
  • On the App-V Management Server, go to the App-V Management Console, go to Applications
    -> Import Application and go to the same App-V package folder. Select the .SPRJ file and click Open. Perform your regular App-V import steps and finish the import.
  • The imported applications in the App-V Management Console should now show the correct http:// paths to both the OSD file(s) and the SFT file(s).
• That’s it! Now just configure your App-V Clients on the desktops to use your newly setup App-V Management Server by configuring a Publishing Server and use Group Policy to set the %SFT_SOFTGRIDSERVER% to the name of a SCCM Distribution Point nearby. We set this variable to DNS name that uses DNS Round Robin to distribute the load to multiple DP’s.

I actually ran into more problems with the PKI after the installation. Although SCCM detects your Site Server Signing certificate during setup, the process of dragging and dropping the certificate from the current user branch to the local machine branch may (not sure if there are situations where this does not happen) corrupt the private key in the certificate. To fix this, you have to change the template for the Site Server Signing certificate. On the ‘Request Handling’ tab, check ‘Allow private key to be exported’. Then go through the process of requesting the certificate as usual, and don’t drag and drop as I described in my previous post, but export from the current user certificates and import in the local machine certificates. That should fix the Site Server Signing certificate.

I also had a problem with the Web Server certificate, don’t know if it’s related to having a Windows Server 2008 Certificate Authority or not. In the Microsoft walkthrough they tell you to duplicate the normal Web Server template. When I did this, SCCM kept reporting the Management Point giving problems; a test http request would return an error. After a little Googling I found the solution: on the new template (I named it SCCM Web Server) add Client Authentication on the ‘Extensions’ tab. Don’t forget to re-enroll and re-assign the certificate to your website.

I hope that’s all I have to say about this.

The last couple of days I’ve been playing around with the SCCM 2007 SP1/R2 beta. I wanted to try out the NAP (network access protection) features, which require Windows Server 2008 on the SCCM server. So I went ahead and created some virtual machines, a domain controller and a SCCM server. I wanted to do it right, so I decided to install Windows Server 2008 on the domain controller as well. To build the PKI required by native mode I followed the excellent walkthrough at http://technet.microsoft.com/en-us/library/bb694035.aspx. And then I ran into trouble…..
There are two issues with getting the Site Server Signing certificate on the SCCM server. First, because the CA is running on a Windows Server 2008 machine, when you duplicate the ‘Computer’ certificate template, you get the choice which versions of Windows should support this template. Considering the fact that all servers in my environment are running Windows Server 2008, I went with that. And that was my mistake. If you select “Windows Server 2008, Enterprise Edition” the certificate template will not show up while enrolling it from the web interface, so you should select “Windows Server 2003, Enterprise Edition”.
The second issue I ran into was related to the requesting client being a Windows Server 2008 machine. When this is the case, the web interface no longer shows the option to store the certificate in the local computer certificate store. Just continue as you normally would and after that, open an MMC on the SCCM server. Add two certificates snap-ins, one for the current user, the other for the local computer. All you have to do is drag the certificate you just enrolled from the web interface from the Personal/Certificates store under the current user branch to th Personal/Certificates store under the local computer branch.
After this, in my case the SCCM installation automatically detected my certificate and installation went smoothly.

 Please note that I have posted a follow-up to this post, because although installation will go smoothly, you will have some errors if you do it the way I descibed above. Here’s the correct way to do it:  http://www.buit.org/2008/05/22/installing-sccm-2007-sp1r2-in-native-mode-on-windows-server-2008-part-2/