Microsoft Endpoint Manager: In-Place Upgrade or Side by Side

D Walsham • 7 October 2021

Part 1 - Analysing Scenarios for best method

Introduction

Here we are with another series. In this one we will be going through an interesting one which I think has also been covered many times in terms of step by step guides and some breakdowns of this particular subject being whether to upgrade your SCCM environment directly or to perform a side by side migration.


There will be many parts to this which we will look to carry end to end on not necessarily a how to do step by step guide perspective but more on a high level design approach.

General Consensus on Way to Go

It's always been said (well mostly) that the best option is to always perform a side by side migration which would be to build a new infrastructure and recover your SCCM environment to the new one as it provides the most security by maintaining your original environment whilst you can not only prepare and environment on the side but perhaps have a window of opportunity to add in some necessary tweaks and updates to it as well.


In perfect world scenarios I think this would reign true many times. However realistically this isn't always the case. First we should outline what are the scenarios that would prompt someone with making this decision. Lets have a look at a bullet point breakdown of some of them below;


  • Operating System: Requirement of high level OS i.e. Windows Server 2016/2019/2022
  • Current Branch Version: Wanting to perform a safer upgrade or may not even be on a current branch version
  • SQL Environment: May not be using SQL AlwaysOn or a sufficient SQL backup strategy for your environment
  • High Availability Plans: Requirements to avoid single point of failure
  • Hierarchy Downsizing: Wanting to retire certain sites or break away from the CAS structure
  • Environment Consolidation: Wanting to merge multiple SCCM/legacy environments/third party environments into one.


There are many more scenarios of course which carry weight to the decision making but these are perhaps the most common and most relatable to a lot of architects and system centre specialists.


With these scenarios being monsters its understandable why you would opt for a side by side option. The worst thing you would want to do is to be responsible for the only environment or the most business critical service to be interrupted.


Disaster recovery can also play a factor in this. Due to the fact there may not even be one or one which is not tested? You wouldn't want to wait for an actual disaster scenario to occur to know if it actually works or not :) This provides you with the opportunity to take action once you are in a position to start working on the new environment.

Why Consider In-Place Upgrade Scenarios

It can be a case of perhaps not having the luxury of resources to entertain a new environment to migrate to, but also can be down to how embedded those business critical resources are. We know that all environments are not the same though there maybe some similarities.


I have seen it where things such as security reasons can play a factor. Where depending on how the environment was built there could be some due diligence that may have not been carried out were certain security levels are unknown on deeper levels such as service accounts, ports, storage and many others. You can even come across environments which also may or may not have an HLD or LLD with them, hence where if you did go to a side by side migration then potentially you are looking at an entire redesign of the SCCM environment. Now that's not a bad thing at all, but a lot of environments can have caveats of business and time critical matters which make the likeliness of those options not come to fruition.


Now using the exact same scenarios in which we listed above, we will provide a small line or so to state as to what the reasons could be to support this option going forward;


  • Operating System: Embedded security hardening which may not be able to be replicated onto another server therefore an in-place OS upgrade would preserve this environment
  • Current Branch Version: Environment is already in a position which satisfies the organisation with sufficient backup and disaster recovery scenarios.
  • SQL Environment: Performing an in-place SQL upgrade due to same reasonings or able to just migrate the SQL servers as opposed to the whole SCCM environment
  • High Availability Plans: Focusing on just the migrations of storage i.e. storage for content library to support passive site server capabilities.
  • Hierarchy Downsizing: Detachment from CAS on current environment or retirement of primary/secondary sites.
  • Environment Consolidation: Adding to the same standalone site or if bigger device management can merge to new sites.


It can indeed save time to perform all of this on the same environment. But one thing that does have to be factored in is of course the high level of risk in which it carries. See performing in-place upgrades isn't necessarily straight forward. There are ALOT of processes which have to go into each part of the staging and if one of those goes wrong you could potentially damage your environment as well as the particular server in which you are looking to upgrade.


These are things to definitely take into account when approaching this.

What will we gain from this series

The aim is to cover each scenario in full detail and not to provide a bias to one side over the other. Now if we have learned anything over various best practices and preferential ideas is that the perfect world scenarios won't always cover a real world scenario so therefore we have to accommodate both outlooks. It's not about making or forcing someone to adhere to a specific narrative of this is the only way, but to understand what the risks and dependencies which are covered in each one.


We want to allow someone who is putting forth the design idea with enough evidence to backup the reasonings behind the decision and if that particular scenario is fitting. Comes down to the old saying of make the solution fit the business and not the business fit the solution.

Coming up on the next part

The second part we will be looking at the first bullet-point which we had mentioned in both scenarios being the Operating System. This is of course the foundation of anything moving forward before we begin to piece together the other parts as depending on which versions we might be on the OS is going to determine what we can and can't do in the long run. So the second part will analyse these steps and again accommodating both options.

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side Part 4 - SQL Server Requirement Analysis

by D Walsham • 13 December 2021
Looking through the current SQL Server topology and how it affects our decision

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side Part 3 - Current Branch Upgrade Approaches

by D Walsham • 19 November 2021
Impact of Current Branch Upgrades

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side - Part 2 - Operating System Considerations

by D Walsham • 29 October 2021
Introduction

Endpoint Manager: Device Estate Cleanup

by D Walsham • 6 October 2021
Introduction

Modern Workplace Management: Creating Applications Common Practices - LOB vs Win32 Package

by D Walsham • 3 September 2021
Introduction

Modern Workplace Management: Build Endpoints Without SCCM Part 6

by D Walsham • 12 August 2021
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency. Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios. In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy. But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as; Co-Management Between Intune and SCCM Hybrid AD with Azure AD and On-Premise AD syncing together These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune. With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.

Modern Workplace Management: Build Endpoints without SCCM Part 5

by D Walsham • 29 July 2021
In continuation from the previous part where we had discussed how we create the "on site" piece of the solution, this was the part which would allow us to get our endpoints into a state in which they would essentially be ready to go through the Autopilot process. Which leaves our next piece of the puzzle, to begin the configuration of the actual backend side that resides within our Endpoint Management console. And you will see how everything ties up together to satisfy the full end to end process of getting an unknown (or known) device to proceed thorough the whole workflow to be finally managed by Intune without the aid of SCCM taking part in any of the prerequisites or preparation at hand.

Modern Workplace Management: Build Endpoints without SCCM Part 4

by D Walsham • 15 July 2021
In this part we are now going to look into the technical step by step points on how we put everything together. In the previous part we spoke about the structure of how we would asses whether a machine was actually ready to be built with Autopilot or not with a build checklist process which would step through all areas which would cover an endpoints eligibility. Now with everything planned out we finally want to step into making things reality by putting everything together.

Endpoint Manager: Find machines not in Autopilot

by D Walsham • 2 July 2021
When it comes to managing your endpoints in endpoint manager, one of the things you may be looking to do is to get all of your Intune registered machines to also be enrolled as Autopilot devices. Now we can of course just have the deployment profile deployed to all machines and then hit the "Convert targeted machines to autopilot" but this might not necessarily be feasible for every client. We may want to perform some due diligence first so we can at least understand what devices in Intune are not in Autopilot.

Modern Workplace Management - Build Endpoints without SCCM Part 3

by D Walsham • 24 June 2021
So just to recap on the previous part of this series we covered a base scenario of where we would utilise other products as a dependency to provision or even pre-provision endpoints before getting them to a state where they can be auto-enrolled and then into Autopilot - in this case this would be around SCCM. We also detailed in a diagram form of where we ideally want to be, and that's to not have any dependency when it comes to the provisioning of the endpoints where its also soley performed within Intune. This part we will be going into the nitty gritty of how this works.
Show More