How To Upgrade/Change the Operating System which hosts Microsoft Configuration Manager

[Guest ms-foxworks]

Hello!

 

 

 

My name is Herbert Fuchs and together with other members of the Customer Success Unit and the Customer Service & Support Organization we want to help our Customers with This Blog-Series. We gathered information and put our field and support experience into this. Special thanks to our contributors, reviewers and content-writers, Wilhelm Kocher, Anthony Fontanez, Emilian Bucur, Pavel Yurenev, Anderson Cassimiro and Madalina Zamfir.

 

 

 

So, what's the story - you implemented a well running ConfigMgr-Environment. New Solutions to deploy, changes in the Organizations, new Features implemented and -

 

well time fly’s by and you are in a situation where your Operating System which Host Configuration Manager is out of date - or close to the end of the Mainstream Support.

 

Search Product and Services Lifecycle Information - Microsoft Lifecycle | Microsoft Learn

 

Maybe you cannot change your Management Solution entirely to Microsoft Intune and you need a Transition time through Co-Management and Tenant-Attach.

 

 

 

When you ever come into this situation you have the following Options:

 

 

 

• Inplace-Upgrade Operating System
  
• Site by Site Migration
  
• Disaster Recovery
  
• High Availability
  

 

 

 

All of these have their advantages and disadvantages – beside the technical implementation there is also Operation Excellence involved. Let's have a brief look into each item:

 

 

 

Inplace-Upgrade Operating System

 

 

 

 

This way is supported – but at the same time it is also not recommended. Frankly speaking - one Problem here is you can move crap from A to B – but the crap still is crap. So, configurations and settings maybe applied and kept which no one knows.

 

However, the downtime in this case is usually the lowest – from our experiences in other productions – you need to reinstall BITS, reconfigure WSUS and check the Permissions in the WMI for the SMSProvider (in the worst case we need to reinstall the SMSProvider) –

 

Scheduled Task must be backed up. The Rest of the System will stay the same. A Fallback can be a Snapshot or a Disaster Recovery. Please keep in mind that a Snapshot is not a supported way of backup/recovery of Microsoft Configuration Manager.

 

The Inplace-Upgrade is also supported for VM’s which are hosted on Azure.

 

 

 

Site by Site Migration

 

 

 

 

This one is usually the safest way to migrate. You setup a new System, configure and install MECM, Test/Validate it – and then you start/create Migration-Jobs from the old Site. Here you have the Opportunity to clean up stuff – so migrate only things what you need – this sounds most time good – but when you look at 10.000 Objects to migrate - well this is Time consuming – or you simple migrate as much as possible – However keep in mind you cannot Migrate Site-Data for instance HW/SW/Metering-Inventory Data.

 

The new Site will have a new Site-Code – so you need to Reassign every Client to the new Site – based on Boundary-Groups, Script or GPO. So, this can also take time if you have many Clients to manage.

 

You cannot use the existing CMG-Instances – because these are already configured for the old Site – so this a block for System which are now in HomeOffice, if you do not take care for such Systems.

 

 

 

Disaster-Recovery

 

 

 

 

The Downtime here is usually one day in Total – so setup a new Box – shutdown the old VM – install configure Features on the new Box – start the Recovery and Post-tasks. Here we have the limitation that the NetBIOS-Name of the new VM must be identical to the old – also, the Installation-Path should be the same – otherwise the Recovery will Fail.

 

This Process is quite robust as it should be for a Backup/Restore-Workflow. Here the most issues we saw with the Content-Library which is not included with the BuiltIn-Backup.

 

So, it might be necessary to Update/ReDistribute Packages/Applications/Image – If you have a Content-Library of 2 TB and more this takes time. For HTTP/EHTTP it is necessary to recreate the Certificates for the DP’s. Re-Generate Secret-Key for the CMG if in use. Different WSUS/SUP Issues.

 

 

 

High Availability

 

 

 

 

This Feature would be also an Option, but it has a couple of Prerequisites – the Content-Library must be moved to an UNC-Path, the SQL-Database must point to another Box or dedicate System. Then you can setup a new System and install it as a Passive-SiteServer – because we do not use the Failover-Cluster-Feature – it is possible to have different OS-Version between the Nodes – the new Node must also act as a SMSProvider. When this configuration is done – you set the Passive-Node to Active – when the failover was successful – you can demote the old SiteServer. A Fallback would be just a switch to the original Node.

 

The new VM and/or the SQL could be on Azure if you wish (IAAS). For this Scenario we have a Tool in the cd.latest folder – ExtendMigrateToAzure, which can assist you with that.

 

 

 

This is now a brief overview – as you can see a couple options and possibilities. However, a couple of other topics will come to mind:

 

 

 

Configuration Manager Design

 

 

 

Microsoft Configuration Manager is an Enterprise Management System – so depending on your size and complexity – you maybe have a Standalone Primary, dedicated SQL-Cluster or maybe a large Hierarchy with 1000 System Servers only for Configuration Manager.

 

All the above Scenarios are independent on this – but you might choose different approaches – For instance if you have a dedicated SQL-Cluster, you probably will install a new Cluster, and use native SQL Backup Restore and point the Configuration Manager to the new SQL Cluster. The Site Server itself you go for an Inplace Upgrade.

 

 

 

Current Infrastructure

 

 

 

Is the platform running virtual or physical – depending on that you need to talk with different department before you start your technical implementation. For example – Virtual – you need to talk to your Virtualization-Team, in a Disaster Scenario they will prepare a new VM – as mentioned the NetBIOS-Name must be the same – so there will be some cleanup of the new and old Host on the HyperVisior. Physical – in case of an Inplace Upgrade does the System provide Drivers for the new OS, if not you will probably not go this route. Disaster-Recovery – we need to buy new hardware – if you are working in the Public-Sector you might need to do a hardware-evaluation or do we want a Lift and Shift to Azure.

 

 

 

Fallback Plan

 

 

 

What will you do if the Inplace-Upgrade ends in Blue-Screens – so do we have a Disaster-Recovery-Plan which is tested, and each Configuration Manager Admin is aware about?

 

 

 

Service-Map

 

 

 

Do we have Tools/Products which depend on the Configuration Manager. Did you create custom Solutions (Scripts, WebService) which are using the Configuration Manager API. Are Connections-String hardcoded or simple changeable through a Parameter set.

 

 

 

Current Assessment

 

 

 

What Roles and Features are in use – are those essential for Configuration Manager – or a Third-Party Product – maybe you installed MySQL-ODBC-Driver to use this in a Report, to combine data from Configuration Manager and Secunia.

 

 

 

 

 

You should discuss this internally with your Team-Members and other departments which way you would prefer. Once the decision is made – we encourage you to look at the Detail-Steps for each in our follow up Blogs to this Topic. Stay tuned.

 

 

 

Blog-Links coming soon!

 

 

 

 

 

We hope this reference is helping you in your decision!

 

 

 

 

 

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

 

Continue reading...