There are a few things we can consider, so in this post I’m going to focus on software deployment – how to get applications for OS X imported into Configuration Manager, and how to get those [...]]]> So now that you’ve got OS X clients happily chattering away to the CM12 SP1 primary site, what next?

There are a few things we can consider, so in this post I’m going to focus on software deployment – how to get applications for OS X imported into Configuration Manager, and how to get those same applications out and installed onto the client.

A prerequisite is to have at least one OS X client installed and registered with Configuration Manager – read my blog post here on how to achieve this.

Next, we need some software.  I’m going to use the latest version of Mozilla Firefox for OS X for this example – you can grab the latest version here.

Step 1 – Repackage the application

Windows doesn’t understand applications designed for OS X, which means that Configuration Manager can’t work with them natively either.  They need to be repackaged into a format which CM can work with.

For this, we’ll need an OS X client which has access to the Configuration Manager agent package as well as the application you want to deploy.

In the Tools folder of the Configuration Manager package (the same location as the CMEnroll utility) is a utility called CMAppUtil.  This is used for repackaging OS X applications to a custom .CMMAC format which can be imported into the Configuration Manager Software Library.

Here’s a short dump of the help content:

Usage: CMAppUtil -h CMAppUtil -r <filename.cmmac> [-v] CMAppUtil -c <source file> -o <output file> [-a] [-s] [-v]

Description: The CMAppUtil utility enables conversion of application installation files into the cmmac format which is compatible with System Center 2012 Configuration Manager. During the conversion process the CMAppUtil utility detects the parameters required by the Configuration Manager client to determine the application installation state.

The utility supports conversion from .APP, .PKG, .MPKG and .DMG formats.

Our downloaded Firefox executable is a .DMG (Firefox 16.0.2.dmg, to be precise), so the usage will be (from the Tools folder):

sudo ./CMAppUtil -c /Users/james/Desktop/DMGs/Firefox\ 16.0.2.dmg -o /Users/james/Desktop/cmmac\ Apps

Note that the filepaths are absolute from root, and that the -o switch to specify the output doesn’t require an output filename as this happens automatically.

Convert Firefox to .CMMAC format

Now, copy the resulting .CMMAC file (in this case Firefox.app.cmmac) to a location accessible by the Configuration Manager console.

Step 2 – Import the Application

In the Configuration Manager console, navigate to the Software Library and select Applications.  Right-click, select “Create Application”, select “Mac OS X” from the drop-down list and enter the UNC location of the .cmmac file created in Step 1:

Navigate to the .cmmac file

Click though the wizard and manually enter the application details – Configuration Manager can’t extract and pre-populate this information as it can with MSI or App-V applications.

Take a look at the Properties of the newly-created Deployment Type and navigate to the “Detection Method” tab.  As you can see, Configuration Manager understands enough from the package to create a detection method which will allow the agent to discover whether the application has already been installed, or whether it has been successfully installed.  In many ways, this functionality is core to the AppModel in Configuration Manager 2012.

Detection method for Firefox on Mac OS X

Before deploying the application, distribute the content to an internet-enabled distribution point.

Step 3 – Deploy the Application

Create a new Deployment for the Application.  At present, the only supported Deployment to OS X clients are Required to Device Collections:

Deploy the Application to a Device Collection with OS X clients

Next, to trigger a policy refresh on the OS X client, open System Preferences and then the Configuration Manager pane under “Other”, then click “Connect Now”:

The agent will talk back to the Management Point and download the machine policy, at which point the user should be presented with an alert that there is an active deployment:

Software Deployment – User Alert

Click “Install Now” to trigger the deployment immediately.  The content will download and the installation will be triggered…

OS X Software Deployment – Progress Bar

…and the user will be notified once the installation is complete:

OS X Software Deployment – Completed Installation

Check out the Applications folder and there’s the newly-deployed software

The client will report back to the site server, and the deployment compliance will be adjusted accordingly, as will software inventory the next time it runs.

Why is this a big deal? Well, if you need to rapidly provision a DP but don’t have the present ability to scale your current [...]]]> Apart from native agent support for Mac OS X, another of the big features of Configuration Manager 2012 SP1 is the ability to deploy “Cloud” Distribution Points on Windows Azure.

Why is this a big deal? Well, if you need to rapidly provision a DP but don’t have the present ability to scale your current environment or can’t provide server infrastructure to remote sites, a Cloud DP will allow you quickly set up a content location accessible from anywhere at a very low cost.  Cloud DPs also allow businesses to service internet-connected clients without having to set up internet-facing Configuration Manager server roles, and also to rapidly provision DPs which are catered for within operational expenditure rather than capital expenditure.  They offer new flexibility to the management story which is quite exciting.

Prerequisites

Setting up a Cloud DP is actually very straightforward, and there are only a few things needed before you begin.

1. A current Windows Azure subscription.  Obviously – otherwise this isn’t going to get off the ground If you are an MSDN subscriber (or you have access via a company subscription) then you have access to a limited Azure subscription – activate it via the MSDN Subscriber Benefits page;
2. Your Windows Azure subscription ID. Once the Azure account is activated, you can get the Subscription ID by logging into the Management Portal and navigating to “Hosted Services, Storage Accounts & CDN”, then “Affinity Groups”.  The Subscription ID is on the right-hand side of the screen;
3. A Management Certificate.  This is a locally-generated certificate which is uploaded to Windows Azure AND used by Configuration Manager to establish secure communications;
4. A Configuration Manager hierarchy running Configuration Manager 2012 SP1 Beta (build 7782) or later.

Management Certificate

There are a number of ways you can create the management certificate.  At present there isn’t much guidance on the best approach, so this section explains how I did it in my own lab environment, which is configured for PKI with an Enterprise CA.

1. On the CA, open the Certification Authority management snap-in, right-click on Certificate Templates and select Manage;
2. Right-click the “ConfigMgr Web Server Certificate” template (or whichever template you prefer to use for HTTPS communications) and select “Duplicate Template”;
3. Give the new template a name like “Windows Azure Authentication Certificate” and make the following changes: In “Request Handling” tick “Allow private key to be exported”, In “Subject Name” select “Supply in the request” and in “Security” ensure that the AD computer account for the primary site server has Read and Enroll permissions, either explicitly or via an AD group;
4. Save the template, exit the Certificate Templates Console, then right-click on Certificate Templates, select “New” –> “Certificate Template to Issue” and choose the newly-created template for Windows Azure;
   

   PKI Certificate for Configuration Manager/Windows Azure authentication

5. Next, go to the Certificates MMC snap-in on the Configuration Manager site server and load the Certificates for the Computer Account;
6. Expand Personal –> Certificates, then right-click Certificates and select “All Tasks” –> “Request New Certificate”;
7. Select the Windows Azure certificate from the list of available certificates and click on “More information is required…”;
8. In the Certificate Properties window, in the “Subject” tab add in the Subject Common Name and the DNS Alternative Name of the name of this hosted service.  For example, if you want to call the Cloud DP “cm12clouddp1″ then the full name is “cm12clouddp1.cloudapp.net”;
   

   Certificate Properties – Subject Name and Alternate Name

9. Finish the enrolment and the certificate will populate the snap-in;
10. Next, right-click the newly-enrolled certificate and select “All Tasks” –> “Export”;
11. The Export process needs to be run through twice: the first time select “No, do not export the private key” and then export the certificate as a “DER encoded binary X.509″ .CER file. The second time select “Yes, export the private key” and export it as a “Personal Information Exchange” .PFX file.  You will need both exports later.

Upload the Management Certificate

1. Open the Windows Azure Management Portal and navigate to “Hosted Services, Storage Accounts & CDN”, then “Management Certificates”;
2. Click on “Add Certificate” and then select the appropriate subscription and browse to the exported CER file created earlier;
3. Wait for the console to refresh and ensure that the Management Certificate has been uploaded correctly.
   

   Uploaded Management Certificate in Windows Azure

Creating and Configuring the Cloud DP

Now that the prerequisites are taken care of, we can create the Cloud DP.

1. Open the CM Console and navigate to Administration –> Hierarchy –> Cloud and then click on “Create Cloud Distribution Point”;
2. Type in the Windows Azure Subscription ID and browse for the exported PFX;
3. In Settings, the service name will be automatically created by Azure.  Select the desired Azure global region (eg: Southeast Asia) and which site the Cloud DP is going to be associated with;
4. In Alerts, specify the quotas in terms of the amount of available storage and the monthly transfer quota;
5. Complete the wizard (that’s all the information it needs) and open up the CloudMgr.log file located in the Microsoft Configuration Manager\Logs folder;
6. The SMS_CLOUD_SERVICES_MANAGER component will initially connect to Windows Azure and create a new storage service – you can watch this in action via the “Storage Accounts” section in the Windows Azure Management Portal;
7. This bit can take some time – the log file will probably show a series of entries like “Skipping safe exception Microsoft.WindowsAzure.StorageClient.StorageServerException. Will check again in 10 seconds.” and “Waiting for check if container exists. Will check again in 10 seconds.”.  Eventually it may time out with an entry “ERROR: Timed out after 00:05:00 minutes waiting for check if container exists.”.  Don’t stress, things are still happening;
8. In my case, around 15 minutes after the timeout entry (with no further input from me), CloudMgr.log updated with “Uploading file ContentWebRole.cspkg to container deploymentcontainer with blob name xxx”.  Behind the scenes, the storage account has been provisioned and Configuration Manager has taken all the information provided in the Cloud DP wizard and bundled it into a .CSPKG file.  Windows Azure will now use that to provision a full hosted service into production;
9. Keep following the logfile and within around 20 minutes (approximately) the service will be provisioned.  Refresh the Cloud section in the Configuration Manager console, and the new Cloud DP will have a “Status Description” of “Provisioning Complete”;
10. Navigate to Administration –> Distribution Points, and the Cloud DP will be there along with your on-premise
    

    Provisioned Cloud DP on Windows Azure

    DPs.

Distribute Content

Distributing content to a Cloud DP is exactly the same as for a traditional DP.  In the example of using an AppModel-type Application:

1. Right-click the Application and select “Distribute Content”;
2. For the content destination, select “Distribution Point” from the Add drop-down (or “Distribution Point Group” if the Cloud DP is a member of a DP Group) and select the Cloud DP from the list of DPs;
3. Open up the distmgr.log and watch Configuration Manager deploy the content to the Cloud DP;
4. Navigate back to Administration –> Distribution Points.  Right-click the Cloud DP and select “Content” – the recently-deployed content should now be visible.

If you want to verify that the content really is there, I recommend a free tool called Azure Storage Explorer, which is available here via CodePlex.  To add a Storage Account to view, you will need the name of the Storage Account as well as the Primary Access Key, both of which are accessible in the Windows Azure Management Console under “Storage Accounts”.

Once connected, under the “blobs” section should be a folder called “content-PKGID” where PKGID is the Package ID of the content you just distributed to Azure (eg: S0100001).  Select that and you’ll see the actual files which have been uploaded and are now available for clients.

Content distributed to Windows Azure

So, you now have a Distribution Point up in the cloud ready to distribute content to clients.  In the next blog post, we’ll look at how clients will access that data

As you’d expect with any sort of cross-platform, non-Windows management story, you won’t be able to do all the same things with Configuration Manager that you can do with [...]]]> One of the (many) big changes in Configuration Manager 2012 SP1 is the ability to enrol and manage Mac OS X clients using a native agent.

As you’d expect with any sort of cross-platform, non-Windows management story, you won’t be able to do all the same things with Configuration Manager that you can do with a Windows platform.  Functionality in SP1 for Mac OS X will consist of:

1. Hardware inventory
2. Software inventory
3. Application deployment
4. Configuration deployment and compliance

And that’s not a bad list to be starting with

So how do you set this up and get Macs enrolled?  Microsoft has a step-by-step guide here which contains all the information you’ll need, and it’s what I used to get my lab environment up and operational.  So here’s my take on the whole process.

Requirements:

1. Mac OS X clients running either Snow Leopard (10.6) or Lion (10.7).  At the time of writing SP1 Beta was used (Build 7782) which does not support Mountain Lion (10.8);
2. Configuration Manager hierarchy running Configuration Manager 2012 SP1 Beta (Build 7782) or greater;
3. Configuration Manager 2012 SP1 site server should be running on Windows Server 2008 R2 SP1.  Build 7782 does work on Windows Server 2012, but it’s slightly buggy and I lost a huge amount of time in troubleshooting.  Stick with W2K8R2 for the moment and save yourself a headache;
4. Configuration Manager hierarchy needs to be configured to support HTTPS communications, so you’ll need to go through setting up PKI.  The reason for this is that Mac OS X clients are treated as internet clients at all times.  This means that they are manageable regardless of where they are (assuming your site server is externally-accessible) but also that they don’t need to be joined to the domain.  Check out this post for PKI certificate requirements in CM12;
5. A PKI certificate template for enrolment on Mac clients. Full information on the process is here.

Site Server Configuration

1. In the Site System role for the primary site server (and every server which will service Mac clients), tick the option “Specify an FQDN for this site server to use on the Internet” and enter the FQDN.  For the purpose of lab testing, this can be the internal FQDN of the site server – it doesn’t HAVE to be accessible externally;
   

   Internet-enabled Site System server role

2. In the Distribution Point role on the primary site server (or wherever Mac clients will get content from) make sure that the DP is configured for HTTPS and from the drop-down menu, select “Allow intranet and Internet connections”.  Also import a CA-signed certificate for use on the DP;
   

   DP enabled for Internet access

3. In the Management Point role ensure that the role is configured for HTTPS, select “Allow intranet and Internet connections” from the drop-down list and tick the option “Allow mobile devices to use this management point”;
   

   Management point enabled for Internet access and mobile devices

4. Install the server roles Enrollment Point and Enrollment Proxy Point.  Both should be configured for HTTPS, but need no further configuration.
5. Edit the Default Client Settings policy. Ensure that Hardware Inventory, Software Inventory and Compliance Settings policies are enabled.  Then, go to the Mobile Devices policy and change the option “Allow users to enrol mobile devices” to Yes, then click on Set Profile to create a new enrolment profile;
6. In the Enrollment Profile screen click “Create”.  Give the new profile a name like “Mac Enrollment”, select an internet-enabled management site code, add the relevant CA and select the certificate template created earlier for Mac enrolment.
   

   Mobile device profile for enrolling Mac clients

Quick Summary

What we’ve now got in an SCCM 2012 SP1 hierarchy configured with HTTPS, supported by a CA and with all the necessary server roles installed and configured for an “external” client to request enrolment.  That client is our Mac system, so now we’re heading over there to continue

Mac Client Installation and Enrollment

1. Ensure that the Mac system can resolve the “external” FQDN of the site server.  If you need to edit the hosts file to fudge it, from Terminal run “sudo nano /etc/hosts” and add an entry.  Open Safari and navigate to https://fqdn.siteserver and ensure that you get the IIS welcome page;
2. Copy across the Mac client – macclient.dmg - which is located in the SMSSETUP\MacOSClient folder within the Configuration Manager 2012 SP1 media;
3. Open the macclient.dmg package and extract the contents somewhere – I created a folder called “MacCMClient” on the Desktop. You should have the following files: ccmsetup and CMClient.pkg, and a Tools folder containing CMAppUtil, CMDiagnostics, CMEnroll and CMUninstall;
   

   Contents of the CM client package for OS X

4. Open Terminal and navigate to the extracted files, then type in “sudo ./ccmsetup“.  This installs the client and will prompt for a reboot once complete – do NOT reboot at this point in time!
5. Next, navigate to the Tools folder in Terminal where the CMEnroll utility is, and enter the following: “sudo ./CMEnroll -s fqdn.siteserver -ignorecertchainvalidation -u ‘DOMAIN\Username’” where DOMAIN\Username is an account which is authorised to enrol the Mac certificate;
6. The utility will contact the enrolment point on the site server, request a certificate and will (all being well) retrieve it and install it on OS X.  Watch the EnrollmentService.log file in the SMS_CCM\EnrollmentPoint\Logs folder on the site server to see the request being received and processed.  Now you can reboot the Mac;
   

   Enrollment process captured in EnrollmentService.log

7. On restart, go to System Preferences, Configuration Manager.  The Preference pane should show that the certificate has been installed and that the system is talking to the CM management point via HTTPS;
   

   Configuration Manager Preferences Pane in OS X Lion

8. To verify that the certificate has been installed correctly, go to Utilities, Keychain Access.  Under Keychains select “System”, and the under Category select “My Certificates”.  In the main panel should be a certificate registered with the same name as the Mac system.  Expand the certificate and it should be linked to a Private Key named “SCCM”.  Double-click on the private key and then select “Access Control”.  Under “Always allow access by these applications” should be CCMClient and CMEnroll.  The CCMClient and CCMAgent applications can be found under /Library/Application Support/Microsoft/CCM, along with the Logs folder;
   

   CM Certificate and Private Key enrolled in Keychain Access

9. Now, check the CM console.  Under Devices the Mac OS X system should appear, active and Approved.  Initially the system icon will be a mobile device, but once hardware and software inventory have been run the icon will switch to that of a standard workstation.  Right-click the device and go Start –> Resource Explorer to see the results of the hardware and software inventories.
   

   Resource Explorer of an OS X client

And that’s about it – your Mac is enrolled and chatting away happily

Stay tuned – the next step is to look under the covers into how to actively manage and troubleshoot Mac clients, how to deploy software to Macs and how to generate and enforce compliance settings.

UPDATE 12/09/2012 - The SIM314 vFuture session had to be pulled because SCCM 2012 SP1 Beta was not going to be ready in time. Then it was released right at [...]]]> TechEd Australia 2012 is back to the Gold Coast, and I’m very pleased to announce that I will be presenting three FOUR! sessions this year.

UPDATE 12/09/2012 - The SIM314 vFuture session had to be pulled because SCCM 2012 SP1 Beta was not going to be ready in time. Then it was released right at the start of TechEd Australia So rather than miss out on the session entirely, it has been moved to Friday 14th at 1:45pm in Meeting Room 9 with a new session code of SIM334a. I’ll be co-presenting the session with Andrew McMurray.

Additionally, in place of the original SIM314 session, I’m doing a Deep Dive session into the AppModel in Configuration Manager 2012.  The details are:

SIM414 Deep Dive – System Center Configuration Manager 2012 AppModel

Session Type: Track Session
Level: 400
Track: Security, Identity and Management
Abstract: Discover the magic behind the new AppModel in Configuration Manager 2012, which enables administrators to deploy and manage applications on current and future versions of Windows, anywhere within your private cloud. Users quickly get access to the applications they need, while administrators no longer need to use monolithic operating system images or layers of task sequences, and applications are managed fully throughout their lifecycle.

Click here for more information.

SIM334a vFuture – Configuration Manager 2012 SP1 – BEHOLD THE AWESOME!! (UPDATED)

Session Type: Track Session
Level: 300
Track: Security, Identity and Management
Abstract: Configuration Manager 2012 SP1 is imminent, and radically changes the framework of systems management. Apart from a range of significant architectural enhancement, it brings a wealth of support for next-gen technologies including Windows 8, Metro applications and App-V 5.0, and opens the playing field for cross-platform management of non-Windows operating systems, including Mac OS X. Come along and check out the future of systems management.

Click here for more information.

 SIM425 Migrate from Configuration Manager 2007 to Configuration Manager 2012

Session Type: Track Session
Level: 400
Track: Security, Identity and Management
Abstract: Configuration Manager 2012 is here – it’s no longer academic! In this session we work through a live, uncut, down-and-dirty, demo-driven migration from SCCM 2007 to SCCM 2012 – everything you need to know for your own Configuration Manager environment.

Click here for more information.

WCL331 VDI in Windows Server 2012

Session Type: Track Session
Level: 300
Track: Windows Client
Abstract: Out-of-the-box, Windows Server 2012 presents you with a massive opportunity to deliver a flexible, powerful and comprehensive managed VDI environment. Find out why Server 2012 will drive VDI, and how you can take immediate advantage.

Click here for more information.

MGT401: Migrate from Configuration Manager 2007 to Configuration Manager 2012 Track: Management Session Type: Breakout Session Level: 400 Abstract: Configuration Manager 2012 is here [...]]]> The sessions have been announced for TechEd New Zealand 2012, and I’m very pleased to announce that I will be presenting two level 400 sessions on Configuration Manager 2012:

Session 1

MGT401: Migrate from Configuration Manager 2007 to Configuration Manager 2012
Track: Management
Session Type: Breakout Session
Level: 400
Abstract: Configuration Manager 2012 is here – it’s no longer academic! In this session we work through a live, uncut, down-and-dirty, demo-driven migration from SCCM 2007 to SCCM 2012 – everything you need to know for your own Configuration Manager environment.

Click here for more information.

Session 2

MGT402: Deep Dive – System Center Configuration Manager 2012 AppModel
Track: Management
Session Type: Breakout Session
Level: 400
Abstract: Discover the magic behind the new AppModel in Configuration Manager 2012, which enables administrators to deploy and manage applications on current and future versions of Windows, anywhere within your private cloud. Users quickly get access to the applications they need, while administrators no longer need to use monolithic operating system images or layers of task sequences, and applications are managed fully throughout their lifecycle.

Click here for more information.

Looking forward to seeing all you NZ IT Pros in Auckland!

It was great to present to such an engaged and engaging audience, all of whom had great, relevant questions. It absolutely made it a highly enjoyable presenting experience [...]]]> This week I was pleased to present three sessions on Configuration Manager 2012 at the Technical Conference component of the VITTA education conference: Reign of the Cloud.

It was great to present to such an engaged and engaging audience, all of whom had great, relevant questions.  It absolutely made it a highly enjoyable presenting experience

Some people were requesting the slide decks, so here they are:

• Session T202 – Windows Deployment with Configuration Manager 2012 – Introduction.  Click here.
• Session T301 – Windows Deployment with Configuration Manager 2012 – Advanced.  Click here.
• Session 504 – Application Management with System Center 2012.  Click here.

In the [...]]]> 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 0×80004005 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:

1. Right-click “Certificate Templates” and select “Manage”;
2. Right-click “ConfigMgr Client Certificate” and select “Duplicate Template”;
3. Select “Windows Server 2003 Enterprise”;
4. In the General tab, change the certificate Template Display Name to “ConfigMgr Workgroup Client Certificate”;
5. In the Request Handling tab, tick “Allow private key to be exported”;
6. In the Subject Name tab, select “Supply in the request”;
7. In the Security tab, select “Domain Computers” and untick the “Autoenroll” permission;
8. 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:

1. Go to Personal –> Certificates;
2. Right-click Certificates and select “All Tasks”, “Request New Certificate”;
3. Select “Active Directory Enrolment Policy” and click Next;
4. Tick “ConfigMgr Workgroup Client Certificate” and click the link directly underneath which is prompting for more information;
5. In the Subject tab, select “Common Name” from the Subject Name drop-down and type in “Workgroup PKI” in the Value field;
6. Select Add, and OK;
7. Select Enrol.

The new certificate should now appear in the MMC window.  Right-click the certificate and select All Tasks –> Export:

1. In the Export Private Key window, select “Yes, export the private key”;
2. In the Export File Format windows, tick “Include all the certificates….” and “Export all extended permissions”;
3. Select and confirm a password, and then a location for the PFX file;
4. 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:

1. Expand Components;
2. Expand amd64_Microsoft-Windows-Deployment_6.1.7600.16385_neutral (assuming your architecture is x64);
3. Expand RunSynchronous;
4. Right-click RunSynchronousCommand and select “Add setting to Pass 4 specialize”.

In the Answer File section:

1. Navigate to the newly-added setting under pass 4 specialize;
2. Change the Description to “Import PFX”;
3. Change the Order to the last in the list (eg: Order = 3);
4. Change the Path to “cmd /c certutil -f -p password-importpfx %deployroot%\scripts\exportedcert.pfx” (without the quotes);
5. Ensure the Will Reboot is set to “Never”;
6. 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.

Once complete:

1. Right-click on the newly-created package and select Properties;
2. Change the package name to “Configuration Manager Workstation Client” and select OK;
3. In the Programs tab underneath, right-click the program “Configuration Manager agent silent upgrade” and select Properties;
4. Change the command line executable to “CCMSETUP.EXE /UsePKICert /NoCRLCheck /MP:mp.fqdn SMSSITECODE=XXX” (without the quotes);
5. 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:

1. Go to the step called “Format and Partition Disk 6.1″ (assuming you’re deploying Windows 7);
2. Delete the small partition which MDT will create for BitLocker;
3. Edit the remaining large partition and tick “Make this the boot partition”;
4. Next, go to the step “Setup Windows and ConfigMgr”;
5. Change the referenced Package to “Configuration Manager Workstation Client”;
6. In the installation properties, enter “DNSSUFFIX=dnssuffix CCMHTTPSSTATE=31″ (without the quotes);
7. 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……)

We had a chat about System Center Configuration Manager 2012 (of course!) and a bit about private cloud too.

The interview has now gone online, so here it is!

Hyper-V in Windows 8 Server has had a major uplift. As much as I like working with [...]]]> UPDATE 04/06/2012 – The KDC bug I mention at the bottom of this post has been fixed in Server 2012 Release Candidate. Tested a live migration from a remote WIndows 8 Release Preview client, and all went well.

Hyper-V in Windows 8 Server has had a major uplift.  As much as I like working with Hyper-V in Server 2008 R2, there’s certainly a sense that Windows 8 Server leaves that for dead.

There’s a good Windows IT Pro article about the major changes by Michael Otey, and a really interesting follow-up blog post by Cristof Wegh which I recommend reading.

And now that I have three physical Windows 8 Server Hyper-V hosts up and running in my lab environment, one of the new features I was really keen to test was Live Migration – WITHOUT SHARED STORAGE!!

Turns out that it’s pretty straightforward.  Once the systems are up and running and the Hyper-V role has been installed (which you can do in parallel from a machine which shares credentials, like any domain-joined system, from the new Server Manager) then right-click on the server under Local Server or All Servers (assuming you’ve added them) and select Hyper-V Manager.  Then in Hyper-V Manager, select the host, click on Hyper-V settings and navigate to Live Migrations.

Enable Live Migration

Click “Enable incoming and outgoing live migrations”.  It’s important to note that this isn’t the process to make use of if you’re planning on making the hosts part of a Failover Cluster.  That’s a different process, and Live Migration is automatically configured in those scenarios.

Bear in mind that these are standalone hosts – they are on the same domain, but a shared network is the ONLY thing they have in common.

For the Authentication Protocol, select “Use Kerberos”.  This ensures that Hyper-V hosts can talk to each other and perform migrations without the administrative user needing to be logged on (apart from the little bug which breaks that rule, but more on that later).

Make any other changes needed, such as the amount of simultaneous migrations (dependent upon available network bandwidth) or which management IP addresses to use, and select OK to save the changes.  Make the same changes on all Hyper-V hosts which you want to be able to Live Migrate between.

Next, set up KDC – Kerberos Contrained Delegation – so that the hosts can authenticate.

On a DC, fire up ADUC (Active Directory Users and Computers), find the host computer object, go into its Properties and select the Delegation tab.

Then, select “Trust this computer for delegation to specified services only” and “Use Kerberos protocol”.  Then click Add and search for the host computer object that this host will be migrating TO.  So in my case I modified the properties of WIN88HOST02 in order to migrate to WIN8HOST03.

In the Service Type list, select “CIFS” and “Microsoft Virtual System Migration Service” and OK to close.  Repeat this for each Hyper-V host (eg: do the same for WIN8HOST03 in order to migrate to WIN8HOST02)

Configure KDC for Live Migration

Next, spin up a VM on one of the hosts.  Once complete, in Hyper-V Manager log onto the host server and select Move.  The wizard will prompt you for what sort of move you want, which host it’s going to move to and whereabouts on the remote filesystem.

A few options available...

Finish the wizard and the migration kicks off.  Try setting up a PING -T against the client VM – it’s impressive

Live Migration - No Shared Storage

The amount of time take to perform the migration is going to vary wildly, dependent on the amount of data you’re transferring (Dynamic Disks transfer faster than Fixed Disks, for example) and the amount of network bandwidth available plays a crucial factor.  NIC teaming will help, of course (now supported in Windows 8 Server Hyper-V) as well as using dedicated NICs and 10Gb ethernet.

The eagle-eyed amongst you will have noticed that I had to log onto the host I was migrating from, even though I set up KDC to avoid that particular scenario.  Yes – welcome to the world of beta If you try to kick off the migration from a remote management system, the migration starts and then fails to create the VM folder on the remote system.  The following errors are logged:

• Virtual machine migration operation for ‘TEMP’ failed at migration source
• Migration did not succeed. Failed to create folder: ‘General access denied error’(’0×80070005′).

Thanks to Ben Armstrong for following up on this one – it’s a bug in the beta build of Windows 8 Server.  That’s not supposed to happen, and it will be fixed.

And there we are – Live Migration of a running VM across the network between standalone hosts.  It’s not designed for failover or HA, but now you can move VMs between hosts without having to implement shared storage, clustering or SCVMM.  Perfect for lab environments and SMEs.  So far – Windows 8 Server is SO GOOD