Our Services & Products
About Us
Get in touch
Privacy

Search for:

Our Services & Products
About Us
Get in touch
Privacy

Category: Uncategorised

SCCM Monthly Software Update Compliance Reporting

Reporting on software update compliance of workstation devices in SCCM brings with it varying levels of complexities. But if you break it all down and…

Topaz George 6 August 2020

48 Comments

Send emails from within a running SCCM Task sequence

Upgrading your enterprise to Windows 10? Send emails to yourself and/or the administrator as proof of a successful deployment. Deployment compliance is the key to…

Topaz George 11 April 2020

0 Comments

Windows 10 Feature deployment with System Center Configuration Manager

According to Microsoft. A deployment ring is a defined as follows. “Deployment rings in Windows 10 are like the deployment groups most organizations constructed for…

Topaz George 11 April 2020

0 Comments

Forum Description

According to Microsoft. A deployment ring is a defined as follows.

“Deployment rings in Windows 10 are like the deployment groups most organizations constructed for previous major revision upgrades. They are simply a method by which organizations fit two separate machines into a deployment timeline.

With Windows 10, you construct deployment rings a bit differently in each servicing tool, but the concepts remain the same. Each deployment ring should reduce the risk of issues derived from the deployment of the feature updates by gradually deploying the update to entire departments. As previously mentioned, consider including a portion of each department’s employees in several deployment rings.”

This blog describes osd365’s recommended approach to any Windows 10 feature updates using Microsoft System Center Configuration Manager (SCCM). As it is expected that the feature updates are released at least twice a year (in March and September) by Microsoft, it would be logical to have policies and processes in place to enable a smoother and more efficient deployment of Windows 10 features.

If you want to deploy Windows 10 feature updates the osd365 way. You will start to think about the deployment from 3 different perspectives.

A domain user.
A domain computer.
A relationship between the domain user and computer via a Primary device assignment.

Domain User

A domain user as the name suggest is a user account in your domain. A user will have the following attributes and more.

A first name.
A last name.
A physical address.
An email.
Department and division details.
A job role.

and a lot more than the above listed attributes. These attributes will help us plan our deployment. The following statement will not make ANY sense right now. But read it without leaning much into it. It will all clear up when all the pieces of the puzzle are fitted.

When we talk about ‘Domain User’ we are focusing on users in Active Directory not Active Directory users discovered and added into the SCCM database.

What are the advantages of these user attributes?

Let’s face it. It is easier (if possible) to deploy to the User. If you agree with the below deployment philosophy, continue reading. Alternatively if you want to deploy your Windows 10 servicing updates to a ‘Device’, continue reading too because there is a twist to this story.

“Schedule the deployment for the user but deploy to the machine.”

It is easier to schedule the deployment for the user because of the user attributes (physical address, email address, department etc.).

The attributes will help us build a crucial component of the Windows 10 servicing model called the “Application Personas”. We’ll talk about “Application Personas” in another blog.

Furthermore Project managers and their teams can quickly whip up deployment schedules based on Users and their attributes.

Domain Computer

A ‘domain computer’ is what we want to service with the latest Windows 10 feature updates.

The deployment plan or the project team will NOT know about the ‘Domain computers’; they focus on the ‘Domain user’.

The following statement will not make ANY sense right now. But read it without leaning much into it. It will all clear up when all the pieces of the puzzle are fitted.

When we talk about ‘Domain Computers’ we are focusing on Computers discovered and added into the SCCM database and NOT computers in Active Directory.

Confused. Good. Remember what we said. “Schedule the deployment for the user but deploy to the machine.”. Keep reading…

The relationship: Users and computers.

User device affinity in System Center Configuration Manager [SCCM] associates a user with one or more devices. This behavior can eliminate the need to know the names of a device associated to a ‘Domain User’.

But NOTE this point. We will not be deploying Windows 10 feature update to the ‘Domain User’. What we are doing here is just making a relationship.

This step is crucial to the success of the Windows 10 feature update servicing process. Organizationally a lot of our customers found this step challenging; mainly our customers with upward of 40,000 seats. If you get this step right, there is a greater probability for a successful deployment. Take time and make this relationship work.

Create Active Directory Groups

Create 4 Active Directory groups that will hold ‘Active Directory users’ that will be the focus of the Windows 10 feature servicing update.

Note: Be mindful of the fact that the Window 10 servicing update will NOT be deployed to Active Directory users but to “SCCM Machine Objects”.

OSD365 Collection Rings for Feature Deployment

Create SCCM device collections

Create 4 device collections in SCCM. Yes. ‘Device Collections’. The device membership will be added using a ‘Query Rule’.

Window 10 feature servicing updates will be deployed to these colllections.

Each of the below collections will be ‘Query’ linked to their corresponding Active Directory group created in above step.

SCCM Collection targeted by Feature Update

Lets talk about the ‘Query Rule’.

The ‘Query Rule’ translates ‘Users’ to ‘Computers’. The ‘Query Rule’ queries the Active Directory groups created in the above section and identifies a list of Users.

It then identifies the ‘Primary Device’ associated with those ‘Users’ and adds them to the SCCM Collection.

If a User has more than 1 primary device; it adds all of the Primary Devices to the SCCM Collection (itself).

The ‘Project team’ will add ‘Users’ to the Active Directory group; the SCCM collection corresponding to the AD group will be automatically identify and add Primary devices corresponding to those users.

Create a query rule for each of the above collections. These queries populate the collections with Primary devices of the users listed in each of the corresponding AD groups.

SELECT 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.Name=SMS_UserMachineRelationship.MachineResourceName
JOIN SMS_R_User ON SMS_UserMachineRelationship.UniqueUserName=SMS_R_User.UniqueUserName
WHERE SMS_R_User.UserName in (select distinct SMS_R_User.UserName from SMS_R_User where SMS_R_User.SecurityGroupName like “<your-domain-name>\fnWindows10ServicingRing0“)

The above query will read all users from the Active Directory group ‘fnWindows10ServicingRing0‘, identify their primary devices(s) and add them to the Collection ‘Windows 10 Upgrade – Ring 0‘ which has the above query rule.

Deploy Windows 10 feature servicing updates

This is the final step. You could either deploy the Windows 10 servicing update as a staged deployment or as sperate deployments to each of the Device Collections created in the previous steps.

Post any questions in the comments below.