Deploy Windows 10 Enterprise using In-Place Upgrade
Many of you have probably thought about deploying Windows 10 in your organization and are already looking into the different options that Microsoft with their new operating system have brought to the table. The traditional ways of deploying a new operating system included methods like Wipe and Load, Refresh and Replace. Now with Windows 10, not for the first time though, you have the option to perform an In-Place upgrade. What’s different this time around is that it actually works, and it works really well.
For those of you out there looking to deploy Windows 10 in your organization, and are interested the In-Place Upgrade scenario, this is the post for you. I will cover the requirements and limitations for the scenario including a basic overview of how the In-Place Upgrade feature actually works under the hood. Additionally I’ll go through the process of using In-Place Upgrade with ConfigMgr vNext, and upgrade the post when the new version of ConfigMgr has been released (if there are any changes of course).
With previously released version of Windows, the In-Place Upgrade scenario was never considered a reliable option to deploy the latest version. But in Windows 10, Microsoft has put in enormous efforts to make the scenario the first choice for organizations when deploying the new version of Windows. This time around, it’s not only steady and reliable, it also features an automatic roll-back feature if any issues would occur during the deployment process, without the need of any IT-staff involvement. This scenario could also be considered faster than the traditional deployment scenarios, since applications and drivers do not need to be re-installed as part of the process. Although, there are some limitations as to how you can leverage the In-Place Upgrade scenario, which I will mention in this post.
When should you consider using the In-Place Upgrade scenario? The following scenarios describe that a bit more in detail:
- When you want to keep all (or at least most) existing applications
- When you do not plan to significantly change the device configuration (for example, BIOS to UEFI) or operating system configuration (for example, x86 to x64, language changes, Administrators to non-Administrators, Active Directory domain consolidations)
- To migrate from Windows 10 to a later Windows 10 release
The latter of those statements becomes really important, and improves the future upgrades to the latest versions of Windows when Microsoft releases them. I assume that you’ve heard about the Windows as a Service terminology? If not, the picture below illustrates how the new versions of Windows will be made available through branches during different stages:
Whenever a new version is released, organizations can leverage the In-Place Upgrade scenario to test and deploy the latest version in their environment. In my opinion, this is killing blow for the traditional methods of introducing a new version of Windows in the organization, and improves the process enormously including keeping the deployment time at a minimal.
What are the upgrade paths available?
|Current Operating System||Upgraded version|
|Windows 7||Windows 10|
|Windows 8||Windows 10|
|Windows 8.1||Windows 10|
|Windows 10||Windows 10|
Requirements for In-Place Upgrade
One of the questions I believe that many administrators are asking themselves is, what do I need in order to leverage In-Place Upgrade in a deployment scenario for deploying Windows 10? Below is a table of things to consider and that you need to be aware of. It’s important that you are familiar with the scenario and what the requirements are.
|Default image||You’re not able to use a custom image of Windows 10 for the In-Place Upgrade scenario. You’d have to use the install.wim image provided with the latest Windows 10 media that Microsoft has released.|
|Internet Explorer 11||While this may not be a requirement prior upgrading to Windows 10, it’s recommended that you deploy Internet Explorer 11 in your environment and make sure that your applications works since that’s the only supported version of Internet Explorer in Windows 10. It’s also good to know that earlier versions than Internet Explorer 11 will become unsupported in January of 2016.|
|Deployment solution||This is a no brainer, since you’ll of course need some kind of deployment solution to deliver Windows 10 to your devices. Supported tools are:
Limitations with In-Place Upgrade
Until now, everything seems great and you probably want to get started with deploying Windows 10 using the In-Place Upgrade scenario. But before you do that, there’s a few scenarios you need to be aware of when you cannot leverage In-Place Upgrade:
|Operating system architecture switch||The upgrade process cannot change from a 32-bit operating system to a 64-bit due to the possible complications with drivers and applications it may bring.|
|BIOS to UEFI switch||When changing from BIOS to UEFI based capabilities, a new disk layout is required and therefor not supported by the upgrade process. It also includes any type of disk layout change, even without changing from BIOS to UEFI.|
|Operating system language change||You cannot leverage the upgrade process when attempting to go from one operating system base language to another.|
|Changing SKU||Changing the operating system version is not supported. You can only go from the same version or higher, e.g. when upgrading from Professional to Enterprise, or Enterprise to Enterprise.|
|Third-party disk encryption||While BitLocker encrypted devices can easily be upgraded, more work is necessary for third-party disk encryption tools. Some vendors provide information on how to implement their software in the upgrade process.|
|Dual-boot or multi-boot systems||The upgrade process is designed for devices running a single operating system.|
There are some other limitations when not to use the In-Place upgrade scenario, like for instance with Windows To Go devices and when using Boot from VHD, but in my opinion they’re barely used in a organization.
How In-Place Upgrade work
In my opinion, you’d have to familiarize yourself with how the In-Place Upgrade process actually works. Perhaps not on a 500 level, but at least have an understanding of the different phases during the process. When you’re upgrading from your current operating system, Microsoft refers to this as the Down-Level operating system. In terms of the operating system being installed, they refer to that as the new operating system.
These are the following items that will be migrated to the new operating system during the upgrade process:
- User accounts and settings
Basically, you can look at it this way, you’ll end up with exactly what you already have on the device (except for unsupported items that are not eligible for Windows 10).
The upgrade process consists of four different phases. During my visit to Ignite in Chicago in May earlier this year, I attended the Windows 10 In-Place Upgrade deep dive session. From that session, the following was presented in terms of the four phases and what’s going on behind the scenes:
Phase 1 – Down-level phase
When setup.exe is executed on the down-level operating system, the following tasks are performed (prerequisites and compatibility checks):
- System checks
- Inventory Applications
- Inventory Drivers
- Assess compatibility
- Prepare WinRE
Phase 2 – Boot to WinRE
WinRE (Windows Recovery Environment) is executed, and has less functionality than WinPE. Possible to recover to the down-level operating system. Tasks that are being performed are:
- Both new and down-level operating systems are offline
- Backup down-level operating system to Windows.old
- Lay down new operating system
- Prepare new operating system
- Inject Drivers
- Some migration (unfortunately the session did not provide any more details on this part)
Phase 3 – First boot to new operating system
New operating system is launched for the first time, but not shown to the end user. This is the configuration phase of the new operating system and it’s possible to recover to the down-level operating system. Tasks that are being performed are:
- Binding new operating system with the down-level operating system
- New operating system gets an identity
- Specialize to the machine
- Install drivers
- Migrate applications
- More migration (unfortunately this part was also not documented further during the session)
Phase 4 – Second boot to the new operating system
During this phase the new operating system is being booted to for the second time. User is taken directly to the Out-of-box-Experience once the finalization is complete. Tasks that are being performed are:
- Finalizing the whole In-place Upgrade process
- Welcome the user back with OOBE
As for the whole upgrade process, it’s much more complicated than described above, but I wanted to highlight the four phases and give you an idea of what’s going on. Now that we have a better understanding of In-Place Upgrade with Windows 10, lets go ahead and prepare for an In-Place Upgrade scenario with ConfigMgr vNext.
Deploying Windows 10 using In-Place Upgrade
As of writing this post, it’s possible to upgrade from any of the supported upgrade paths with the most current version of ConfigMgr 2012 R2 SP1. Although, this version requires a custom made task sequence (one that Microsoft has already provided for us, available here). Instead I’ll go ahead and demonstrate how the real (hopefully) task sequence will look like by using ConfigMgr vNext TP3 and a task sequence template called Upgrade an operating system from upgrade package.
NOTE! This is still in preview and might change. If the process is updated in the final release, I’ll update this post accordingly.
The scenario I’m going to demonstrate in this post involves a Windows 7 SP1 Enterprise domain joined device that will be upgraded to Windows 10 Enterprise. Before I go ahead and start creating anything, I’d need to download the source media of Windows 10 from MVLSC and extract the content of the ISO.
Add an Operating System Upgrade Package
1. Open the ConfigMgr console and go to Software Library. Expand Operating Systems, right click on Operating System Upgrade Packages and select AddOperating System Upgrade Package.
2. Specify the path to where you’ve downloaded the source content from the latest Windows 10 build available on MVLSC and click Next.
3. Specify a name of the upgrade package and a version (I suggest that you specify the build version in the version field). Click Next.
4. On the Summary page, click Next.
5. On the Completion page, click Close.
6. Distribute the Operating System Upgrade Package to your Distribution Points.
Create an Upgrade task sequence
1. Right click on Task Sequences and select Create Task Sequence.
2. Select Upgrade an operating system from upgrade package and click Next.
3. Enter a task sequence name and a description and click Next.
4. Next to the Upgrade package field, click Browse and select the new created upgrade package and click OK.
5. Back on the Upgrade the Windows Operating System page, click Next.
6. Select to install All software updates and click Next.
7. Decide whether or not to have the task sequence installing any additional applications, click Next.
8. On the Summary page, click Next.
9. On the Completion page, click Close.
We now have the upgrade package containing the latest build of Windows 10 together with an upgrade task sequence ready for deployment to our Windows 7 device. The next step would be to deploy the task sequence to a collection containing the Windows 7 device. I’ll assume that you’re familiar with deploying a task sequence, so I will not cover those steps in this post. For the purpose of demonstration and for you to follow along, I’ll deploy this task sequence with a purpose of Available to my Windows 7 device.
You should of course decide whether to make this available to your devices or if you should at some point require it. In terms of the Windows as a Service, and keeping up with the latest version in your organization so that your devices are supported, perhaps a good idea would be to make it available for your organization a certain time before the build runs out of support. And at the end of the support time frame, make it required. This is something that Microsoft is currently working on with ConfigMgr vNext and what they’re calling Windows 10 servicing plans.
NOTE! In the Technical Preview 3 of ConfigMgr vNext, I had to re-distribute the upgrade package so that it got a version 2 for it to work.
Execute In-Place Upgrade
1. On the Windows 7 device, opening up Software Center I’ll now see the new upgrade task sequence available under Applications and click Install.
2. The In-Place Upgrade process will now start where the first phase will run, checking for readiness and compatibility.
3. The device is booted into WinRE.
4. After a reboot, Windows 10 is being specialized in addition to other tasks as mentioned above.
5. A second reboot occurs and Windows 10 is being configured and launched for the first time.
6. After the third reboot Windows 10 is upgraded from Windows 7 and we’re back in the task sequence engine.
7. Software Updates are installed.
8. We’re finally presented with the logon screen after a final reboot.
After we’ve logged in, Windows 10 will setup your apps and perform a few other tasks where it eventually will present you with the desktop. The whole upgrade process is now complete and your device have successfully been upgraded from Windows 7 to Windows 10 by using the In-Place Upgrade scenario.
Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences and user groups.