Microsoft provides ample documentation describing the process for enabling Bitlocker in the enterprise.  There are only a half a dozen or so steps required to prepare then Active Directory environment and then a few minor modifications to the SCCM or MDT task sequence to enable BitLocker during builds.  In the field I have found there is one area where the BitLocker documentation is lacking and thought I would share this tip.

When enabling backup of Bitlocker Recovery key information in Active directory it is required that Group Policy be configured in order to turn on the Active Directory backup feature of BitLocker on the worstation itself.  The Microsoft guide for preparing and configuring Active Directory can be found HERE.

Unfortunately the guide does not provide complete information for Group Policy configuration.  Following the guide will result in two group policy settings being configured, one for TPM recovery keys and one for BitLocker recovery keys.  Six group policy settings are required in order to properly configure Active Directory backup of BitLocker keys.  This requirement is not clearly detailed in the Microsoft documentation.  If these policy settings are missing and you attempt to save BitLocker recovery information to Active Directory via the “manage-bde -protectors -adbackup c: -id {device id}” command line you will receive the following error:

ERROR: Group policy does not permit the storage of recovery information to Active Directory. The operation was not attempted.

Additionally, searches for recovery key information in Active Directory BitLocker Recovery Key Viewer will not return any results.

Resolution:

Verify all of the following group policies are configured and present on the workstation, then retry saving BitLocker recovery information to Active Directory via the “manage-bde -protectors -adbackup c: -id {device id}” command:

• Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and Windows Vista)
• Configure how BitLocker-protected operating system drives can be recovered
• Configure how BitLocker-protected removable data drives can be recovered
• Configure how BitLocker-protected fixed data drives can be recovered
• Configure how BitLocker-protected drives can be recovered (Windows Server 2008 and Vista)

And finally, for the TPM:

• Turn on TPM Backup to Active Directory Domain Services

If you do not know the device id then run the “manage-bde -protectors -get c:” command, replacing “c” with the drive letter of the device in question.  If all of these settings have been configured properly and BitLocker is successfully enabled you will see the following event in the system log:

User Affinity is shaping up to be one of the most promising new features in SCCM 2012.  What is User Affinity?  This new feature creates a “link” called an “Affinity” between a user and their primary device(s).  Yes you read that correctly, users can have more than one primary device.  With this “Affinity” in place, software can be assigned to the user and it will only be installed on the devices in the user’s “Affinity” list.  Sounds simple right, well it has taken Microsoft a while to get this into their product.  Now that it is here, SCCM administrators can once again broach the topic of user assigned software instead of computer based assignments.  All this without the worry of software ending up in places where it shouldn’t and the associated licensing headache.

So how does this “Affinity” work?

When a workstation is built, the task sequence has two new variables that can be set.  As long as the SCCM distribution point has been configured to accept the Affinity assignments during the build then the Affinity links to users can be defined on the fly during the build process.

The first variable is “SMSTSAssignUsersMode”.  This variable can be set to one of three settings depending on the desired behavior of Affinity creation.  If set to “Auto”, the Affinity processing will be automatically approved by SCCM.  Set to “Pending”, the Affinity rules created during the build will require central approval via SCCM administrators.  Lastly, set to “Disabled” no user Affinity processing will take place.

The second variable is “SMSTSUdaUsers”.  This is where the magic happens.  One or more users can be assigned to this variable in the format of “DOMAIN\Username”.  This can be done by any number of traditional methods for setting task sequence variables such as VBScript, custom executable, or the popular HTA method.  We’ll talk more about this in a bit!  Once the user is assigned to the variable, then the SCCM client will create the Affinity to the workstation in SCCM.  After the task sequence  completes the SCCM, client will begin installing User assigned applications that match the Affinity of the machine.

How can this make the deployment of workstation easier?

Over the last few years, many of our client’s shifted from 3^rd party software distribution tools to SCCM 2007 only to realize the headache of user based software assignment after the fact.  At Kraft Kennedy we have assisted clients with this challenge in a number of ways, ranging from simple Direct Membership assignments to assigning software to workstations via Active Directory Security Groups, all the way up to customized databases for linking software assignments to users and installing the assignments on the fly during the task sequence via Multiple Application Installation tasks.  The latter of these options brought clients very close to Microsoft’s “Zero Touch” build process, but requires a fair amount of custom code.  Achieving Zero Touch builds is realistic for homogenous workstation environments.  In reality, especially for those of you in the Legal community, workstations require many different combinations of applications and many of the combinations apply to one or two users at best.

User Affinity looks to be the sweetheart solution to a lot of these deployment issues.  Circling back around to the actual assignment of Affinity values during the build; to make this concept work in a Zero Touch environment all we are going to need is (1) users properly assigned software and (2) a simple system such as a database for linking hardware to usernames.  The only custom code required will be the process for assigning the User Affinity variables during the task sequence according to the entries in the linking system.  SCCM will take care of the rest by installing the usual build software and the “Affinity” assigned software immediately after the build.

At Kraft Kennedy we are working on a web front-end that is SharePoint compatible for easy and central creation of the “Affinity” links to be used during the build process.  How are you planning on implementing the new “Affinity” feature?

For those of you looking for some additional information on this topic John V. at Microsoft has a great post on the topic found HERE.

As I previously mentioned, the Android OS is a shortfall of the Nexus One when using it for business. Google integrated applications, such as Google Maps, work excellent but the business tools do not. The most notorious feature that is still missing is the ability to synchronize the calendar with Microsoft Exchange. Since switching from my Blackberry to the Nexus One I have been late to or have missed dozens of appointments because of the lack of reminders. Key business features that are also missing include e-mail signatures, notifications for high-priority emails only, and poor cut and paste functionality. Additionally, the layout of the keyboard is hard to get used to. The keys are smaller than those on the iPhone and the spacebar is very close to the Home and Menu hard keys which results in frequent miscues of those functions.

Security is a major issue with mobile devices and there are two major security issues with the Nexus One. First, the Android OS does not support Exchange Remote Wipe for erasing data from lost devices and second is what I call ‘Google’ security. When setting up the device Google asks if it is ok to upload information to Google about the phone’s location, and in order to use certain features like the calendar you must integrate with Google applications requiring Google Accounts. This puts the user in a precarious position where sensitive data could possibly be transmitted and stored on Google servers which is unacceptable for most business security policies.

To wrap up on a positive note, Google is definitely headed in the right direction with the Android OS and Nexus One, especially with their no contract purchasing plan. Once Google provides the critical business functionality that is currently missing then Google might have a real Blackberry or iPhone killer on their hands.