IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hey Everybody! I am Jose Blasac, a Microsoft Premier Field Engineer, here with my first post on the world famous ASK PFE Platforms blog! I am super excited!
I spend a lot of time working with System Center Configuration Manager and Windows 10. If you have done any work with Config Manager and Windows 10 Servicing, you will have noticed some of the pre-requisites like Heartbeat Discovery and WaaS Deferral GPOs (More on this later).
By default, all Windows 10 systems are discovered as CB or Current Branch. (If you are not familiar with WaaS Concepts like CB or CBB, head over to our WaaS Quick Start Guide)
Starting with Config Manager 1511 a pair of new attributes have been added to the DDR or the Heartbeat Data Discovery Record of Config Manager Clients. For our purposes, we are concerned with the OS Readiness Branch attribute as highlighted below.
The OS Readiness Branch properties of a Computer Object can display the following values:
- Do not defer upgrades = CB
- Defer Upgrades = CBB
- LTSB = LTSB
So where does the Client discover this information?
As I stated earlier, these attributes are now part of the DDR that is inventoried on Clients and copied up to the Management Point for Processing by the Primary Site. We can trace these activities on the client side via ConfigMgr Log files. The Client logs Discovery actions in the InventoryAgent.log found in %windir%\CCM\Logs folder.
After manually initiating a DDR cycle let’s follow the action. If we drill down through the InventoryAgent.log to see what items were discovered and inventoried, we can see the following WMI query with a particular property of Interest!
So, what is the OSBranch property all about and what values are we potentially looking for? If we launch the good old Wbemtest utility, we can test this WMI query for ourselves!
Right Click on Start, Run, Type in Wbemtest and Launch the Utility. Hit Connect and Attach to the Root\ccm\invagt namespace. We can take part of the query above to peek into the OSBranch Property.
As you can see above we have an integer value of 1. This system is considered a CBB client.
The OSBranch Property has the following possible integer values:
- Current Branch or CB = 0
- Current Branch for Business or CBB = 1
- Long Term Servicing Branch or LTSB = 2
As we continue to piece this together, what is the Client Discovery routine looking for to decide what value to set the OSBranch Property to? Now I happened to have read the documentation on configuring Windows Update for Business which is here.
So technically I already know what Registry Keys need to be set. (I am doing all my testing in this blog on Windows 10 1607)
If we scroll down the page to the section titled “Configure Devices for Current Branch (CB) or Current Branch for Business (CBB) we can see the Release branch policies and how to configure them for either Windows 10 1607 or Windows 10 1511. Here is a snippet of that Table.
With that said we still have the ability to trace this for ourselves and observe the system behavior. Let’s resort to one of my favorites tools, Process Monitor. Chances are you have used this in the past but just in case you can go over to www.sysinternals.com and grab the it!
Prior to initiating a DDR discovery cycle I will launch Process Monitor. The DDR cycle runs quickly so I will pause the trace after approx. 30 seconds. Then I begin to search for key terms. In this case I used to the term “Branch”.
Bingo!! The first hit takes us right to the relevant Registry key.
We can see the RegQuery being performed by the WMI Provider host process but let’s dig deeper and see who is initiating the actions.
Double click on the Highlighted Line item and pull up the Event Properties Dialog box.
Let’s go to the Stack tab to view this Threads Stack activity. Without getting too Nerdy we can see some Config Manager activity once we walk up the Stack.
The ddrprov.dll belongs to the Config Manager Client DDR Provider as detailed below.
Phewww, ok so now what? Knowing how Config Manager Discovers and identifies WaaS in Windows 10 can be very helpful once we start to play with things like Windows 10 Servicing Plans or trying to make sense of the Servicing Dashboard. Etc
We can create collections based on some of these Attributes and create Deployment ‘Rings’. For example, you could create collections based on OS Build or OS Readiness Branch.
Some of the possible integer values when setting up your Query.
We could also run SQL reports and queries against the Config Manager database to identify systems. The SQL view of interest is v_R_System. This contains the attributes like OS Build and OS Readiness Branch.
Here is an example query and result:
As you can see the Branch value is also an integer in the Database. As we should have all mastered by now, Current Branch or CB is 0 and so on and on….
Well, I hope you have enjoyed this little exercise on identifying WaaS systems in your environment using System Center Configuration Manager.
Till next time!!