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

D Walsham • 19 November 2021

Impact of Current Branch Upgrades

Introduction

With this part we will be continuing looking at the comparisons of our approach when it comes down to the current branch version upgrades. There can be still very surprising events and challenges which can still indeed arise from this though has become more robust and more simplified over time. But it can have a slight unpredictability when it comes to different environments hence we will look and outline the areas of interest which will help you decide as to which route you may wish to take.

What could possibly go wrong??

Famous words amongst quite a few!


Performing a current branch update is fairly simple, but we have to take into account the overall architecture that we have for SCCM because whilst the upgrade itself is fairly simple, the changes itself won't be able to be rolled back so potentially there could be some very big leaps or changes which will have an instantaneous knock on affect to the rest of your environment, which is definitely something which you should bear in mind when proceeding to go ahead and apply these upgrades.

Isolate device compatibility

This is probably one of the most sensitive parts of any upgrade, the overall device estate.


Now in real world scenarios you are always (well most) will contain a good portion of devices which may fit the following categories;


  • Windows 10 (Lower Recommended Build Versions)
  • Windows 8 & Lower
  • Windows Server 2008 R2 & Lower


These are just some examples of the overall mixture of platforms one would or could have in their estate. Now once you start to climb up in the versions of SCCM, especially where the SCCM client version is concerned you may start to see more and more additional resistance when it comes to advertisement of deployments, policy changes and software update patching and so forth. Eventually you may get to a part where advertisement hits and misses get to a point where they start to no longer function correctly. So much to the point that you would need to reinstall the client, sometimes even locally on the machine in order to force a refresh of these.


This is an issue regardless of slow or quick you might be to upgrade your infrastructure. And by the time you potentially reach up to SCCM 2006, this is where the compatibility is officially cut. As server OS clients such as Windows Server 2008 R2 and lower are no longer supported. Resistance on client OSes such as Windows 10 1903 could also become a problem further down the line which we will cover later on.


More can be seen on the supported OS clients and server systems here.


Workarounds can be done to maybe keep somewhat of better communications such as having those unsupported clients at lower SCCM versions where they may have been once more responsive, but overall it can me more of a stalling or prolonging the overall situation as much more administrative effort is then required to ensure that they are communicating with SCCM.

Frozen Stages of Upgrade

Not sure how common this particular situation is still but for a long while this had caused a lot of issues.


Basically whilst running through the upgrade where you get the window stating its progress of how the upgrade is going, either through the prerequisite check or the installing check once it approaches the steps to do with checking the SCCM database, there is a tendency to actually freeze and not move anywhere. Even the log files which monitor the progress of this also don't move which makes understanding why it does this to be very complicated.


Tools such as CMUpdateReset.exe tool does help to get out of this situation, but I have also seen many cases where this doesn't work and processes remain locked and will not break. Worse case scenarios have came into play where sites had simply had to be rebuilt because of this.


Why is this a particular reason to consider an in-place upgrade or side by side you might ask? Well it can come into play when some of the issues related to this can come from a clogged SCCM environment which is then reflected within the database where peak times can fight for processes and having a not so updated SQL infrastructure doesn't help this situation either. So its something to bear in mind as well to observe other peoples potential issues which was quite common at a certain time.

ADK Version Hike

Similar to the section of isolating devices, as depending on the type of infrastructure that you have a huge jump in ADK versions can possibly be problematic. For example, certain ADK versions will become obsolete when it comes to climbing versions of the current branch build numbers such as versions for Windows 10 ADK 1903 being no longer in use by the time it starts to reach to SCCM 2103 and onwards.


A further breakdown can be seen here

Re-Evaluation of Hardware/Software Requirements

Perhaps this should be at the top, but then again with all the other categories collated together perhaps it makes sense to keep this here. Now when it comes to evaluation of hardware/software requirements this can be down from the OS versions which your mandatory site system server roles maybe supporting as well as other topologies such as utilising a CAS server, centralised storage etc..


Once starting to go up further in versions the more you will be faced with a decision to upgrade the OS levels to the recommended version for supporting the latest upgrade of SCCM which depending on your circumstances could potentially bring everything to a stand still.


And its not just those areas you also have to take into consideration the SQL Server versions as well. Anything 2012 and below will require an upgrade for sure and that can already have its complications of its own.

More information on supported software can be found here.

Take Advantage of the opportunity whilst you still can

A collation of various areas to consider, its best to take advantage of the situation before these types of decisions are approached before hand.


Further down the line there will be more updates and upgrades, and bottom line you want to ensure that you not only stay compliant but also ahead of the game where necessary.


A window of opportunity is really right now. Ultimately analysing and reviewing your current infrastructure on a HLD and LLD perspective will allow you to understand the required changes in order to move forward. Though this has been done ideally you don't want to just have to apply these changes right as you are faced with some of the bits mentioned above, it's best overall to have this settled before hand whether you select to perform this as an in-place upgrade or a side by side migration.


It's not about just being fully updated each time a release is thrown to you, but more about being resilient to changes where your estate doesn't get hindered by non-support, incompatibility and many other scenarios. All about a balance of being able to support scalability and being able to accommodate the new features and OS support levels as well as having wiggle room to support an estate that might not be quite the recommended level but at least a fair distance from being obsolete too :)

Next on part 4

The next part will have more of a pure focus on the SQL environment side which will be more technical as opposed to this particular part should also be comprehensive image wise too :)

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 2 - Operating System Considerations

by D Walsham • 29 October 2021
Introduction

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

by D Walsham • 7 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