Physical Machine Image Snapshot Solution

Dujon Walsham • 6 October 2018

Part 1 - The Concept

How I came up with it
I had been around various projects for desktop deployments and migrations, as well as machine rebuilds and recoveries etc.
Quite a common practice I used to see when a machines gold build either suffered major technical issues which would take either too long to resolve or troubleshoot would be rebuilt. Technologies normally used for this would be either SCCM task sequence image deployment or MDT Task Sequence image deployment.

Though it resolves the issue fully it can be a very time consuming task depending on the size of your gold/hybrid image and the complexity of your task sequence configured.

So I had analysed the amount of time it took to rebuild a machine (approx. 2 hours) and decided to do some testing and had developed a strategy which I had named a "Physical Machine Snapshot". The idea is that the machine can revert back to a previous state after a triggered reboot which would be stored on the physical disk.

How Does it Work

Essentially it sounds like the same as a system restore point however with what I had created you can manage the snapshot points from system centre (SCCM mainly) and another part to it is that if you have a new image version you can update the desktop with the newest version and maintain the same data.

I had worked on this and managed to get it working back in 2014 but as I moved around several projects it didn't get to see the light of day so I decided to revive it.

The idea was to have a gold image solution similar to how Citrix did through XenDesktop. And the way I configured the upgrading or applying the new image version is quite similar to the Azure swapping templates functionality.

I dived a lot into the real functionalities of deployment tools SCCM and MDT. With utilising ZTI and complex task sequence designs I saw that MDT applies images with imagex whilst SCCM uses DISM. They are pretty much the same but imagex has more complex switches which enables MDT to provide certain enhanced features for SCCM when integrated together.

MDT 2013/2014 had brought in some new task sequence options which allowed you to use VHD images on the machines you build, and SCCM also introduced a VHD task sequence option to deploy a task sequence directly to a VHD disk which can be used on a new VM and used this concept to build the overall solution.


Benefits of the Solution

So in terms of statistics I broke down it would take approximately 2-3 hours to build a machine or to even rebuild a machine depending on the complexity of the build, whilst the “Physical Machine Snapshot” solution I had cuts this time down to 75% less (Between 45 Minutes to 60 minutes or less.

Part 2 will show a more technical breakdown of how the overall solution works as well as illustrated design diagrams

by D Walsham 13 December 2021
Looking through the current SQL Server topology and how it affects our decision
by D Walsham 7 October 2021
Introduction
by D Walsham 6 October 2021
Introduction
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.
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.
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.
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.
Show More