- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
A Windows update breaks a server. This is not the start of a joke but a repeating piece of news we see every few months. When it isn't a Windows update, it's some application deployment or update causing issues. Those who do not update are in a worse situation—just ask anyone infected with WannaCry. When stuck between this rock and that hard place, what options do we have? Among your better options are SCCM and Group Policy update rings.
SCCM and Group Policy update rings can make your deployments easier and safer. They ensure proper testing and also timely deployment of patches. You are probably familiar with update rings already, often called servicing rings or servicing plans. Microsoft uses the concept to deploy new Windows 10 versions.
Those eager for new updates get the builds first. Consumers receive the refined builds next. Finally, businesses receive stable builds. Implementing internal update rings is fairly easy. To get it right the first time, let's accurately map out our update rings.
Microsoft's implementation of update rings with Windows 10
Mapping out application and Windows update rings
Start building your own internal update ring structure by mapping out your device structure. Get an accurate device count for your organization. SCCM client counts, PowerShell Get-ADComputer queries, or tools like OldCmp can provide this data. This count should include a total along with the individual computer names.
Divide this data into two subsets: one for servers and one for clients. You will likely want tighter update schedules for your servers as they have shorter maintenance windows. It will be easier later by having a separate ring build for them now.
Think about the negative impact a bad update would have on your devices, and group each subset by that impact. Divide each subset into at least two, preferably three, groups.
For example, you might divide your servers into three groups that look like this:
- Server Group 1 (Low Impact): Least critical servers, servers used for test environments, passive servers used in active/passive high availability setups. This group may range from 5% to 25% of the total group and receives updates first.
- Server Group 2 (Medium Impact): Run-of-the-mill/ordinary servers. These provide non-critical services, or you can easily restore them in the event of an outage. This group may range from 50% to 90% of the total group. It will normally be the largest of the three groups. Servers in this group receive updates next.
- Server Group 3 (High Impact): Mission-critical servers make up this last group. If one of these servers is offline, it would severely interrupt or stop whole business operations. This group is the inverse of Group 1 and may contain between 5% and 25% of the total group. This group receives updates last.
Although I used the term servers above, this same methodology applies to server groups or application groups. For example, you may put the domain controller (DC) with the primary domain controller (PDC) emulator role in Server Group 3 and all other DCs in Server Group 2. You may also find that you need just two groups or that you may need groups between ordinary servers and mission-critical servers.
Keep in mind differences that may cause an update to break a server. If all of your mission-critical servers run 2012R2 but your least critical servers run 2016, you need to rework your groups. This is also true for hardware; ensure there's representation for most or all hardware types across your update groups.
Client grouping takes place in a similar manner. Your initial update group may contain machines not used often. You can pull this information from the lastLogonTimestamp Active Directory (AD) attribute or from the heartbeat log in SCCM. Below is a sample PowerShell script:
$Date = (Get-Date).AddDays(-21)
Get-ADComputer -Filter {PasswordLastSet -le $Date} -Properties passwordLastSet ‑ResultSetSize $null | Foreach { Add-ADGroupMember -identity "Clients - Low Impact" -Members $_.SamAccountName }The initial group may also contain computers from tech-savvy departments or those belonging to attentive users. These users are likely to spot problems sooner. With any setup, ensure that your first group contains a representation of your overall environment. Above all, design the setup that fits your environment.
Creating update ring security groups and deployments
As stated at the beginning of this guide, update rings are a methodology for managing updates and reducing risk. They are not a fancy piece of technology that is difficult and expensive to implement.
After mapping out your groups, create an organizational unit (OU) named something like Software Updates. In this OU, create a security group for each mapped group detailed in the section above. It might look something like this:
This environment groups clients into just two update ring subsets
These groups would link to collections in SCCM or to your other management tools. However, you set up the groups, aim for universal use. These should apply to OS, hardware, and application updates. For example, you might use SCCM for Windows Updates. You would create an automatic deployment rule (ADR) for each group and stagger the availability and deadline times.
Your low-impact group may receive updates the day of release, medium a week after, and high within two weeks. You can adjust that schedule to fit your environment, but be wary of extending important updates too far into the future. WannaCry taught us that lesson as well.
Finally, configure these groups to be as self-sufficient as possible. Use tools with scheduling, like ADRs, to automate deployment times. Use PowerShell or a similar tool to turn those groups into shadow groups. For example, your low-impact client group could derive from an AD query that looks at OU membership plus 21 days of inactivity.
Subscribe to 4sysops newsletter!
A proper implementation of update rings takes a lot of up-front planning. After mapping them though, you can install future updates with less risk in a timely manner.
Thank you for interesting article. This is a good idea to create groups for specific rings. But in some cases it’s dificult to keep such gruops up to date. I’m trying to create rings based on User Device Affinity (UDA) information. For example Devices used by Users who are members of group “Executives” move to collection “High impact”. Such groups for users usually up to date, because those groups people use for grant access to resources.
Pavel – that is a good idea! Once you get your collections created, post the collection query here! I would like to see it.
It would be like this:
select distinct SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System JOIN SMS_UserMachineRelationship ON SMS_R_System.ResourceID=SMS_UserMachineRelationship.ResourceID JOIN SMS_R_User ON SMS_UserMachineRelationship.UniqueUserName=SMS_R_User.UniqueUserName WHERE SMS_UserMachineRelationship.Types=1 AND SMS_UserMachineRelationship.IsActive=1 AND SMS_R_User.UserGroupName=”Domain\\UsersGroup”
For my environment it works. But! We should use it carefull and use limiting collections to ensure the end result contains the systems you expect.
This is awesome!! Thank you for posting your query!