With the release of Windows 10 came a new deployment option that Microsoft calls an “In-Place Upgrade.” But wasn’t that always a method, like when we went from Windows XP to Windows 7?

Kinda sorta, but not really. Traditionally, we often used MDT-integrated ConfigMgr task sequences to perform an operating system Refresh, which would put a new image on your workstation. The Refresh sequence was often called an In-Place upgrade, or Wipe ‘n Load, and therein lies the confusion. To set the bar, and to know when and how to use each, let’s dive into the various deployment options available to us when we use ConfigMgr OSD:

Bare Metal

This is traditional imaging at its finest, and the method we use when we’re building new computers. It’s launched from a boot image, delivered via physical media, such as USB key or DVD, or via the network using the Preboot eXecution Environment (PXE), (re)partitions the hard drive, lays down an image and installs applications as defined by the task sequence.

In the MDT-integrated Task Sequence, steps to perform Bare Metal actions are performed early in the task sequence by determining if the machine was initially booted from media delivered over USB/DVD/PXE.

Bare Metal deployments are often called Imaging, Reimaging, Build, Rebuild, and probably a few others I’m forgetting

Refresh

A refresh deployment occurs when a new image is being installed on an existing workstation. This can include installing the same OS version or an upgraded one, such as a Windows 7 to Windows 7 deployment, or a Windows 7 to Windows 10 deployment. In a refresh deployment, the user’s settings and data are typically migrated to the new operating system.

In the MDT-integrated sequence, Refresh steps are executed if the task sequence was initiated from within Windows, as opposed to booting it from USB/PXE.

Refresh deployments are often called in-place upgrade, soft rebuild, or reimage with data migration.

Replace

A replace scenario is used when a user is getting a new workstation and we want to migrate their settings and data effortlessly. A replace is performed in three steps. For ease of explanation, let’s call the user’s old computer ComputerA, and the new one ComputerB:

  1. ComputerB is manually imported as a device in ConfigMgr. During import, ComputerA is specified as a Source Computer. This is performed in the Devices node of the Assets & Compliance workspace. A ribbon option is listed to Import Device.
  2. A User State Backup Task Sequence is performed on ComputerA. This creates a .mig file on the State Migration Point
  3. The MDT-Integrated task sequence is executed on ComputerA. Due to the Device Association performed on import, when the task sequence executes the Request State Store (or Provision PBA Data Store for 1E customers), it will look for ComputerB.mig to restore the data from

Your Replace scenario is most often called a side-by-side migration

Windows 10 In-Place Upgrade

All the previous deployment scenarios use our traditional imaging practices, where we first build a reference image and customize the task sequence with all the required applications. The Windows 10 In-Place Upgrade, though it uses the same task sequence engine, follows a completely separate process from that of traditional imaging. Instead, this process executes setup.exe from the Windows 10 Setup media, and performs an upgrade of the existing operating system.

Now, this sounds hauntingly familiar to the process many people will do at home to upgrade their home PC to a new version of Windows. We’ve been told for years that it’s a bad idea to do that in the enterprise, and I can’t agree with that statement enough. However, with Windows 10, Microsoft has invested a lot of time and effort into improving that process, and have certified the process for enterprise use. For what appears to be a smooth process to actually work, there are quite a few considerations:

  1. If you want to go from x86 to x64, this won’t work
  2. If you’re using 3rd party disk encryption, this may not work. You’ll have to check with the vendor to be sure
  3. If you’re moving from BIOS to UEFI, you cannot use the Windows 10 In-Place Upgrade. This means, basically, if you’re not coming from Windows 8/8.1 and already use UEFI, don’t bother doing an in-place, as you REALLY want to move to UEFI…
    1. Update…As of Windows 10 1703, Microsoft provides a tool to switch your machine from MBR to GPT, or Master Boot Record to Guid Partitioning Table, and ultimately allowing you to successfully enable UEFI.  It has some limitations, such as a max of 3 partitions, but is supported by Microsoft for enterprise use.  It’s not as versatile as 1E’s BIOS2UEFI solution, but definitely worth it if B2U is the only reason keeping you from an in-place upgrade.
  4. If you’re upgrading, replacing, removing a bunch of applications, it’s better to do a Refresh.
  5. Garbage in, garbage out. You’re upgrading your existing install of Windows, so if it’s buggy now, chances are it’s gonna be worse after you upgrade it to Windows 10
  6. Although the Win32 subsystem hasn’t changed between Windows 7 and Windows 10, there are still some application compatibility issues out there that can cause issues. If you’re not getting good analytical data about your deployed applications, you will likely get a higher number of failures with this sequence, as a Refresh does not migrate applications where this sequence will.

To segue from applications, I want to take a moment to point out Desktop Analytics. It’s a free solution provided by Microsoft through Azure. Desktop Analytics uses Windows Telemetry data from the global upgrade experience to analyze your environment and assess for potential upgrade concerns, allowing you to view the data in ConfigMgr to allow it to built your deployments. For more information about Upgrade Analytics and OMS, please visit https://docs.microsoft.com/en-us/configmgr/desktop-analytics/overview.

Hope this helps!

É