One of the major changes in Configuration Manager 2012 is that the old Mixed and Native modes in CM07 are gone. Instead, CM12 does the vase majority of its communications using HTTP and HTTPS, and the CM12 site is configured on installation to use either a mix of both protocols, or HTTPS only.
In the old Native mode in CM07, you had to cater for certain scenarios, such as Build and Capture task sequences, where the system normally doesn’t join the domain (to avoid picking up group policy, logon scripts and other domain-based configurations). It takes a little more effort, but it works just fine.
Things are a bit different in CM12, and I’ve been picking away at a particularly annoying problem in my lab environment, which is configured to only use HTTPS. This isn’t really a scenario most ConfigMgr administrators are likely to encounter, but I figured that this was the configuration most likely to break something…..guess I was right 🙂
The specific problem is this:
- You create a Build and Capture task sequence which has one or more Install Applications or Install Software Updates steps;
- The task sequence is either classic CM or MDT-integrated;
- The task sequence does not join the system to the domain;
- The CM hierarchy is configured for HTTPS communications only;
- The task sequence is started from either PXE or boot media with an imported PKI client certificate;
- The task sequence runs successfully until the Install Applications step, at which point the task sequence fails with a generic 0x80004005 error;
- The log files are of little or no earthly use.
What’s happening is that the workgroup system is failing to be properly assigned to a site. It’s finding the management point (which has been published via DNS) but because it doesn’t have a locally-installed PKI client certificate, it can’t talk to an HTTPS-only management point. CM07 had an option to use HTTP for site assignment, but CM12 doesn’t have this fallback position.
There are a number of ways around this, but my challenge was to find a solution which didn’t involve changing the security settings in the CM12 hierarchy or joining the system to the domain during the Build and Capture. The trick to achieving this is how to get a valid PKI client certificate into the operating system during the build process before the CM12 agent gets installed, especially considering that the OS installation and agent installation are all part of the same step. Before that step, you’re still in WinPE, after that step, it’s too late.
This is a bit lengthy, so read on for the full solution.
Step 1 – Generate a Client Certificate
This is the easy bit. You just need a valid PKI client certificate which gets exported, along with its private key for importing later on. For this you just need a domain-joined system which can talk to the CA.
The certificate template I used was the same as the ConfigMgr Client Certificate template I created to support HTTPS communications in CM12. So, in the Certification Authority console:
- Right-click “Certificate Templates” and select “Manage”;
- Right-click “ConfigMgr Client Certificate” and select “Duplicate Template”;
- Select “Windows Server 2003 Enterprise”;
- In the General tab, change the certificate Template Display Name to “ConfigMgr Workgroup Client Certificate”;
- In the Request Handling tab, tick “Allow private key to be exported”;
- In the Subject Name tab, select “Supply in the request”;
- In the Security tab, select “Domain Computers” and untick the “Autoenroll” permission;
- Select OK.
Back in the Certificate Authority console, right-click Certificate Templates and choose “New” –> “Certificate Template to Issue”. Choose the newly-created template from the list and select OK.
Now, on a domain system (it can even be the CA), launch the Certificate MMC snap-in for the Local Computer:
- Go to Personal –> Certificates;
- Right-click Certificates and select “All Tasks”, “Request New Certificate”;
- Select “Active Directory Enrolment Policy” and click Next;
- Tick “ConfigMgr Workgroup Client Certificate” and click the link directly underneath which is prompting for more information;
- In the Subject tab, select “Common Name” from the Subject Name drop-down and type in “Workgroup PKI” in the Value field;
- Select Add, and OK;
- Select Enrol.
The new certificate should now appear in the MMC window. Right-click the certificate and select All Tasks –> Export:
- In the Export Private Key window, select “Yes, export the private key”;
- In the Export File Format windows, tick “Include all the certificates….” and “Export all extended permissions”;
- Select and confirm a password, and then a location for the PFX file;
- Export completed.
Step 2 – Bring the PKI Certificate into Configuration Manager
It’s easy enough import an exported PFX file using Configuration Manager as a command line step, but this isn’t going to help us in this scenario. You can’t import a certificate into the OS from WinPE (mainly because the OS hasn’t been installed yet) and as already mentioned, after the “Setup Windows and ConfigMgr” step it’s too late.
However, MDT to the rescue! 🙂
So yes, you will need to have MDT 2012 integrated into your CM12 environment and be using an MDT-integrated task sequence. Why? Because whenever the “Use Toolkit Package” step is called, everything within the MDT package gets copied down to the _SMSTaskSequence folder on the local system. That gives you a lot of flexibility to call on your own resources during a task sequence.
In my case, I just copied the exported PFX file to the SCRIPTS folder in the already-configured MDT Toolkit package. If you haven’t already created an MDT package for use within Configuration Manager, just create a new MDT-integrated task sequence – it will prompt you to create the package. Make sure the PFX file is in the SCRIPTS folder (it doesn’t particularly have to be there – that’s just what I used) and ensure it’s been distributed to all distribution points.
Step 3 – Import the Certificate during the Windows Build
This was a tricker solution to find.
One of the steps in creating an MDT-integrated task sequence is that you’re prompted to create a new Settings package. This creates Unattend.xml and a CustomSettings.ini files for use during the task sequence.
On a system with the Windows Automated Installation Kit (WAIK) installed, launch System Image Manager and open the Unattend.xml. Make sure that it’s associated with a Windows catalog for the correct architecture version of Windows (eg: x86 or x64).
In the Windows Image section:
- Expand Components;
- Expand amd64_Microsoft-Windows-Deployment_6.1.7600.16385_neutral (assuming your architecture is x64);
- Expand RunSynchronous;
- Right-click RunSynchronousCommand and select “Add setting to Pass 4 specialize”.
In the Answer File section:
- Navigate to the newly-added setting under pass 4 specialize;
- Change the Description to “Import PFX”;
- Change the Order to the last in the list (eg: Order = 3);
- Change the Path to “cmd /c certutil -f -p password-importpfx %deployroot%scriptsexportedcert.pfx” (without the quotes);
- Ensure the Will Reboot is set to “Never”;
- Expand RunSynchronousCommand and right-click “Credentials” and select Delete.
Save and exit System Image Manager. Make sure that the Settings package is updated in the Configuration Manager console so that the latest version is copied to the distribution point.
Step 4 – Create a new Configuration Manager Client Package
To force the CM agent to pick up the PKI certificate, we need to force the issue.
In the Configuration Manager console, go to the Software Library. Right-click Packages and select “Create Package from Definition”. Step through the process of creating a standard Configuration Manager client package.
- Right-click on the newly-created package and select Properties;
- Change the package name to “Configuration Manager Workstation Client” and select OK;
- In the Programs tab underneath, right-click the program “Configuration Manager agent silent upgrade” and select Properties;
- Change the command line executable to “CCMSETUP.EXE /UsePKICert /NoCRLCheck /MP:mp.fqdn SMSSITECODE=XXX” (without the quotes);
- Click OK and distribute the package.
Step 5 – Customising the Task Sequence
To bring all of this together in the task sequence, there are a couple of changes which need to be made. Open up the task sequence in the Software Library:
- Go to the step called “Format and Partition Disk 6.1” (assuming you’re deploying Windows 7);
- Delete the small partition which MDT will create for BitLocker;
- Edit the remaining large partition and tick “Make this the boot partition”;
- Next, go to the step “Setup Windows and ConfigMgr”;
- Change the referenced Package to “Configuration Manager Workstation Client”;
- In the installation properties, enter “DNSSUFFIX=dnssuffix CCMHTTPSSTATE=31″ (without the quotes);
- Select OK to close down the task sequence
What Happens Now?
When you run the updated task sequence, the PFX file will be copied down to the local machine as part of the “Use Toolkit Package” step.
After the operating system is laid down, the RunSychronousCommand item configured earlier will run and will import the PFX file. The MDT variable %deployroot% will be resolved as C:_SMSTaskSequence. If we hadn’t removed the BitLocker partition it would have resolved as D:_SMSTaskSequence because WinPE assigns a drive letter to all partitions, but Windows 7 does not assign one to the BitLocker partition, so the RunSychronousCommand step would have failed.
When the Configuration Manager client is installed, it will be forced to use the PKI certificate, told which management point to look for and told to work in HTTPS mode. It will then be able to be assigned to the site correctly.
Subsequent Install Applications and Install Software Updates steps in the task sequence will run successfully. Once the system is sysprepped, the imported PKI certificate will be stripped out.
This solution may seem convoluted, but it overcomes the issue without having to change any settings in the CM hierarchy and it keeps the Build/Capture process as clean as possible.
So far, this has been the biggest hurdle I’ve encountered in running CM12 in a pure HTTPS environment and it took quite a while to resolve.
Onwards and upwards with CM12 🙂 (damn I hate trying to write pithy conclusions……)