Wednesday, February 3, 2016

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! :-)

2 comments:

  1. 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.

    ReplyDelete
    Replies
    1. Thanks Torsten, will do that next time. But still a nasty situation in a production environment.

      Delete