- Can’t uninstall app: Delete or change Windows apps that have been flagged as non-removable - Thu, Mar 16 2023
- FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
- Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022
Windows 10 brings a new set of challenges for deployment and management. Universal Windows Apps, Start menu and interface changes, user accounts and synchronization – these are a few of the areas where administrators and architects will find Windows 10 markedly different from previous iterations of the Microsoft operating system.
The largest change, though, is arguably the move from the previous updating paradigm to the new Windows 10 "servicing" model, and it is this that introduces one of Windows 10's greatest challenges. It is an important question about Windows 10 deployment, and possibly the most pertinent one for anyone adopting the new operating system. When applying Windows 10 "feature upgrades" – which are new releases of the OS, arriving on a regular basis – do you allow an "upgrade in place" to proceed, or perform a fresh install, sometimes also called "wipe and reload," each time?
This doesn't just apply to Current Branch for Business – LTSB has an update available every year, and if you wish to take advantage of the new features available in that annual release, you will need to perform an upgrade of the operating system.
Upgrading Windows versions
When initially moving from the previous version of Windows (XP, 7, or 8) onto Windows 10 for the first time, a "wipe and reload" approach makes a lot of sense. Traditionally this is how Windows operating system upgrades have been approached, but because of Windows 10's "fast update" cadence, this may no longer be sustainable.
OS upgrades were a project that previously came along every three or four years and could be allocated the required amount of resource, but now, with potentially two releases in every 18-month period, Windows admins have reached a state of "perpetual migration." Performing the required testing, remediation, and deployment planning that goes with this puts an extra strain onto IT departments that may already be short of resources.
Seasoned IT pros on in-place upgrades
Seasoned Windows veterans have a very dim view of in-place upgrades. This prejudice towards performing an in-place upgrade is borne out by the statistics below (compiled from a survey of EUC staff).
Windows 10 feature upgrade preferences
In the main, experienced administrators are worried about the potential for "cruft" from the previous user environment persisting into the upgraded one, and also the possibility for applications and/or the OS to be unstable or broken once the upgrade is completed. Incompatibilities or even security threats will be brought into the new environment if the upgrade route is taken. This has to be balanced out, though, against the persistence of user applications and data that the "in-place upgrade" provides to the user.
Fresh install considerations
If you decide that the "wipe and reload" approach works best for your environment, then you need to put tools into place to persist the pertinent areas of the user experience, to ensure that your users have a smooth transition from each feature upgrade to the next. The key areas are:
- Applications – ensuring that the user has easy access to the applications they need to perform their jobs
- Data – maintaining access to the user's data, whether they have stored it in standard or non-standard locations, and also ensuring that supplementary data (such as PST files) are still available
- Profile – capturing all of the settings that complement the user experience, such as shortcuts, MRU lists, file type associations, autocomplete files, custom dictionaries, views and layouts, etc.
The user personality components
Ensuring that access to all of these areas is maintained is vital to being able to maintain user productivity once a feature upgrade has been applied. It is also vital to identify and communicate user interface changes and feature additions/removals that may have occurred during the feature upgrade application, so that users are able to effectively use the operating system from the off, and deal with any changes to their working environment.
In a VDI environment
If you're running Windows in a VDI environment (particularly a non-persistent VDI environment), then a fresh install may be a viable option. This is simply because VDI environments, especially non-persistent ones, often already have tools in place to provide smooth roaming between sessions, which can ease the pain of a regular operating system upgrade. Traditionally, a new OS means a new VDI base image, and there are usually already teams in place to deal with image management and updates.
If you're not in a VDI environment, then you need to decide, to put it bluntly, whether you trust Microsoft to make the Windows 10 "in-place upgrade" experience as painless as possible. Microsoft are very keen to make the point that Windows 10 is "a new way of upgrading Windows," possibly to try to combat the natural aversion that experienced Windows administrators have to performing in-place upgrades.
Conclusion
Certainly, the first few instances of in-place upgrades, and the associated success rates, will drive the future policies of IT departments towards them. If departments find they are performing mop-ups of failed upgrades at a rate of, say, 40% – which will probably need the wipe-and-reload treatment to fix – then it will appear more sustainable to invest in technologies that can allow for a fresh install approach.
If the failure rate is much lower, perhaps under 5%, then it may be that in-place upgrades start to be viewed as an acceptable option. However, sustaining a good user experience after the upgrades also has to be factored in, along with the fact that it will take only one major issue during an upgrade for all of the built-up trust to erode away quite rapidly.
Microsoft has to maintain a high success rate over the entire Windows 10 operating system evolution in order for people to fully embrace the "in-place upgrade" methodology – major disruptions to line-of-business applications and user productivity will not be tolerated for long.
Moving to a "perpetual migration" model is a headache that understaffed and overstretched IT departments don't need. It is very important to make the decision early on whether "wipe-and-reload" or "in-place upgrade" is the method of choice to suit your estate.
Subscribe to 4sysops newsletter!
To support this, it may be necessary to adopt a tool or stack of tools that allows you to decouple the user data, applications, and "personality" from the underlying OS, so that they can easily be injected back in if the operating system is reloaded. Getting this process laid down and operating smoothly will be key to embracing the Windows 10 updating model and to providing quick and easy access to new operating system features as they arrive.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
Great article! One of the biggest reason we very seldom recommend to do an in-place upgrade is the fact that many of the new security features that we want to leverage in Windows 10 like, Credential guard for instance requires UEFI and Secureboot to be used. Which cannot be enabled when we do an in-place upgrade as we must change the partitioning on the machines and wipe the disk.
There are more concern but this is the number one reason for not doing an in-place upgrade.
/Jörgen Nilsson
A great article about a difficult topic. I think as Jurgen says, there will be situations such as security features that require hardware support, that will initially require the wipe and load scenario. But, whilst it’s difficult to predict, I would expect that over time the scenarios requiring wipe and load will become fewer.
Regarding user state persistence, Microsoft has already made inroads here with Enterprise State Roaming (ESR) , and I would expect continual investment, to the point where custom items that are not currently roamed from computer to computer, would be allowed as extensions to ESR.
The biggest question for me would be applications. Breaking applications as part of OS feature upgrades would raise bigger questions than in-place upgrade vs wipe and load. I have seen some clients turn away from Current Branch and favouring LTSB, purely to avoid frequent change and leverage application virtuisation technology to overcome compatibility issues.