In my last post, I discussed deployment rings and the reason they are the hidden gem of Windows as a service. I outlined why they are a critical component in the evolution to the modern workplace, how they can help your deployment strategies evolve in line with other business processes, and how they can enable you as an IT pro to become more agile and responsive.
Today, I’d like to talk about some of the tactical considerations you should look at when creating deployment rings, and how you can use deployment rings to accelerate your ability to more easily and effectively service Windows 10 devices across your organization. While it would be impossible to construct a “one size fits all” plan, let’s dig into some of the specific and practical questions that can help you move forward quickly and efficiently.
One of the first questions I usually receive when discussing deployment rings is, “How many rings should we have?” While this is critical, it’s also where I usually take a step back to understand context, posing a few questions of my own:
As we progress, each question becomes less straightforward and more subjective. This is the reason there is no hard-and-fast guide to choosing the number of rings. It’s also why a company with 10,000 PCs may have 6-8 rings while a company with 100,000 may only have 4-6 rings, or vice versa!
To put it simply, ring count is not based on the size of the environment alone. In the right environment, you may successfully deliver 25,000 updates per month, while other environments may only get several hundred. In general, however, a minimum of three rings is usually needed to see the benefits.
Every business has its own complexities and risk tolerance. Whether it’s seasonal challenges like those found in retail, or highly regulated industries, or dealing with bandwidth challenges, you will have to adjust your rings to meet your individual needs. This is not unlike how you adjust your initial Windows rollouts today, but potentially adds more data-driven decision points and drives toward validation and the most optimal experience as a continual process.
It’s important to keep in mind that your deployment ring strategy is not something that will remain static. It can (and should) change based on business goals, risk profile, learnings and even user demand. You may also need to alter your strategy, depending on which solution you use to manage your deployments and updates, whether it be Windows Update for Business (WUfB) or System Center Configuration Manager (ConfigMgr) and Windows Server Update Services (WSUS), Microsoft Intune or other management solution. The trick is to gain deployment acceleration quickly while successfully managing risk.
Let’s walk through a hypothetical example of a company with 10,000 devices. As we do so, remember the north star: staying current to help improve security and empower end user productivity.
Let’s start by defining our checks and balances, which we will use to measure our decisions:
Next let’s look at users and machines, grouping and naming them for reference. Note, groupings and rings are not the same things; instead, groupings are high-level logical units for common generalities and rough timing.
For this example, I’ll use the following four general groupings:
It’s now time to formulate the criteria from which we’ll make the decisions on how to structure the rings for our sample company.
In the flow below, we weigh each decision against our experience goals and criteria, risk tolerance, and any analytics or insights available. From there, we choose the appropriate ring or accept the user’s desire to opt in to early technology adoption. As your process matures, you may also introduce opt-out for early releases and some logic to move a user to a different ring based on their business need.
We want to create statistically relevant rings, which would include:
By applying our decision criteria (balanced with statistical relevance), then evaluating and adjusting our strategy as needed to mitigate risk, we have arrived at the following example for ring definitions:
The breakdown for our user base across various deployment rings would equate to something like the following:
While we started with our four logical groupings, due to logistics and other considerations, we required more than four deployment rings to help mitigate risk and provide the best overall experience. We also used various technologies to provide the best user experience for each situation, such as Delivery Optimization for our mobile clients and Configuration Manager peer caching for our lower bandwidth sites, thereby avoiding unnecessary work attempting to make one method work in all cases.
The total deployment time for our 10,000 seats is roughly 12-14 weeks. In our ring definitions, settings like cache retention will ensure we have locally cached bits available for each ring, and that we are managing the rollback period to consider things like app usage statistics. We would also build peer support resources, or “champions,” to minimize potential help desk calls. Champions are also critical to gaining quick and relevant feedback.
In the deployment example above, if we put this in the context of the Windows 10, version 1903 release (May 21, 2019) and the current date as of this blog (July 10, 2019), this is how our deployment ring strategy would be applied:
Notice that our corporate standard is not about version, it’s based on time. If you ask where we are three weeks from now, you would see the numbers adjust accordingly. However, the environment is current within our planned window of 12-14 weeks, delivering new technology faster while leveraging the insights from early rings to mitigate risk.
Your deployment timeline might be more or less aggressive than the example outlined in this blog post. It is not uncommon, for example, to see an initial rollout on a rolling 6-month cycle, and see that strategy later tighten up to a 2-3 month cycle over several releases as the process matures. At Microsoft, our IT organization has a schedule that evolved from about one year (to roll out a feature update to approximately 250,000 machines) to just nine weeks. Our deployment window decreased over time and so can yours.
The final piece of the puzzle is to proactively communicate with your all of your users throughout the process. It’s critical to ingest all the feedback you can and revise your communications as you broaden your adoption and repeat the process. If you combine this with data-driven insights, you can minimize risk and maximize velocity in your rollout.
To learn more about how we achieved a faster deployment cycle at Microsoft and download assets, including customizable timelines and communications to help you provide a seamless Windows 10 rollout, check out the resources available from Microsoft IT Showcase.
Stay tuned for my next post, where I’ll discuss moving to Windows Update for Business. In the meantime, to learn more about Windows as a service, check out the Windows as a service gateway on Docs.
Sean McLaren is a PM covering customers in the South Central United States and specializing in Windows deployments. With over 20 years of IT experience, he works directly with Microsoft’s enterprise commercial customers across many industries helping them with strategy and technical guidance around modernizing client endpoint deployment, management and security. In his own words, “I have the privilege to help our customers enable their digital transformation goals by delivering modern devices and the latest technology to their users while lowering costs and streamlining their operations. I also get to take feedback and learnings to our engineering teams and help make our products better.”
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.