The real-world guide to Windows 10 migration

With Windows 10 already deployed on more than 400 million computers, it’s hard to argue with its success. But the fastest adoption rate of any Windows release has thus far played out predominantly on consumer devices. The enterprise tells a different story, with organizations still mostly on Windows 7. But the change is coming fast. Brad Anderson, corporate vice president at Microsoft, recently announced that 86 percent of enterprises will upgrade to Windows 10 within three to four years; of these, organizations 47 percent said they will upgrade in the next 12 months.

With the changes to Win10’s updates and rumors of the OS being the final major version of Windows, your upcoming rollout may be your last great Windows migration ever.

In this article targeted for organizations that want to migrate to Windows 10, I walk you through the planning processes, requirements, and deployment scenarios, providing guidance on how to keep your Windows fleet updated. For me, working as a ConfigMgr and OS Deployment consultant, the past two years of doing almost nothing but Windows 10 migrations have been a great ride, with a few big surprises. Read on to find out how Windows 10 has altered the Windows migration experience.

Windows 10 deployment challenges

Migrating to Windows 10 offers unique challenges. To tackle them, you'll need to keep a few details in mind before you start. First, you'll need a deployment and management platform not only to get the first Windows 10 bits out there, but also to keep your fleet updated. Windows 10 also introduces significant networking concerns that you'll need to address, not to mention new opportunities to overhaul your group policies.

Deployment and management platform requirements

Microsoft offers two platforms for deploying Windows 10: the free Microsoft Deployment Toolkit (MDT) and the not-free System Center Configuration Manager (ConfigMgr) Current Branch management platform. MDT and ConfigMgr are the only deployment solutions from Microsoft that support Windows 10. Windows Deployment Services (WDS) is not a deployment solution on its own; it’s the deployment infrastructure that MDT and ConfigMgr use in the background.

To deploy Windows 10 with MDT, you need to be on Version 8443, which supports both Windows 10 and Windows Server 2016 deployments. For ConfigMgr Current Branch, you need to be on version 1606 or higher for Windows 10 version 1607 (Anniversary Edition, RS1), or ConfigMgr version 1702 for Windows 10 version 1703 (Creators Update, RS2).

Because it’s only a deployment solution, MDT is not suitable for managing Windows 10 after deployment. ConfigMgr Current Branch, however, does management well, as does Microsoft Intune.

IDG

Infrastructure and network requirements

In addition to deployment and management, you will need infrastructure for activation and for software updates. For activation you will use either Multiple Activation Keys (MAK) or a Key Management Server (KMS), which can either be standalone, integrated with Active Directory (AD) so that all machines activate when they join your domain, or a combination of both. For software updates, organizations can currently perform updates via standalone WSUS, ConfigMgr, Windows Update for Business, or via Microsoft Intune.

As far as networking goes, the sheer size of Windows 10 updates that needs to be installed on each client is the biggest pain point. We are talking about 5GB to 15GB of updates for every single Windows 10 machine on your network, with sizes varying depending on how you deploy the updates, not what updates you deploy (you learn more about that in the Servicing Windows 10 section below).

To reduce the network impact that Windows 10 will have in your environment, Microsoft is doing two things: employing techniques to reduce the size of the updates, especially what clients must download, and investing in software-defined networking, like peer-to-peer (P2P) solutions. Windows 10 natively includes a delivery optimization service that allows clients to share contents with each other, and for clients managed with ConfigMgr, Microsoft has added Peer Caching in ConfigMgr v1610, which does basically the same thing—allowing clients to share content with other clients. This new P2P technology can (and should) be integrated with existing features such as BranchCache and BITS. A cool addition to ConfigMgr is its Client Data Sources dashboard, which breaks down content sources for each client group, letting you see what percentage of Win10 update data came from a Distribution Point, Cloud Distribution Point, BranchCache, or Peer Cache.

IDG

Assessment, deployment, and readiness tools

To prepare you for Win10 migration, Microsoft has released Windows Analytics, a free cloud service that is part of Microsoft Operations Management Suite (OMS). Within Windows Analytics, you will find Upgrade Readiness, formerly named Upgrade Analytics. Upgrade Readiness uses telemetry data from Windows 7, Windows 8.1, and Windows 10 version 1607 to help you prepare for application compatibility issues and the like. This is a direct replacement for the Application Compatibility Toolkit that used to be part of Windows Assessment and Deployment Toolkit (ADK), but has been removed since Windows ADK 10 version 1607.

To enable your clients to report data to the Upgrade Readiness solution, follow the “Get started with Upgrade Readiness” guide on TechNet.

OU structure and group policy strategy

Starting a Windows 10 deployment project gives you the golden opportunity to overhaul your existing group policies. Many organizations have been using group policies since Windows 2000 and have added more and more over time. For example, I often stumble across lockdown policies that were created when users were local admins in the Windows XP or Windows 7 timeframe. This is often no longer the case, and many of the older lockdown policies are simply not needed anymore.

In addition, there are plenty of Windows 7 policies that will downright break Windows 10 machines. For example, one customer I visited late last year had installed a bunch of Windows 10 computers into an Active Directory OU containing group policies for their Windows 7 machines. After the deployment, they realized that the Start Menu wouldn’t work, and after some research it turned out to be Windows 7 AppLocker policies breaking the Start Menu. There are also scenarios where Windows 7 security baselines can break Windows 10 machines.

Bottom line: I recommend you put your Windows 10 machines in a separate OU, at least during the pilot project, and link only the group polices that are absolutely necessary for features to work, such as certificates, and so on. Technically you can also limit what operating system a group policy applies to via WMI filters, but it’s easy to forget to add that filter when creating group policies. If you are using a separate OU structure it’s much easier to see.

Deployment scenarios

Microsoft’s Windows 10 deployment solutions (MDT and ConfigMgr) support four scenarios for Win10 deployments. The scenarios are explained in detail below, but here is the quick summary of each:

• In-place upgrade. A new deployment scenario, available only for Windows 10. In this scenario, you simply upgrade an existing Windows 7 or Windows 8/8.1 machine exactly as it is to Windows 10.
• New computer. A bare-metal deployment of a new machine.
• Computer refresh. A reinstall of the same machine (with user-state migration and an optional full WIM backup).
• Computer replace. A replacement of the old client with a new client (with user-state migration and an optional full WIM backup).

In-place upgrade

The in-place upgrade scenario in Windows 10 is a very nice deployment addition when it can be used. First, it upgrades the system as it is, with all applications, data, and settings. There is no option for selecting what should be included. It’s an all-or-nothing scenario. This means you need to be quite happy with the current platform because the new machine will be the same as before, except of course now running Windows 10.

In addition, while in-place upgrades are nice, there are quite a few scenarios when you need to use the old-school deployment scenarios (new computer, refresh computer, or replace computer). Windows 10 in-place upgrades have the following limitations:

• You cannot use a custom reference image with applications installed. You must use the default Microsoft image.
• You cannot change from BIOS to UEFI (not supported by Microsoft) or do other disk layout changes.

Note: This is valid for Windows 10 v1607, but for Windows 10 v1703 (Creators Update), Microsoft has added in a new utility, the MBR2GPT.exe utility, that allows you to convert disk partitions from MBR to GPT during an in-place upgrade.

• You cannot upgrade with (most) third-party disk-encryption software installed.

Note: From Windows 10 1607, Microsoft has added a new switch to the Windows 10 Setup engine, the /ReflectDrivers switch. This switch allows you to specify a folder for vendor drivers that works with an in-place upgrade.

• You cannot upgrade when (most) third-party antivirus software is installed.
• You cannot upgrade between architectures (for example, x86 to x64).
• You cannot change the base operating system language.
• You cannot change to a lower edition (or SKU).
• You cannot upgrade a “boot from VHD” system.
• You cannot upgrade Windows to Go USB sticks.

The deployment process for an in-place upgrade scenario is as follows:

1. The setup starts on a machine running the operating system that is to be upgraded.
2. The operating system image is upgraded via the setup.exe/Auto Upgrade option.
3. Other application installations follow (as part of the task sequence, if added).
4. The machine is ready to be used.

New computer

This scenario occurs when you have a blank machine you need to deploy or an existing machine you want to wipe and redeploy without caring about any existing data. The setup starts from a boot media, using PXE, CD/DVD, USB, or ISO images. You also can generate a full offline media, including all the files needed for a client deployment. The target can be a physical computer, a virtual machine, a virtual disk running on a physical computer (Boot from VHD), or a USB stick (Windows to Go).

The deployment process for the new machine scenario is as follows:

1. The setup is started from boot media (PXE, CD/DVD, USB, or ISO).
2. System validations are run.
3. The operating system image is installed.
4. Other application installations follow (as part of the task sequence).
5. The machine is ready to be used.

Computer refresh

Sometimes called "wipe and load," this was the new “upgrade” for Windows 7 and Windows 8.1 deployments. The process is initiated on the running client. User data and settings are then backed up and restored as part of the deployment process. The target can be the same as for the new computer scenario except for the USB stick.

The deployment process for the wipe-and-load scenario is as follows:

1. The setup starts on a machine running the operating system that is to be upgraded.
2. System validations are run.
3. User state is saved locally (normally).
4. The operating system image is installed.
5. Other application installations follow.
6. User state is restored.
7. The machine is ready to use.

Computer replace

A computer replace is like the refresh scenario. But because we are replacing the machine, we divide this scenario into two main tasks: backup of the old client and bare-metal deployment of the new client. As with the refresh scenario, user data and settings are backed up and restored.

The deployment process for the replace scenario is as follows:

1. The setup starts on a machine running the operating system that is to be upgraded.
2. System validations are run.
3. The user state is saved on the server through a backup job.
4. Then the new computer is deployed as a bare-metal deployment.
5. The previous backup is restored on the new computer.

Real-world note: Sometimes the computer replace scenario is used even if you would like to keep your old hardware. If the machine runs a third-party disk encryption system, it could be faster to treat the scenario as a replacement to avoid decrypting the hard drive before deployment or spending time getting refresh scenarios to work. This also applies when the disk partitioning layout is incorrect (BIOS vs UEFI).

MDT and ConfigMgr also supports a special OEM scenario that you can use if you want to prepare an image in-house, then send it to an OEM for cloning. That scenario is not described in detail here, but it should be mentioned as a possibility.

Servicing Windows 10

With Windows 10, Microsoft changed to a Windows-as-a-service model. This means that Microsoft provides not only security updates (quality updates) on a regular basis, but also new features (called feature updates) every once in a while. These new features releases are released two times per year for the “normal” Windows 10 editions, and less frequently for the Windows 10 Enterprise LTSB version.

The new service model also changes how these feature updates are released and tested compared with previous releases of Windows. Feature updates for Windows 10 (and Office 2016) are released in a ring-based approach.

When using a ring-based approach, as with Windows 10, you get the following timeline for how feature updates are tested and released: