SCCM - Enable BitLocker with TPM and PIN

In our environment we are using BitLocker with the TPM and a PIN. SCCM has the option to enable BitLocker as part of a Task Sequence.

However, you cannot set a PIN. Now if you have the settings in Group Policy to force a PIN this wont add the registry settings until AFTER the TS has completed. Not very useful.

The solution:
Use the built in SCCM Task for Enable BitLocker. Choose TPM only and save the recovery info into AD:

This will enable BitLocker and start encrypting the disk. I have not tested it yet, but I cant see why you couldnt have this straight after the step "Setup windows and ConfigMgr". In theory this would leave you much further in the encryption process by the time the TS ends.

From an encrypted PC you want to export the registry with your settings. Remember to re-do this if you change your BitLocker policy. The registry you want is located here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]

With this all at the end of the TS, I add a reboot after the above step. I have had some odd results with the first login without doing this reboot. However if this is at the begining, you will most likely have a reboot somewhere.

Apply the registry you exported above, using a "Command Line", or create a package.

regedit /s <filename.reg>

Ok, so we have encryption enabled, and our registry added. Now we can set a PIN. Add another "Command Line"

manage-bde.exe -protectors -add c: -tp %EnPass%

%EnPass% is a task sequence variable. How you set this is up to you, you can set this manually here if you want. I have an HTA with some options, one of which asks for this password and sets this variable.

SCCM Client Not Updating the server - Part 2

Following on from this post the fix I decided to use is again, not ideal but it will get the machines talking back to the SCCM server.

The solution was to create a task sequence in Group Policy Preferences.
"Computer Configuration" > "Preferences" > "Control Panel Settings" > "Scheduled Tasks".

Create a new task with the following settings. The most important one is "Run with highest priviledges". Enter the details of an admin account that can run this on the PC's you want it to as well.

Create a new trigger, I went for "At log on", and delayed this by an hour. So after the user has been logged in for an hour, run this task. I also add a limit to how long this can run, just incase.

Create a new action, "Start a program". You want to run:

C:\Windows\System32\ccm\ccmrepair.exe

I have also added a condition that a network connection must be available. There is no point trying to reconnect to the server if it cannot be reached.

The rest of the settings dont really matter, but the above is what I went for. As long as a machine gets Group Policy, the SCCM client will repair.

Still best to resolve the issue with the build as outlined in this post, but this will fix the ones that slipped through the deployment.

SCCM OS Targeting by Collection

In cases like updates and such you may want to target machines based on what OS they are running.
Create a new collection, and select a Query based rule

Give the rule a name, limit it to a collection if you wish. Click "Edit Query Statement..."

On the Query Statement Properties, click "Show Query Language". This will allow you to enter a statement rather than selecting fields manually.

Paste in the the query below, and change the <OSVERSION> with the version number below that.

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 where SMS_R_System.OperatingSystemNameandVersion like "%<OSVERSION>%"

Windows XP: Workstation 5.1
Windows 7: Workstation 6.1
Windows Server 2003: Server 5.2
Windows Server 2008: Server 6.0
Windows Server 2008 R2: Server 6.1

Save the query and the collection. Update and the collection will now contain all machines that have reported to be running that OS Version.

SCCM Client Not Updating the server

PART 2, the more reliable solution

Post deployment clients are not talking to the SCCM server and updating it with their information.

The blog post here has some great information on how to solve the issue. What it doesnt cover is how to get the PC's you have rolled out already.

What J.C. Hornbeck does mention is where to correct it, the registry key:
HKLM\SOFTWARE\Microsoft\CCM\CcmExec\ProvisioningMode="true"

I have created a Group Policy Preference to change the "true" to a "false". Follow this up with the script from Microsoft here. If you are deploying this out there, comment all the "Echo" commands out so it gives no prompts and is 100% silent.

This is NOT a fix for the root issue, but gets the clients already deployed to comunicate back to the mothership