Doing a ConfigMgr 1511 upgrade (Notes from the field)

Recently I did an ConfigMgr 1511 upgrade, where earlier upgrades and clean installs went fine. But this one was a bit different; more like the ConfigMgr 2012 R2 SP1 upgrade before. Before you begin just make sure you have a good backup! Most of time I start with a ConfigMgr backup and snapshot of ConfigMgr and SQL VM's. Better safe then sorry :-)

Then start the 1511 media, it will be finished in around 30 minutes. The crazy part is starting after that. ConfigMgr isn't done with the upgrade (like the 2012 R2 SP1 upgrade before), but running tasks in the background. Strange enough it's hard to see what's the status of that, and sometime it's stuck too and a reboot (or multiple reboots) are needed. Let's have a look again.

When the upgrade wizard is finished and you start the ConfigMgr console, have a look at Site & System status. The MP will be down for almost one hour. When looking at Software Library the ConfigMgr client package and boot images are not updated yet. Because of that OS deployment isn't possible too. Sometimes it will be started automatically within one hour, sometimes a reboot is needed to start processing again. A nasty situation for sure.

Installation progress in short:
 

Management point in critical state

 

No Site Components available

  

SMS Replication Configuration Monitor

 

As I sayed earlier, it can take on hour before the Management point is healthy again and Site Components are back in business. It may help to reboot the Primary server once (or twice), when there's no progress seen (recommended only when nothing changed after one hour). After the reboot you will see that functionality is restored soon! When looking at Software Library the ConfigMgr client package and boot images will be updated now. Still it's a nasty upgrade, because you think it's done in 30 minutes, and not one hour after that.

Management Point installed after reboot

Have a look in mpsetup.log for successful status:
-Installing the SMSMP
-Passed OS version check.
-IIS Service is installed.
-SMSMP already installed (Product Code: {861C35CB-8117-469B-A847-D948AEE1F507}).  Upgrading/Reinstalling SMSMP
-New SMSMP is a new product code {{2627B2A8-5D52-4AE0-87D1-0CCF0145FB3F}}.  This is a major upgrade.
-Enabling MSI logging.  mp.msi will log to D:\Program Files\Microsoft Configuration Manager\logs\mpMSI.log
-Installing D:\Program Files\Microsoft Configuration Manager\bin\x64\mp.msi <parameters>
-mp.msi exited with return code: 0
-Installation was successful.
-~RoleSetup().

 

Site Components back again

CM Client package cannot be updated

After successful management point setup, the client package couldn't be updated: No action specified for the package <?>, however there may be package server changes for this package.

CM Client package updated manually

Therefore I did another update on the package as well. This time it went fine: Successfully created/updated the package server in the data source. After that deployment is possible again.

Why not mention in the wizard, installation is not finished and will take another hour? Or count another hour on the wizard and finish it in 60-90 minutes, instead of running tasks in the background? I guess this can be better with future releases. Hope it helps!

Update 11-2: As Torsten mentioned in comments: This has always been the case: "ConfigMgr isn't done with the upgrade ... but running tasks in the background" - even for CUs or SPs. Just monitor sitecomp.log instead of rebooting the server.

Once the UI is done, in the background the Site Component Manager is kicking off and re-installing all components, and Site systems needs to be re-installed. This can take multiple hours, so prepare for that. Check sitecomp.log for progress on this.

It's preferred to Check the database before doing a ConfigMgr upgrade as well. Happy upgrading! :-)

Path for Upgrading ConfigMgr 2007 to ConfigMgr 2016 (as a service)

Since the ConfigMgr 2012 release (April 2012), I'm doing both implementations and 2007 migrations a lot. ConfigMgr 2012 is still the best choice for on-premises and remote device management.

With Microsoft Intune integration (part of Enterprise Mobility Suite) for mobile device and application management, you have best of both worlds. Microsoft mentions that 'No one else offers this functionality!'. Therefore ConfigMgr and EMS is the best solution for deploying and managing Windows 10 on PC's, tablets and mobile devices.

Additionally, ConfigMgr 2016 (ConfigMgr as a service, which is called just 'ConfigMgr' from now on) will support MDM-based management for Windows devices, fully on-premises, with no ConfigMgr agent required. In that case you can choose between full (with ConfigMgr agent) and MDM-based (no ConfigMgr agent) management.

But what to do if organizations are still on ConfigMgr 2007 these days?

On Microsoft TechNet there was a question about this several months ago. I did a post on Twitter today as well. The answer sounds promising: ConfigMgr 2016 does support migrating from ConfigMgr 2007 R2 SP2 and R3 SP2, which is really great news! So no need to migrate to ConfigMgr 2012 first before going to 2016. Thanks to Peter Daalmans (@pdaalmans) on this one.

ConfigMgr 2016 will be generally available in Q4 CY2015 (which is really soon!). Technical Preview 4 is released last week, which is the last technical preview before the general availability (GA) of the current branch of ConfigMgr.

ConfigMgr 2012 R2 OSD slow at Driver package and ConfigMgr client stage

Last month I did a ConfigMgr upgrade from SP1 to R2, with Cumulative Update 4 afterwards. At first sight everything seems to be okay. After a few weeks however, customer was mentioning OSD was very slow at Driver package and ConfigMgr client stage installation. Default deployment before the R2 upgrade was around 45 minutes, but after R2 upgrade around 135 minutes! Lucky me I found the following post on Microsoft TechNet HERE and HERE.

It mentions:
It appears that MS support was able to find a solution for my environment.
Immediately after enabling the "allow clients to connect anonymously" setting on each distribution point the time it took for the MDT Toolkit package to download went from 30 minutes to around 20 seconds.
The support tech was unable to explain why this setting was required following the R2 upgrade in our environment. He verified that in his lab environment he did NOT have this setting configured on the DP and he saw no issue downloading the MDT toolkit package.
As much as I would like to have a root cause for this issue I'm just happy that my OSD process isnt taking 3 hours now!

At customer mentioned this was the solution also. Immediately after enabling the "Allow clients to connect anonymously" setting on each distribution point configured, deployment was done in 45 minutes again. Strange enough I did a lot of R2 installations, and a lot of SP1 to R2 upgrades also, but never had this issue before. Still happy with this easy to implement solution. Thanks again!