Migrating to Windows 11

It’s been a few months now since Microsoft released Windows 11 (Oct 5th 2021 so 3 months at time of writing) and with the holidays in between, not a great deal of migration motions have really started.

However, now that we’re back into the swing of things with 2022, maybe it’s time to start considering the plans for migration?

Windows 11 desktop with start menu open

Thankfully, there’s nothing revolutionary in Win11 that means a big change to process from Windows 10. That’s assuming you already had a Windows as a Service (WaaS) lifecycle process in place already…

Some of the main pillars that need to be thought about consist of:

  • Hardware
  • Applications
  • Features
  • Security Controls
  • Deployment Schedules

You could add Deployment Methods to that list, but that’s more of a technical tool choice/enabler to the process than part of overall methodology so I’ll leave that for another post, maybe.

Hardware

While every WaaS lifecycle run should include an assessment of hardware during the validation phase, mainly to identify devices out of warranty or past their refresh point, Windows 11 does actually pose some interesting requirements/recommendations when it comes to hardware.

This time round for Windows 11, we should be specifically assessing the hardware in the estate for:

  • Supported CPU (1Ghz+ and 2 or more cores)
  • 4Gb or more memory
  • 64Gb storage or more
  • UEFI firmware that is Secure Boot capable
  • TPM 2.0
  • Is already running Windows 10 2004 or above for upgrades

Most hardware within the last 4 years “should” have a TPM 2.0 chip (discreet or CPU embedded) and is fairly easy to check for, but the “Supported CPU” statement is something new.

I do understand where Microsoft are going with this, in order to make sure access to the enhanced security features such as Virtualisation-based security (VBS) and Hypervisor-protected code integrity (HVCI), it requires CPUs that support it. Part of me also assumes that with the whole performance hit CPUs took with Spectre, moving to newer CPU architectures that attempt to mitigate some of the performance penalties also can’t be such a bad thing.

However… it does mean paying attention to this and identifying what can and can’t fully support Win11.

The official list is here, but it’s quite a big one to wade through:

https://docs.microsoft.com/en-us/windows-hardware/design/minimum/windows-processor-requirements

If you want to do some spot checks, there’s the PC Health Check app that Microsoft released to allow some diagnostics to be run on your Windows 10 device manually:

https://www.microsoft.com/en-gb/windows/windows-11#pchealthcheck

But to check at scale, we really need something automated… which is where the Windows 11 hardware readiness report section of the Work from anywhere (odd choice of report naming/combination if you ask me) comes into play.

https://docs.microsoft.com/en-us/mem/analytics/work-from-anywhere#bkmk_windows11

With this report you can quickly see which devices are capable, or not, of upgrading to Windows 11 along with the reasoning of why not that will allow you to make decisions on hardware refreshes to support this or the next WaaS lifecycle run as appropriate.

The report should provide reasons back across:

  • Storage
  • RAM
  • TPM version/missing
  • Firmware
  • CPU Core count
  • CPU Family support
Image showing the Windows 11 readiness report sample from Intune
Capability to upgrade to Windows 11 shown in Intune

Applications

Nothing new here at all for Win11, however there’s always an opportunity to improve a process.

At a minimum a standard method of packaging should already be implemented, making it hopefully as easy as possible to quickly re-use apps regardless of the target for deployment (Win32 Intune app vs. ConfigMgr App Model vs. Azure Image Builder for AVD etc), but maybe take the time to look into MSIX and start the process of seeing what that may give as benefits or how it would work within the environment.

https://docs.microsoft.com/en-us/windows/msix/overview

Next is the process of testing and verifying that the apps do actually work (and work well) on the new version. Again, this should have been done for each previous release of Windows 10 and arguably should be done against monthly quality updates. But that would be a complete drag time wise monthly if done in a manual fashion… enter Microsoft Test Base!

https://docs.microsoft.com/en-us/microsoft-365/test-base/overview

While currently in a Public Preview state and not specifically aimed at Enterprises (mainly for software vendors writing the apps themselves at present) there’s scope enough within it to look at automating your key apps for installation, open, perform key actions, close and uninstall.

While it may evolve into having specific key enterprise integration (Automated Intune app deployment anyone??) there’s nothing to stop investigating it’s potential right now.

Shows the Microsoft Test Base main console with Adobe Acrobat passing various tests
Adobe Acrobat passing automated tests against various Windows versions in Test Base

Features and Security Controls

This is a little bit more nuanced. Basically with each release the OS needs assessing to see what new features are introduced and if they’re optional and of benefit or mandatory and potentially introduce changes to security, experience or productivity.

With Windows 11 we have the following examples:

Feature Effect Requirement
New Start Menu
User Experience Change
Mandatory
New Teams App
Experience and Security Change
Default but removable
Windows Snap Assist
User Experience Change
Mandatory
Widgets
User Experience Change
Default but changeable

Obviously, anything that may introduce a user experience change should be communicated to end users as part of the upgrade rollout communications and where necessary any training given.

I marked the new Teams App as a security change. This is in the context that at present the new app built into the Windows 11 install is only for personal accounts and depending on the organisation’s controls (think Data Loss Protection) this might be deemed unwanted and therefore planned for removal.

It may be as well that (even if not new new) this rollout is deemed as the right time to introduce some of the optional (but needed) security controls available such as System Guard, Windows Hello for Business, Application Control etc.

In short, take time to go through the new features within the new release, update Group/Intune Policy controls where needed and assess new features to be implemented that might require additional infrastructure changes or other mini-projects to enable.

Talking of Security Controls, Microsoft did provide a little bit of a curve ball with Windows 11 and Group Policy…

The new ADMXs for Windows 11 aren’t compatible with the Windows 10 ADMX files, essentially meaning you can only have one or the other versions stored in your central PolicyDefinitions folder.

Current recommendation from Microsoft is to continue to store the Windows 10 ADMX files in the central store and use a Windows 11 device with a regkey to force local ADMX usage when editing specific Windows 11 targeted policies until you have more Win11 than Win10 within the environment, at which point reverse the approach above.

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/windows-10-or-windows-11-gpo-admx-which-one-to-use-for-your/ba-p/3063322

Personally, If you’re still using Group Policy for Windows 10, I would take the opportunity to go pure Intune Policy control for Windows 11 (and optionally look to bring Windows 10 along for the ride). At least this way you don’t have to mess about just to edit and control GPOs.

Deployment Schedules

With Windows 10 Microsoft were very keen to recommend and get people using Desktop Analytics, which to be fair, made sense and we ourselves at PowerON used it regularly. Desktop Analytics gave some good inside into device readiness, spread of applications to give a good test group representation, blockers etc.

However, that’s not an option with Windows 11 as Microsoft have not added support and will deprecate the service on 30th November 2022.

So, while most organisations will be comfortable with defining small test and slightly larger pilot groups, what to do with splitting up the larger deployment groups for the business.

Firstly, don’t overthink it.

If the organisation is large enough to have multiple geographic regions, then maybe think about splitting it that way as to allow easier localised support efforts if needed, but if using Windows Update for Business (WUfB) then some incoming changes will likely have you covered for rollout.

The new Windows Update for Business deployment service (WUfBDS??) introduces some new controls for scheduling, along with automatic intelligence to choose which devices spread across a group based on hardware, installed apps etc to help phase the update within the group.

https://docs.microsoft.com/en-us/windows/deployment/update/deployment-service-overview#schedule-rollouts-with-automatic-piloting

Quoting the example from the doc:

“You can stage deployments over a period of days or weeks by using rich expressions (for example, deploy 20H2 to 500 devices per day, beginning on March 14, 2021).”

Summary

In summary, not a lot has changed in the approach to deploying Windows 11 from the previous Windows 10 (1909 > 2004 > 20H1 > 20H2 > 21H1 > 21H2 etc) except for the additional requirements around hardware to be considered. I would recommend using this upgrade as an opportunity to further refine the process used and take a look at further hardening your security.

Image showing the PowerON WaaS Lifecycle approach with different phases involved.
PowerON WaaS Lifecycle Approach

Why not reach out to myself and the team at PowerON if you have more questions or need a hand. Also, don’t miss out on the Windows Lifecycle servicing strategy guide we have available as a free download.

In this article:

Share on Facebook
Share on Twitter
Share on LinkedIn

Related blogs

laptops on a desk in an office

What is Windows Autopatch? 

You’ve likely been hearing a lot about Windows Autopatch lately! We’ve been getting a lot of questions around the solution, so I’ve collated some of