Microsoft Digital shares its strategy for managing deployment rings inside the company.

Like many businesses transitioning to the cloud, Microsoft’s shift to Windows as a service meant that we had to rethink the way we deploy updates. This transition required us to make process changes, but it’s also offered opportunities to fine-tune our approach to deployments overall. We’ve utilized deployment rings, and as a result, it has never been easier for us to deploy Windows updates smoothly and invisibly.

“Deployment rings are making a magical difference for us,” says Microsoft Program Manager Brent Barnett.

While most enterprises understand that they need to break up large-scale deployments into more manageable rings, waves, or phases, determining how to delineate those waves is complicated. Here’s a look into how we introduced deployment rings and even more specific waves to our process around Windows updates at Microsoft.

Our original decision to break up deployments into multiple rings was informed by three main goals:

• Validating updates on a smaller subset of devices to ensure application compatibility
• Minimizing the impact on our network (delivery optimization is also effective)
• Mitigating risk to prevent overloading support teams

First, a small team within Microsoft Digital is responsible for running Windows’ daily engineering builds. This provides early insights into issues and helps us understand when a build is ready for deployment to larger groups. We then expand the deployment to a group of approximately 1,000 users who have volunteered to pilot prerelease builds. This group helps validate features, policies, and applications internally, guiding us into the broad deployment phase that will ultimately reach approximately 200,000 devices.

When deployments need to reach broad communities of users across a huge number of devices, it’s sometimes necessary to create additional sub-rings, called deployment waves, within a broad deployment ring. Within the broad deployment ring we create six smaller waves of 30,000 devices each. When delineating waves within the broad deployment ring, we took into consideration the need to comply with these business rules:

• No deployments to sales and finance devices near the end of the fiscal year
• No deployments to specific device models with driver issues
• Prioritize deployments to specific device models to address security vulnerabilities
• Prioritize deployments to devices with an associated user, to enable direct email communications
• Prioritize deployments to executives

We manage these business rules with a deployment solution built using SQL Server and a simple C# application. This solution provides the control we need to manage deployments in a way that minimizes the impact on users. The solution helps us identify and manage waves by:

• Defining the scope. Target devices in a specific Active Directory Organizational Unit (OU), devices in a specific build range, or devices running specific SKUs or language packs.
• Defining exclusions. We maintain multiple security groups with devices that are excluded from deployment; the solution updates the database daily with those included in the security groups.
• Defining business rules. We assign points for each business rule we need to comply with based on relative priority. If we want to deprioritize a group of devices without excluding them completely from the deployment, we can apply negative points to a rule.
• Defining number of waves and maximum number of devices per wave. We typically break broad deployments into four to six deployment waves of 30,000 to 40,000 devices each and associate a specific security group to each one.

The solution first imports updated device and user data on a daily basis to ensure that we’re making decisions based on the most recent data available. Every device in scope for the deployment is scored on applicable business rules through the associated points system, and is then assigned to a wave based on its points total. Devices with the most points are sorted into earlier waves, and devices with fewer points end up in later waves. We lock each wave when it’s ready for a deployment, preventing its membership from changing further while those daily updates continue.

Previously we deployed feature updates using System Center Configuration Manager Operating System Deployment (OSD). But with the 1809 Windows release, we moved to Windows Update for Business (WUfB). In both cases we use security groups for each wave, converting those groups to collections if we’re using OSD, or applying deferral policies to them if using WUfB.

Finally, the solution generates a list of devices in the wave with associated users. This allows us to send users information about the update in direct email communications, detailing when the update will occur and how to defer the update if there is a valid business reason to do so. As the deployment progresses through its broader rings, the ability to add or remove business rules, exclusion groups, and specific waves allows us to respond to issues faster. That minimizes the impact on productivity.

There are multiple options for deploying Windows updates. This allows enterprises to base decisions on their risk tolerance and on the builds that are available to them. The Windows Insider Program helps enterprise customers at the proof-of-concept stage. Once feature updates are publicly released, enterprises can expand to larger pilot groups within their organizations to start validating applications and hardware. Once the deployment is issue-free, or once they have identified and understood all potential issues, enterprises can expand to broad deployment.

For enterprise customers, Desktop Analytics allows for the creation of a deployment plan that identifies which devices need to be updated. It automatically recommends a pilot group to maximize application and device coverage. The solution is integrated with Configuration Manager to streamline deployments. After deploying to the pilot group, Desktop Analytics helps IT teams identify issues and exclude relevant devices from the broader deployment until those issues are addressed. “This creates the confidence necessary to move the deployment to larger groups of devices,” says Barnett.