Previous blogs in this series:

Part 1 – Introduction : What is WaaS?
Part 2 – Windows 10 Updates.
Part 3 – Servicing Channels.
Part 4 – Servicing Tools.

In the first part of this blog series I introduced Microsoft’s new concept to get Windows 10 systems to the current build and how to stay current as feature updates are made available on a semi-annual cadence.  This is called Windows as a Service whereby an organization ‘services’ – or maintains – their Windows 10 fleet to the latest feature and security (quality) updates no matter how long ago the OS was last updated. 

The purpose of this blog series is to provide some guidelines on what you can do if you have a large and complex organization with tens of thousands of systems that you need to update: so, let’s get to it! 

First, I’d like to start with the famous Deployment Rings that Microsoft introduced with Windows as a Service. There are 3 rings:   

1. Insider preview deployments 

2. Pilot deployments 

3. Broad deployments 

1. Insider Preview Deployment Ring 

As we have seen in Part 3, the Insider Preview edition of Windows 10 is the feature update that is being developed by the Microsoft Windows team before it is released to the general public; it is a pre-release of the feature update.  The Insider Previews are available on a monthly basis on average starting from the first month after the last feature update was made available, until the new feature is made GA.  In other words, the Insider Preview for Windows 10 1909 was available 1 month after Windows 10 1903 was made available. Insider Previews are updated and available for testing for roughly about 5 months (April to August in the case of a September release and October to February in the case of a March release). 

In this ring, you probably want your IT pros and developers to evaluate the previews – say on a fortnightly basis – to investigate whether the new update has or should not have some features enabled.  And, if a new feature is enabled (or disabled/removed), what does it entail for your organization in terms of compliance, infrastructure, communication (to the end-users be they IT Pros, Devs or Information Workers), etc.  It is a period where not only Microsoft works on creating new features but also where users have a voice by providing feedback to Microsoft on how to make the feature better and/or how to fix any issues before it goes GA. 

I recommend to any large organization to take advantage of this phase to the fullest.  But if you are an individual who wants to know what’s coming before the rest of the world, you can subscribe to the Insider program as well. To enrol: 

• As an individual:  https://docs.microsoft.com/en-us/windows-insider/at-home/ 
• As a business: https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-get-started 

Note: Be aware that as the Insider Preview is a pre-release, you might get the odd bug. Focus on the new capabilities that are introduced and report any feedback on the Feedback Hub App directly from your Windows 10; simply select the Start button and type Feedback Hub to select the app (more information here: https://support.microsoft.com/en-au/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app). 

2. Pilot Deployment Ring 

At this point the new Windows 10 feature update is Generally Available. However, as you may (or may not) have tested the new features during the Insider Preview ring, you might want to test the new features with a small subset of your organization before deploying the new build to the entire population. 

Remember that the purpose of testing a deployment is to receive feedback and the Pilot Ring is a test in production; hence, you must carefully select your target systems and end-users whilst avoiding those that could have a negative impact on your business.   

Note: Your business-critical systems that have a specific function and don’t require an interface update – such as for ATMs, medical equipment, etc. – need to be on the LTSC.  If you are piloting an end-user application, you are testing it on a small subset in production so that if there are issues with the compatibility of that application, your business is not – should not – be impacted because you are not testing on all the systems that have that particular application. 

One effective way to recruit users is to request volunteers.  When doing so, clearly state that you’re looking for their feedback rather than people that would “just try it out”. You also must let your volunteers know that there could be occasional issues involved but the expectation is that if an issue does arise, be sure to include members who will provide the broadest set of applications and devices to validate the largest number of apps and devices possible.  

For example, if your organization has 6000 HP devices split into 15 different models of which you can categorise into 4 chassis form factors, then it would be great to have 15 volunteers (1 per model) so that you can validate whether the new Windows 10 update does not have any issues with all the HP devices in your fleet.  Additionally, if you have another 6 models across 4000 Dell systems, and 3 models of your 8000 Surface Pros fleet, etc., in terms of chassis, if you install the new feature update on a laptop model from each manufacturer, you can tick that box confirming that your pilot of  24 systems (15 HP, 6 Dell, 3 Surface Pros) did not have an issue and that all laptops in your fleet from all manufacturers are compliant with the new Windows 10 feature update. 

Furthermore, your 24 volunteers should not be from the same department. You may have 3 of them from the Marketing department, 2 from Accounting, 5 from Manufacturing, etc. as each department has their own set of applications that they use on a daily basis for their “Business as Usual” (BAU) work.  Over the course of the few months during which you are deploying your Pilot, you are confirming that the new feature update does not have any issues with the hardware or software that your organization uses across the whole fleet.  

It is therefore imperative that you select your pilot sample to be as much representative as possible of your whole organisation. Some guidelines: 

• Pick a sample that contains all your hardware manufacturers, models and chassis to validate your drivers 
• Pick a sample of users that encompasses as many of your business-critical applications as possible.  This will help validate that the applications that are most important to your business are in fact compatible with the new Windows 10 feature update. 

Note: If you come across an issue with an application during your Pilot phase, try to immediately remediate it by: 

• Contacting the vendor of that application 

• Contacting Microsoft via the App Assure program at https://www.microsoft.com/en-us/fasttrack/microsoft-365/app-assure. This is Microsoft’s commitment to make any software that worked on Windows 7 compatible with Windows 10. 

You can see that the above process can be quite daunting as not only you have to search for volunteers to create the best representative sample of your organization, but you also must have a process in place to get feedback from your Pilot users. If you had a similar process in the past with Windows XP to Windows 7 or Windows 7 to Windows 8 upgrades, this is not much different.  

What if one of your Pilot users is on annual leave during the last month of your Pilot phase and that, since you didn’t get any feedback, you start deploying to the general population only to find out that a driver or an application has issues. Luckily, Microsoft provides a tool called Desktop Analytics that will make these kinds of calls for you; it will use Artificial Intelligence to propose a list of systems for your Pilot ring that will be the best selection for a cross section of all the hardware and software in your fleet. It will also use data collected from millions of computers across the world to let you know if, for instance, an app or a driver in your environment have already been flagged – by other Desktop Analytics users in the world – as having issues with the Windows 10 update feature you are targeting.  

Note: Desktop Analytics is a cloud-based service that integrates with Configuration Manager. It provides insight and intelligence for you to make more informed decisions about the update readiness of your Windows clients.  I will discuss Desktop Analytics on a separate blog later in this series but, for the purposes of the current blog, simply be aware that there is service that you can leverage – and which integrates – with Configuration Manager that can help you identify any issues that might arise from the pilot phase of a new Window 10 feature update. 

3. Broad Deployment Ring 

This is the final phase where you deploy to the rest of your fleet.  By this point, after the Insider Preview and the Pilot rings, you should be 99.99% confident that the new Windows 10 feature update: 

• Is compatible with most of your hardware fleet 

• Is compatible with most of your application set 
• Will not break your business-critical systems (if you are deploying to them) 
• Will not be deployed to a specific subset of systems (because they are LTSC systems or because they require special care from the software vendor / hardware manufacturer, etc.) 

Once you have this level of confidence, you need to plan how you will disseminate the update so as not to cause any disruption and have the least impact on your user’s daily work.  Some of the things you must consider are (non-exhaustive list): 

• What Servicing Tool will you use: we’ve established that for large and complex environments, the tool(s) of choice are Microsoft Endpoint Configuration Manager, and potentially combined with Windows Update for Business using Microsoft Intune with Co-Management. 

• Where are the systems located: In terms of networking and geographical location.  You must consider whether you are deploying to 3000 systems in one building or 40 systems at a remote branch office. 
• What caching technology you will use (Peer Cache, BranchCache, Delivery Optimization, Connected Cache): If you deploy the new feature update that could be 2 or 3 Gb in size to 1000 systems all at once, you could be sending 2 or 3 Tb of data over the network and bring it down to a standstill. The alternative is to make use of caching technologies according to the various scenarios related to network location and infrastructure availability. If you are using Configuration Manager, I’m talking here about Distribution Points and their installed OS, available disk space, network location with respect to the targeted systems, etc. If you are using WUfB and Intune, you can use Delivery Optimisation if you have a cluster of systems in a single location to share the OS data amongst themselves rather than having each individual system download their own copy of the feature update.  
• What type of systems are you deploying to: You might want to make sure that there is enough battery left before the feature update starts to install by deploying it as an In-place upgrade Task Sequence. If you are deploying it as an update, Windows 10 is smart enough to let you know that the mobile device doesn’t have enough battery and needs to be plugged in before starting the update installation). What if it is a desktop? Sure, you have tested that it is compatible with the new Windows 10 feature update but what if it doesn’t have enough disk space to download the update before starting the installation.  On the other hand, what if you have a handful of “super-desktops” that are powerful, have plenty of available disk space and connected to a high-performance network? Perhaps you can leverage them as Peer Cache Sources for other systems to pull the update from. 
• Across what type of network will you be deploying: You might have some systems that are constantly connected to a wireless network and you want to minimize the impact of having heaps of data going through that network.  You could schedule for the devices to be brought in and updated on a LAN based network but in some cases that might not be possible; what can you do then?   

How about if you have systems located remotely and there are no servers in that location where they can pull the update from? Pulling 3 Gb of data for 40 systems over the WAN just won’t cut it. This is where you might want to think about using a form of caching technology. 

• What bandwidth control technology can you leverage: With the cumulative update KB4284833 installed on a Windows Server 2016 Distribution Point or with a Windows Server 2019 Distribution Point, you can make use of Windows Low Extra Delay Background Transport (LEDBAT). LEDBAT is a network congestion control feature of Windows Server to help manage background network transfers.  
• Etc.  

The ‘Red’ button approach 

Traditionally organizations used to consider a Windows upgrade as a project where an image is created as a package that is customized in terms of OS settings, application settings, drivers, Microsoft Office settings, etc. After months of testing and approvals, when the package is ready for deployment, the “Green/Go button” is pressed signalling the start of the upgrade for the entire environment. Unfortunately, even more time is used up for communications, scheduling, security access to sensitive locations, etc. All in all, this process used to cost a lot of money as an OS upgrade project would typically take 3 years – sometimes more – on average for a large organization with 50 000 systems. 

The Red button approach is like the production line of a factory where a product is continuously being manufactured and the plant doesn’t stop unless there is a major issue; the “Red button” is pressed to stop production, fix the issue and restart production as soon as possible.  Windows as a Service takes the same approach: You continuously deploy and do not stop unless there is a major issue with the deployment. 

How do you do this you might ask? As I mentioned earlier, by the time you reach the ‘Broad Deployment’ ring, you should have enough confidence that the new Windows 10 feature update is compatible with most of your hardware fleet and application set.  In addition to this, you can also make use of the App Assure program if you have an issue with a specific application. You can contact your hardware manufacturer during the Pilot phase if you have an issue with drivers. For end-user data, this is the age of the cloud people! Use OneDrive, SharePoint, Office 365, … Educate your users not to store company owned data locally! Additionally, remember that this is an update; not a wipe-and-load where the system is completed deleted and the OS is installed from scratch. So, end-user data with all the customised settings should remain after the update is installed. And then there is Desktop Analytics! I’ll discuss this cloud-based service in detail later in Part 7 of the blog series but in short, Desktop Analytics provides you with insights on the readiness of your fleet in terms of software and hardware compatibility with the build of Windows 10 you are targeting to upgrade to. 

Phased Deployments 

Within the pilot and the broad rings, you might segregate your deployment into stages, or phases. You can do this manually and perhaps you might already have a process in place from the pre-Windows 10 days or, you can leverage Configuration Manager’s Phased Deployments to automate this process.  For example, within the Broad Deployment Ring, you can configure multiple phases of deployment depending on what systems you are targeting for each phase. 

Phased Deployments is a great feature of Configuration Manager that’s been available as a full release since Current Branch 1806. You can now pre-program your Windows 10 upgrade as a series of deployments to specific collections.  Each deployment is automatically launched depending on certain conditions and criteria such as:  

• Criteria for success of the previous phase in either percentage or in number of devices that have successfully deployed. 
• Condition for beginning the next phase of deployment depending whether you prefer to start it manually, automatically straight after the end of the previous phase, or defer the automatic start of a phase after a specific number of days after the end of the previous phase. 
• You can choose to let Configuration Manager gradually make the upgrade available over a specific period. For example, suppose you have a collection of 3000 systems, you can configure to have all of them upgraded within say 60 days, or 90 days, etc. This is configurable on a per phase basis. 
• Finally, you can configure the how long you’d like to offer a grace period for the end user to install the upgrade. In other words, the end-user will receive a notification that the upgrade is available for their device and they can choose to defer the installation by say 7 days because that’s what you configured for the grace period. And this is configurable for each deployment phase. 

Phased deployments can be used with Applications, Task Sequences and with Updates.  Hence, if you wish to deploy the new Windows 10 feature update you can set up phased deployments via the “All Windows 10 Updates” menu in the “Software Library” node.   

An alternative is if you create an In-Place upgrade Task Sequence and would like to upgrade your fleet this way (because you have more control on what actions are taken pre and post upgrade), you can create phased deployments for that as well. Personally, I prefer this method as it is also the way Desktop Analytics integrates with Configuration Manager. 

Furthermore, the end-user experience is a little different when you deploy the feature update as a Task Sequence compared to when it is sent as an update. As a task sequence, the end-user system must be managed by Configuration Manager, the upgrade will be available via the Software Centre. As an update, the upgrade will be available via the ‘Update & Security’ panel of the Windows 10 Settings app; it will show just like any other update.  

Delivery Optimization is a cloud service and it is used to optimize the delivery of updates whereas you can use Peer Caching with Task Sequences, Application packages and Update Packages. So, depending on how your network is configured (does your organization permit access to whitelist Delivery Optimization endpoint URLs? Or do you have parts of your network where there is a strict no-Internet access policy? Etc.), you will be more inclined to use 1 technology over another from one network subnet to another.  That is not to say that you cannot use 2 or 3 technologies concurrently, but you must be careful how you configure them if you are using Configuration Manager or Windows Update for Business. I’ll discuss further caching and network bandwidth control later in Part 8 of this blog series.  

Note: If you wish to use Delivery Optimization, you should whitelist the below hostnames for communication between clients and the Delivery Optimization cloud service: *.do.dsp.mp.microsoft.com 

For Delivery Optimization metadata: 

• *.dl.delivery.mp.microsoft.com 
• *emdl.ws.microsoft.com 

For the payloads (optional): 

• *.download.windowsupdate.com 
• *.windowsupdate.com 

Another useful important note is that starting with Windows 10, version 1903, Delivery Optimization uses LEDBAT to relieve congestion on the router from peer-to-peer activity on the LAN. 

Source: https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization#frequently-asked-questions 

Stay tuned for my next blog where I’ll talk about putting all the considerations discussed in this series so far together and more…