Previous blogs in this series:
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:
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:
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).
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:
Note: If you come across an issue with an application during your Pilot phase, try to immediately remediate it by:
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.
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:
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):
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.
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.
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:
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:
For the payloads (optional):
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.
Stay tuned for my next blog where I’ll talk about putting all the considerations discussed in this series so far together and more…