Before we can select the best deployment method, we need to select a suitable branch, as one branch implies some timing restrictions due to shorter support timelines, which will be explained now.

Beginning with Windows 10 and its new Windows as a service concept, you can choose between two main flavors. All Windows 10 Home, S, Professional, Pro for Workstation, Enterprise, and Education SKUs support the Current Branch (CB) model. This branch was renamed with Windows 10 1709 to Semi-Annual Channel (Targeted). When Microsoft officially releases a new feature update for Windows 10, that update is marked as CB / Semi-Annual Channel (Targeted).

In this CB model, the system will be updated up to three times a year (don't worry, the Windows 10 product group stated that they normally plan only one to two releases per year). As soon as this CB is available, it will be rolled out to all Windows 10 installations, which will be getting their updates directly from Windows Update (WU) online. The roll out will be done in stacked waves.

If you want to postpone such a roll out, you need to defer feature updates, which is an option only available in Pro, Pro for Workstation, Enterprise, and Education. You can defer updates per GPO when using WU for 1-8 months, or directly inside your Windows Server Update Service (WSUS), System Center Configuration Manager (SCCM), or third-party deployment solution for a even longer time frame.

To distinguish between the different branches, a lot of people use the build numbers. But it is cumbersome to memorize all these builds: 10240, 10586, 14393, and so on. You should use this naming only when speaking of Windows Insider builds.

Also, the code names are not that clear and do not describe at what time a version was released (for example, Threshold 1/2, Redstone 1/2/3, and so on). With the Windows 10 release in 2016, they also introduced public code names such as Anniversary Update or Creators Update. But this is more or less only a way for marketing to describe a future version without already stating the exact release date, which is possibly not fixed at the time of announcing the new version.

When speaking of the defer option, a lot of sources mix it up with the Current Branch for Business (CBB). But this is only partially correct. When a new Windows 10 version is released, it is automatically CB. After around 4 months, when several cumulative updates have ironed out all remaining hiccups or when a newer version is released, the ISOs will be updated and the CB will be declared as CBB. So CBB is not different in its bits and bytes; it's just updated media and a different name.

This branch was renamed with Windows 10 1709 to Semi-Annual Channel.

Organizations can selectively delay CB and CBB updates into as many phases as they wish (also called a ring model) using one of the servicing tools mentioned in the CB section. Deferring a version long enough will result in it being on an older branch than the current CBB. If you now name it just CBB, it could be misleading.

We should instead always speak of a CB or CBB with its version (for example, CBB 1703) or as CBB and CBB+1, where CBB+1 is the older version. I prefer the year year month month (YYMM) versioning. Also naming convention of CBB/CBB+1 will be completely replaced with 1709 by Semi-Annual Channel (Targeted) and Semi-Annual Channel (without any extension). So beginning with Windows 10 1709 we should speak about Semi-Annual Channel 1709.

So, when you are able to defer feature updates as long as you want, how long is such a CBB / Semi-Annual Channel version supported and getting security updates?

Before the release of Windows 10 1709 it was rather complicated, the answer is a minimum of 12 months support, according to Michael Niehaus, Director of Product Marketing for Windows at Microsoft:

Most people were only reading 12 months and getting scared. But in fact, the support time frame can be much longer:

The minimum 12 months' time frame starts at the time when a release gets declared as CBB. So you always get a minimum 4 months of CB (blue bar) + 12 months of CBB (orange bar) + 60 days grace period (grey bar) after a release goes out of support. So each feature update release will be supported and updated for a total time frame of at least 18 months.

Depending on how many releases are done per year, this time frame could be even longer, because a release will be supported as long as there are no more than two CBB versions at the same time. For example, 1511 released in November 2015 got support until 1703 was declared CBB in August 2017, and with an additional grace period of 60 days, it was supported and updated for 24 months in all. (Version 1511 was declared CBB in March 2016, release 1607 was declared CBB in November 2016. When release 1703 was declared CBB, there would have been three CBB versions in the field and so support for the 1511 CBB was dropped and the grace period started.)

In the unlikely event of three releases a year, the other rule of a minimum 12 months' CBB support will jump in, so in all circumstances, you will always get a minimum of 18 months of total support and update time beginning with GA.

All these CBB, CBB+1 and Grace Period phase was more confusing than helping. With the release of Windows 10 1709 a lot of things were made easier. CBB is now named Semi-Annual Channel. And there is no more Grace period, no more calculating, no more dependence on any version release. You will get a fix full support time frame of 18 months.

Windows 10 will be released 2 times a year with a target frame of March and September each. After release each Windows 10 Version will be supported 18 months fix and end of support date will be available on release date or short after.

A lot of enterprise customers requested already longer support time-lines. At the time of writing this book the time was still 18 months. Look out for announcements regarding a longer opt-in time frame after release of 1709.

The Long-Term Servicing Branch (LTSB) has a ten year support time frame, like with former Windows releases. The ten year time frame is also split into five years main support and five years extended support. During this ten year time frame, the LTSB will only get security and quality updates but no feature updates. Stability and not breaking anything are the most critical points.

LTSB versions are only available as Windows 10 Enterprise LTSBs. So if you do not have Windows 10 Enterprise, you won't qualify for LTSB. The version always contains a year in its name. So the first LTSB version created is now referenced as Windows 10 Enterprise LTSB 2015. In 2016, Windows 10 Enterprise LTSB 2016 was released, but don't expect this to be a standard occurrence. Releasing the 2016 version was an exception, and the next LTSB version is not planned for release before 2019. New LTSB releases are planned typically every two or three years. To get new features, you will need to install a newer LTSB version.

IT pros getting nervous when reading about two updates per year at the CB/CBB branch may be tempted to select the LTSB as it seems at first like all the previous Windows versions' support strategies. But there are several risks and limitations when choosing the LTSB.

The LTSB was designed for specialized systems such as controlling medical equipment, point-of-sale systems, and ATMs. These devices typically perform a single important task and don't need feature updates as frequently as other devices.

Maximum compatibility, reliability, and stability are the key focuses of the LTSB, which makes changes to the kernel and system less possible. Using MS Office and other products on your system that would need changes to the system would block a patch. Therefore, you could end up in a situation where the only workaround would be waiting for the next (fixed) LTSB or changing to CB/CBB meanwhile.

At the time of the LTSB 2016 release, the latest processor families were Intel's Kaby Lake and AMD's Kaveri platforms. Newly released processors such as AMD Zen or Intel Cannonlake will most likely not be supported on LTSB 2016 as they will need modifications to the kernel and the system, and this is in conflict with the maximum reliability and compatibility goals.

The LTSB has some more limitations, which the following table summarizes:

Even so, since 1607/LTSB 2016, support has been introduced to perform an in-place upgrade from LTSB to CB/CBB; there is no support yet to perform an in-place upgrade from a down-level OS to LTSB or from CB/CBB to LTSB.

So you could end up in a situation where Kaby Lake and Kaveri are no longer available, but neither is the LTSB version, so you will have an image but no suitable hardware.

With all the limitations and caveats of LTSB, it is best to stay with CB and CBB for most of your PCs. Use LTSB only in situations where long-term maintenance is essential, such as in production lines, point-of-sale systems, and medical control systems. Most enterprise customers decide to roll out CB and CBB on their main general purpose systems and so should you.

With the introduction of Windows 10, there was also a change to the installation mantra. Earlier, it was recommended you create a golden image and always perform a wipe and load sequence. Now with Windows 10, it is recommended you perform an in-place upgrade. Also, a new option with provisioning is now possible. We will look at the different new possibilities.

With the improvement of the Windows servicing stack, the possibilities of in-place upgrades got faster and more robust. In-place upgrades aren't the go-to solution, but will do well for a large number of scenarios. Performing an in-place upgrade will preserve all data, settings, apps, and drivers so, it will reduce a huge part of the complexity of migration, transfer of user profile, and (re-)installation of programs.

A big benefit of performing an in-place upgrade is 100% rollback in case of failure. With a classic wipe and load, if there is something wrong after installation, the user ends up with nothing, putting a high time pressure on IT to solve the problem. Mostly, this pressure results in a fast workaround of reinstalling the client a second time and losing all data, settings, apps, and so on.

When something goes wrong during an in-place upgrade, it will completely roll back to its original OS and the user will still be able to work with their client. This gives IT some time to inspect what went wrong and try again later when they have a fix. Even after a successful upgrade, IT has the ability to roll back to the old OS for 10 days if something else is not working as expected.

The current in-place upgrade process is divided into four phases, with multiple reboots in between:

• The Downlevel Phase: Depending on whether you are executing setup.exe or executing this phase by upgrading via Windows Update or WSUS, the GUI will be different. But technically, the following steps always need to be done:
  • Build a $Windows.~BT folder, analyzing the system and downloading required cumulative updates (if not restricted by setup flags)
  • Extract required drivers from the running system or (if not prohibited by setup flags) download drivers from Windows Update
  • Prepare the system and the sources, place a SafeOS Windows Preinstallation Environment (PE) boot environment, upgrade the boot entry, and suspend BitLocker (if running)

You will see this phase as Windows Update preparing your system, counting from 0% to 100%. The system will reboot after this phase. Setup result error codes (the second code after the 0xC19xxxxx code) in this phase typically start with 0x100.

• The SafeOS Phase: In this phase, a Windows PE instance is running, which is why it is called so. The recovery partition will be prepared and updated, the old OS will move offline to Windows.old, a new Windows folder will be built, and the new OS WIM will be applied to the drive. Dynamic updates and OS updates will now be installed. After that, the required drivers will be integrated so the system can boot from the new Windows version next time. You will see this phase in older Windows 10 releases as a black screen with a grey ring, like doing a setup installation and in releases since 1607 as a blue screen, like installing Windows Updates, with a message stating part 1 of 3 and counting from 0% to around 30%. The system will reboot after this phase. Setup result error codes (the second code after the 0xC19xxxxx code) in this phase typically start with 0x2000C or 0x20017.
• The First Boot Phase: Now the new system will boot up for the first time and run through the sysprep phase. Device drivers are getting ready and the migration plugin is running to extract all required data from the old OS. Already, the first boot data and settings have been applied. You will see this phase as part 2 of 3 and counting from 30% to 60%. The system will reboot after this phase. Setup result error codes (the second code after the 0xC19xxxxx code) in this phase typically start with 0x30018 or 0x3000D.
• The Second Boot Phase: In this last phase, the system runs the migration plugin one last time, applies the last migrated settings, starts the system services, and runs the Out of Box Experience (OOBE) phase. You will see this phase as part 3 of 3 and counting from 60% to 100%. The system will present you with the login screen after this phase. Setup result error codes (the second code after the 0xC19xxxxx code) in this phase typically start with 0x4000D or 0x40017.

With this move of Windows to Windows.old and a complete rebuild of the new OS, only migrating the required settings, apps, and drivers, the whole process is now very robust and prevents too much waste from older OSes. Even so, Microsoft does not provide detailed numbers. We could observe only very low numbers of rollback at approximately 2%-5% in huge national and international customers. And even if a rollback occurs, the system is still usable.

This in-place upgrade process runs smooth and fast on modern hardware. We clocked approximately 17 minutes on a Surface Book i7 with 256 GB NVMe and 60-70 apps installed. Even on a 3 or 4-year-old i5-class system with an SSD, times of approximately 25 minutes were possible. On very old hardware with low-RPM HDDs and a low amount of RAM, installation times can grow up to 1 hour 30 minutes and more.

With all the big benefits of the in-place upgrade, it still has some limitations and caveats. We will try to identify all blockers and limitations and try to formulate possible workarounds.

The main blocker, especially for releases up to 1607, is installations done in BIOS or legacy mode. You can perform an in-place upgrade in BIOS mode, but you will end up in BIOS mode again. A lot of enterprise customers want the benefits of the new UEFI mode, especially the new security features, which require the secure boot feature, which itself requires UEFI mode. So you end up having to decide between doing a smooth and fast in-place upgrade and not being able to use UEFI, secure boot and dependent services such as Credential Guard and Device Guard, or you can perform a classic wipe and load with all its problems of losing settings, needing to store user data, and so on.

Beginning with release 1703, there is now a method supported by Microsoft to change from BIOS mode to UEFI mode without installing an OS. The required tool, MBR2GPT.exe, is now included in the OS sources. MBR2GPT needs to be executed in offline mode, so run it from within Windows PE or attach the disk as a data disk to a running OS and execute it from there. If you are already on release 1703 or higher, you can convert it before upgrading to a new OS. If you are on a lower release, you first need to upgrade to 1703 at least. The tool can only prepare the disk, convert the MBR to GPT, and update the boot entry. To change the firmware itself from BIOS to UEFI mode, you need to use the manufacturer tools or do it manually.

A blocker that still exists and will persist in the future is trying to perform an in-place upgrade from an x86 to an x64 OS. In fact, you will be able to perform an in-place upgrade, but you will only be able to keep your documents and not your apps. There are too many changes with different paths, dual structures in the registry, and so on to keep this blocker going into future releases. So if you need to upgrade to x64--and trust me, you want to upgrade to x64 as new hardware will no longer provide x86 drivers and a lot of features are not available in x86--you can keep your files or go with a wipe and load. Microsoft will still support a 32-bit version of its client OS, but features requiring Hyper-V, such as Virtual Based Security, Credential Guard, and so on, will only be supported on the 64-bit version.

You can't change the base OS language on the fly during an in-place upgrade. If your current base OS is for example en-US with language packs installed for de-DE, you are not able to upgrade your system with a new base OS with de-DE as the base language. If you try to do so, the in-place upgrade process will not migrate your applications. There are some hacks on the internet to install all the language content of the new base language you want to change to, booting into Windows PE and setting the new international settings, and getting an OS that looks like it is specific to this changed language and will be accepted by the in-place update routine. But be warned: this is not officially supported in terms of not being tested by Microsoft, and therefore, you could run into trouble and not be able to get official help.

With 1703, the partition type problem of MBR to GPT is solved, but all changes are still not possible out of the box. The included tools like diskpart only support shrinking or expanding a partition, but not merging or moving a partition or converting it from logical to extended or vice versa. So if you opted for a different disk layout involving such kinds of changes together with the new OS, you need to create the new structure before or after the upgrade with third-party tools or go with the classic wipe and load option.

Since Windows 8.1, there have been no major improvements done to the Windows To Go feature. Since 8.0, there were problems in performing an in-place upgrade, and these limitations still persist. So if you go with Windows 10 CB/CBB in a Windows To Go scenario, you will end up in a wipe and load one to two times a year for your USB media. The only way to circumvent this problem is to use the LTSB version on Windows To Go media, but with all the limitations and problems of LTSB.

Boot from VHD in terms of saving space was replaced by a better feature called Compact OS. So if you have been doing boot from VHD only for space savings, you should do a wipe and load and go with Compact OS in future, which is fully in-place capable. If you've used boot from VHD for separating different (test) installations and want to use this feature in future versions, you need to do a wipe and load every time.

In short, you cannot in-place upgrade your golden image and then do a sysprep. The process will detect it and present you with an error message: Sysprep will not run on a upgraded OS. The long version is that it is recommended you always build your golden image from scratch with a base ISO of the new Windows version. As your running systems will be able to upgrade in place, you will need your golden image in the future only for break fixes and installation of new hardware. And in the case of new hardware, the new process of making provisioning packages will be replaced in some years. Don't try any dirty hacks to remove certain regkeys used by sysprep to detect such an upgrade. You do not want to install an unsupported solution to thousands of clients. Invest the time to create a new golden image.

Even though there were improvements in the 1607 and the 1703 releases with setup.exe command lines to support more third-party encryption systems, you can still end up in a situation where an in-place upgrade is not possible or runs into a severe error. To prevent this problem, you need to upgrade to the newest version of your product. If this still does not help, you can only decrypt your drive (which is time consuming) or use a classic wipe and load without retaining your apps, data, and settings.

Too much changing of applications is not a major blocker but could limit your installation times. As in-place upgrade only supports the swapping of the base OS, all application changes needs to be done before or after the upgrade inside some task sequences. This could be very time consuming, and when your top priority goal is deployment time, especially if there are no or low user data amounts and settings which need to be converted, the classic wipe and load could be a better option.

Change of domain is not supported inside the in-place upgrade as the corresponding sections inside your sysprep XML will be ignored. If you need to change domain, local admins, and so on, you need to do this before or after the upgrade. If it is not possible to run the new OS in the old environment or the old OS in the new environment, you could be limited to the classic wipe and load method.

The well-known process of creating a golden image, syspreping it and deploying it to your clients, also known as wipe and load, will still be available with Windows 10 and still be supported in the near future.

To adapt your existing wipe and load process to the new Windows 10 OS, you just need to exchange your Windows Automated Installation Kit (WAIK) or Assessment and Deployment Kit (ADK) with the newest ADK provided by the latest Windows 10 release. This implies that your deployment solution is capable of handling the newest ADK version. Carefully check every modification to the golden image to see if it is still a supported setting or has been deprecated. Also see if the feature you are (re-)enabling is perhaps now disabled by default (for example, SMB1 support). This could be a hint for support in future versions.

Do not modify binary registry keys, also known as binary blobs, and use only documented registry keys, as with every new version, undocumented registry keys can change behavior or vanish, even with cumulative updates. As they are not officially documented, there needs to be no official warning or announcement.

If you want to provide an experience similar to in-place upgrades, you need more steps, more tools (for example, the User State Migration Tool), and possibly more external storage. In some rare cases, such as bulk app changes, you may need more time.

A down-level OS with lots of security mitigations like excessive use of ICACLS and other rights management tools to bend the security of the OS to comply with outdated or suboptimally programmed applications may also qualify for a wipe and load instead of an in-place upgrade, which will possibly carry on these changes.

The new Windows Configuration Designer (WCD) is part of the Windows 10 ADK. It will be updated/enhanced with each release of the ADK. With the release of Windows 10 ADK 1703, it was renamed from Windows Imaging and Configuration Designer (WICD) to WCD.

Not only does it have the ability to create configuration packages, but it is also able to switch the SKU of your Windows 10 installation. This was previously not possible. You still cannot move to LTSB via this mechanism, as this is a completely different build. At this stage of the process, you cannot downgrade. Currently, only an upgrade from Pro to Enterprise is possible (except for the Education SKU, which allows an upgrade from Home to Education).

The WICD can be used to create packages that implement any MDM-based setting. Alternatively, you can run external scripts to set most MDM settings.

For some actions, such as pre-provisioning Windows 10 Mobile or switching to Windows 10 Mobile Enterprise, WCD is the only tool available to the enterprise.

WICD has a wide range of functionality in addition to script support. All in all, it sounds like a mighty and powerful tool. However, it is currently not directly supported inside the Microsoft Deployment Toolkit GUI and inside SCCM 1702; this is subject to change in future releases. You can integrate a command line as a workaround, but this has a major drawback.

Currently, there is no way to fully automate or silently install the provisioning package. You can sign the package to remove some prompts, but not in all circumstances. You also need to embed it in an image so that it gets installed during the OOBE process to get no prompts. However, this takes away a lot of flexibility.

It has been our field experience that certain functions that WCD can perform or try will break the Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager (SCCM) deployment process. Therefore, it should be tested and care should be taken while including this tool in your work (at the time of writing this).

Also it still lacks the ability to remove crapware and bloatware preinstalled onto vendor OS images. As long as a Windows 10 signed edition is not available worldwide and from all vendors, the tool definitely needs improvements in this section.

This tool is likely to be improved in future releases of the ADK. Also, future releases of MDT and SCMM will likely support WCD directly in the GUI, so keep an eye out for release note changes and an improvement in the tool's capabilities. More information on WCD will be covered in the next chapter.

Windows 10 delivers many new security and enterprise deployment improvements. Windows 10 also includes new options to improve and automate deployments and upgrades to keep pace with the fast release of feature updates. We will show some important improvements in deployment in the new Redstone branch.

With the introduction of the 1607 release, the upgrade Update Progress UX was refined and visually adapted to a multi-boot update process. At first look, you will hardly spot the differences. Before this change, the upgrade UX was just like the bare-metal setup process. with a black screen and grey round circle.

Together with this refining, the upgrade process itself was also improved. It is now 15-20% smaller and therefore faster. When compared to previous upgrade times between 60 and 120 mins, since 1607, it is down to between 30 and 90 minutes, and on very fast hardware down to 17 minutes.

Before this release, the Start menu was customizable, but not the taskbar. Now there is the possibility to pin/exchange up to five icons on the taskbar. But you will need to recreate the required XML files.

Besides the graphical changes, pay attention to the new driver signing requirements for better security.

With Windows 10 1703 the Windows Imaging and Configuration Designer (WICD) was re-branded to Windows Configuration Designer (WCD) and its Wizards were re-designed. The possibility to modify the Image itself, mainly a OEM feature, was removed and Wizards for more Windows SKUs were added. A closer look to WCD will be done in next chapter.

Windows 10 1703 introduces the Unified Update Platform (UUP) under the hood.

To benefit from this reduced download size of build updates, you will need a UUP-enabled build as footprint. The first enabled build was Insider Build 14959. To benefit from official releases, you need to roll out 1703 and upgrade to a newer version.

So which is the first release that will benefit from UUP? As UUP needs a base footprint of the previous OS to work on, you will get this benefit only if upgrading from Windows 10 1703 or newer. If you skipped 1703 and are directly jumping from 1607 to 1709, you will miss the required known footprint of the previous OS and so cannot use this feature until the next upgrade.

It was planned to leverage this feature to Windows Update (WU), WSUS, and SCCM including third-party deployment solutions. In Windows 10 1709 the new UUP is only enabled when using WU as a update source. Support for WSUS, SCCM and 3rd Party will follow earliest in Windows 10 1803.

To get a impression which savings are possible in first release a estimated size graph was released together with announcement of UUP. Saving is approx 50-60% over WIM size and still even more than 35% over ESD size.

Another deployment feature added with Windows 10 1703 and enhanced with 1709 is the new Windows AutoPilot. This feature enables IT professionals to customize the Out of Box Experience (OOBE) for Windows 10 and enable end users to take a brand-new Windows 10 device and get a fully-configured business device with just a few clicks. Users will walk through the self-service deployment of their new Windows 10 device without needing IT assistance.

IT will (optionally) pre-configure settings like privacy settings, OEM registration, Cortana setup, OneDrive setup and choosing between personal or work device and preventing the account used to set-up the device from getting local administrator permissions.

The device needs to be registered to your organization. IT will need to acquire the device hardware ID and register it. Microsoft is actively working with various hardware vendors to enable them to provide the required information to organizations or upload it on behalf of them. In the meanwhile there is a script to gather these information available at https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo.

The end user will unbox an turn on his new device. He just needs to configure a few simple steps:

• Select a language and keyboard layout
• Connect to the network
• Provide Azure AD email address and password

All settings configured by IT will be skipped. Following this process the device will be joined to Azure AD and enrolled into Microsoft Intune or other third-party MDM service configured.

With Windows 10 1703 it is already possible to joint into Azure AD and MDM. With the release of 1709 or short after it is planned to enable self-service deployment to Active directory domain-joined devices and enhancements to the OOBE to offer a highly-personalized and specific OOBE. Additionally there is a Windows AutoPilot Reset capability planned to enable organizations to easily reset their configured devices while still maintaining MDM enrollment and the Azure AD join state to get the device back into business ready state very fast.

The in-place upgrade is already very stable and robust, but with some tips, you can improve the robustness even more.

During the Insider Preview phase, several tens of thousands of different configurations will be tested, but there will still remain some minor hiccups in the very first ISO/WIM released directly at GA (typically this version is something like 10.0.14393.0). If you have a .0 image or with a low one digit number at the end, you should integrate yourself into the latest cumulative update. Do not wait four months until the declaration of CBB and auto-update of sources.

Upgrading your install.wim is very easy. Download the latest cumulative update from Windows Update Catalog. Unpack the ISO and mount the included install.wim to a temporary folder. Add the .MSU file with DISM.exe, commit the changes, and unmount the WIM file. To reduce unnecessary growth of the WIM file, start over each time with the original WIM.

Update the installed graphics card driver of your down-level OS before attempting an in-place upgrade, especially if your driver is from before July 2015. Also update your SD card driver, as we've faced installations freezing several times during the first boot phase when initializing the SD card device. If there is still a problem in the 30% to 60% first boot phase, try to detach unnecessary hardware during the upgrade.

Setupact.log and Setupapi.dev.log are perhaps the two most important log files that are used during update/setup failure troubleshooting. Here are the locations these files will be typically located at, depending on the deployment phase:

• Down-level (Setupact.log): Used for troubleshooting rollbacks and down-level failures

Location: $Windows.~BTSourcesPanther

• Rollback (Setupact.log): Used to troubleshoot rollback and and uninstall failures

Location: $Windows.~BTSourcesRollback

• Windeploy and OOBE (Setupact.log): Used to troubleshoot failures during OOBE

Location: $Windows.~BTSourcesPantherUnattendGC

• Pre-initialization (Setupact.log): Used to troubleshoot pre-launch failures

Location: Windows

• Upgrade Complete (Setupact.log): Used for post-upgrade investigations

Location: WindowsPanther

During private and public preview the service was named Windows Upgrade Analytics. With its release to productive state it was renamed to Windows Upgrade Readiness. This new service is available to enterprise environments that makes use of the telemetry feature of Windows. While some view telemetry as a spying or data collection problem, Microsoft shows that they are using the data to improve Windows while at the same time helping organizations upgrade to Windows 10. The analytics features will work on Windows 7 and preceding hosts and allow the enterprise to gauge what hardware needs to be replaced before making the move to Windows 10. A detailed write-up of the service offered can be found in this article: https://docs.microsoft.com/en-us/windows/deployment/upgrade/manage-windows-upgrades-with-upgrade-readiness.

This question is not easy to answer. Different people will have different preferences and therefore favor different deployment tools. But perhaps we can roll up to the question from a different side as it is just the same if you use MDT, SCCM, or a third-party deployment.

It is important to use the latest ADK delivered with the Windows 10 release you are deploying. Your ADK should be at most one release older; have a look at the known issues page of the ADK before picking it. From this important requirement and the release cadence of one to two Windows 10 releases per year, we come to the next prerequisite.

Your chosen deployment tool should get at least one to two updates per year to support the newest features and newest ADK. As more and more configuration is not only done by GPO but also by MDM and WMI bridge, it becomes more essential that your deployment and configuration environment keeps up with the pace.

Last but not least important is the ability to script pre- and post-upgrade task sequences. You will most likely run into situations where you need to configure, update, or remove something before performing the upgrade, and the same applies to the phase after a successful upgrade. As some configurations can only be done from PowerShell, you should select a deployment tool with (direct) PowerShell support.

In this chapter, you learned the concepts and best practices of the new deployment options introduced with Windows 10. We looked into the traditional wipe and load method and the complementing new options of in-place upgrade and provisioning and provided some context to the difference these deployment options can make.

The next chapter will walk you through enterprise deployment and in-place upgrade techniques. Deployment tools will be covered as well as tips and tricks to smooth in-place upgrades from 7 to 10 and migrate user state information and settings.