ConfigMgr Build 1602– Deploy overview

Today I see that ConfigMgr current Branch B1602 released, I installed it onto 1511 today, and thought I’d put together a brief guide to provide a light overview of the installation process, showing how easy it is now that it is integrated into the product. Configuration Manager as a Service (CaaS) really is kicking in, with the flow of change ramping up.

The actual Updates and Servicing feature entirety relies on the Service Connection Point role that was introduced in Configuration Manager Current Branch (and LTSB), and I suspect that in a day or two, when standing up a Build 1511 Site server, and then deploying this role, you will see Build 1602 showing within minutes of the first sync, whereas today, it may take a few more hours before everyone can see the update pack globally.

To deploy a 1602 site server you must first deploy the ‘baseline’ build, which is currently 1511. You can move from 1511 to 1602 in both offline and online modes (offline servicing just means having the 1602 kit to hand and not downloading from the internet). After a year, a new baseline build should replace 1511, resulting in a single installation taking place to get to the current build. I would not expect that to last long, and that a double-install will be the norm, since these update packs are released (cadence) quite quickly.

Here’s the release version matrix for current branch as it now stands:

Note that 1602 updates a 1511 Database. It most likely will always be okay until it isn’t okay, so please make sure you are backing up your SQL DB Unlike past versions of Configuration Manager, if installing an update fails, you should not need to perform a site recovery, and instead can Retry the update installation. Therefore, while the test upgrade of the database is less critical than in past product versions, it still remains as a concern, and a recommended step (more so for production!).

On the subject of database changes and failure during upgrade, you should note this statement in the documentation here

Unlike past versions of Configuration Manager, if installing an update fails you should not need to perform a site recovery and instead can Retry the update installation. Therefore, while the test upgrade of the database is less critical than in past product versions it remains a recommended step.

Failure during upgrade can be retried, previously the show was over, and a restore was needed, pretty rad that!

• Here’s a 1511 Site server showing 1602 has arrived

• Clicking on the 1602 update pack will give you some options via the Ribbon or a Right click

I’ve already covered most of how the Updates and Servicing mechanism works in this blog post here, in this post I’ll simply walk lightly over deploying Current Branch Build 1602 to a lab based Stand-alone Primary Site server.

Let’s get the upgrade from B1511 to B1602 underway.

• Go create a device collection, call it Client Pre-deployment (Validation of B1602)
• Add some devices to the new collection, these will be automatically updated for us

• From the Console, go to Administration, Cloud Services, Updates and Servicing,
• If Build 1602 does not show, then from the ribbon or a right click select Check for updates
• If it shows then most likely its already been downloaded, but if it doesn’t show and initiating a check for updates or a recycle of the SMS_Executive service gets it to appear, check the DMPDownloader log file on the Site server

• You should see that something is afoot, a cab being downloaded, unpacked and verified

• Here you can see the download of the update pack has completed

Even though we can retry if there is any failure during the upgrade while dealing with SQL, it would make sense to copy your database over to a server hosting the same SQL edition (with service packs and hotfixes as the ConfigMgr Database Site server) so as to test the upgrade on your database using TestDBUpgrade. I’d do this every single time with production, for the lab I don’t bother. That a retry after upgrade failure is supported indicates that most likely over coming releases, we should see far more robustness of the whole SQL upgrade process until nursing it becomes a distant memory.

Check out Nickolaj Andersen post here on handling TestDBUpgrade, it is pretty simple, takes a bit of effort to keep SQL server like for like, although for 1602 I didn’t dig out where the install kit was pre-installation, and after it’d been downloaded, you’ll have to go find the installation kit (might be in cab only form at this point, or in unpacked form, go eek it out) in the ConfigMgr folder once 1602 state changes to available.

• One you are ready to proceed with the upgrade, from the Updates and Servicing node, right click the 1602 update pack

• Select Install Update Pack

• We’re welcomed by the Configuration Manager Updates Wizard
• You can tick Ignore any prerequisite check warnings and install this update regardless of missing requirements, so as to override any warnings regarding requirements not being met, or let it stall and notify you so you can resolve them
• Select Next

• This is where we select the features we want installed, as you can see 1602 delivers

• Apple Volume Purchase Program
• Windows 10 conditional access with health attestation service
• iOS Activation Lock management
• iOS App configuration

• Tick or untick the features you are interested in
• Select Next

• Your choice on whether you update your current production ConfigMgr Client package with Build 1602 Client kit straight off, or whether you stage the event, and when confident perform the update later
• Select Browse

• Find the collection you created earlier
• Select OK

• Looking good, we’re going to validate the client in pre-production, by deploying to a specific collection of devices and not the entire estate
• Select Next

• Tick the licence agreement checkbox
• Select Next

Select Next

• Select Close

• From the Updates and Servicing node we can see that things are underway

• If you have a CAS there is over 1GB of content that needs to be replicated, for a stand-alone primary this shouldn’t take more than a few minutes

• Once the staging is complete, the prerequisite checker will kick in

• This part will take a long time

• Once the prerequisite checker has completed with no errors (and that we’re ignoring or observing missing requirement warnings) you should see the status transition to Installing 

• Let’s take a look at the prerequisites
• Head to Monitoring, Site Servicing Status, and from the Ribbon or a right click select Show Status

• We can see what did and didn’t pass …
• Also check out the CMUpdate log

• Once the update packs status changes to installed, check out the SiteComp log to make sure all the components\roles have reinstalled correctly

• Here is a resource record of a device in the pre-production collection that was automatically updated for me

If you had any consoles open, after a bit of cruising they should start to prompt you to upgrade to a newer version. Opening a new 1511 console will produce the same prompt until it has been accepted, which will kick off the console upgrade.

• Accepting the upgrade will get the Console MSI downloaded from the Site server and the upgrade process underway

• MSI Logic detected that I had a Console related executable still in memory, Status Message Viewer, which was blocking the upgrade, so I closed that manually and clicked OK

The MSI Installer then rolls off the older version, and rolls on B1602.

• A quick nose around the Features node of Updates and Servicing shows us the features, which can be viewed in the documentation here:

Also, my three test clients all upgraded to 1602 as well. I did have a delay here, am not 100% sure right now what caused it, but the clients all kicked off their upgrades once they fetched their policy from the MP.

Okay that’s it, done, and it was easy wasn’t it!

Once we are all good with the client upgrade, we can switch 1602 Client kit to become the production kit used for all future clients deployments

• Navigate to the Updates and Servicing node again

• From the Ribbon or a Right click select Client Update Options

• Tick I am ready to make pre-production client version available to production
• Select OK
• Get the hierarchy Settings up and you’ll see that pre-production deployment has been turned off, and the production client version has changed to 5.00.8355.1000

You could also check at the file level to make sure the client files have been upgraded, perhaps I’ll circle back for that fully and update the guide another time, here is a shot of CCMSETUP.EXE to show its version (8355 is 1602)

Feature-wise In-place upgrade the operating system of site servers that run Windows Server 2008 R2 is a real winner, enabling many quick upgrades to supported OS versions without a backup\restore being needed. Very enabling, as is SQL Server AlwaysOn availability groups. For mobility there’s a whole bunch of iOS MDM related features pouring in too, nice, and cloud-wise we have more management over Office 365 usage\deployment. For the full list of features don’t forget to check out the documentation.