Windows 10 Servicing with ConfigMgr Confusion

What Current Branch and Current Branch for Business are not.

A lot has been written and spoken by Microsoft and in the community of Windows 10 as a service and it’s multiple servicing models, commonly called Windows 10 Servicing. This of course includes Current Branch (CB), Current Branch for Business (CBB), and Long Term Servicing Branch (LTSB). LTSB is special servicing branch of Windows 10 but this post is completely non-applicable to it because, well, eww yuck, it’s best to avoid LTSB altogether.

There are a lot of incorrect and misleading statements floating around about CB and CBB in both official Microsoft documentation, unofficial documentation, and community blog posts to name a few sources. Here’s a summary of these statements which are more or less all related and stem from a faulty understanding of what the service model really is or rather what a customer should use it for. Additionally, these statements seem OK on the surface and in some scenarios may actually appear to be true. But, once you peel back the layers, it’s easy to see that they are not and can be bad for your environment if you treat them as true.

CB and CBB are a “state” of a Windows 10 system that can be determined by the value in the registry. NOT

This specifically refers to the Defer Updates and Upgrades setting (which has now become Pause Feature Updates setting in Windows 10 1703). This is completely incorrect and even dangerous, see Why WSUS and SCCM managed clients are reaching out to Microsoft Online for a lot more details on this. To summarize briefly, this setting (and resulting registry value) are meant to control when feature updates are applied from Windows Update for Business (WUfB) only. Even if you are using WUfB, don’t equate setting this value to somehow magically changing what is installed on a system. This setting defines the intent of an administrator for when it will get a feature update in the future. The exact state of the system right now is completely separate from what the value of this setting is.

If you are using System Center Configuration Manager (ConfigMgr) for updates, you should not be setting this value at all (and if you’re not using ConfigMgr, you’re doing it wrong to begin with). Setting this value, as detailed in the post above, enables dual-scan for Windows Update which in turn has multiple nasty side effects. Don’t do it and delete it ASAP if you have.

CB and CBB are different versions of Windows 10. NOT

CB and CBB are in fact, the exact same version of Windows 10. Many folks like to point out that Microsoft releases new media when a version of Windows 10 is declared CBB and so that means it’s a new version. This is [of course] false. The new media is simply a convenience for those building images and/or deploying new systems. The version does not change and a CB system can easily be updated to the latest build by applying the latest cumulative update.

It’s important to note here that version here refers to 1507, 1511, 1607, and now 1703 because these version numbers refer to a locked in feature set.

CB and CBB have different end of life dates. NOT

Because CB and CBB are really the same version of Windows 10, they go end of life at exactly the same time (which is still variable and based upon the initial CB release of the second version after the version in question).

I need to set the Defer Upgrades setting for Windows 10 Servicing to work in ConfigMgr. NOT

Per the theme of this post, this is also false. ConfigMgr doesn’t care about or rely on this setting in any way. The deployment ring criteria page when creating a servicing plan is for update selection and not targeting. Servicing plans are simply Automatic Deployment Rules (ADR) with a few additional settings and like ADRs, the result of evaluating a servicing plan is an Update group, an update deployment on that update group, and the download of the updates (feature updates in this case) to an update package (known as deployment packages if the console even though they have nothing to do with deployments).

So what are CB and CBB really?

CB are the builds of a Windows 10 version at the time that version is initially released up until the time that version is declared ready for business use. Similarly, CBB are the builds of a Windows 10 version from time that version is declared ready for business until the time that version is retired. That’s it, a simple set of builds.

Notice a key word in both statements above: declared. It’s very important to take note of this word because this is truly the difference between CB and CBB. At some point, Microsoft simply says, it’s ready to be used for our business customers. Nothing has truly changed about the version except a bunch of fixes wrapped up in the latest cumulative update. It’s still the same version though.

If you have a system on a CB build, as noted above, to bring it up to CBB (assuming the version has been declared ready for business) all you need to do is apply the latest cumulative update.

Put simply (and stolen from Mr. Niehaus) CBB = CB + latest CU.

So, how do you determine if a system is on a CB or CBB build? By looking at the actual build numbers. This page has those build numbers although it hasn’t been updated for 1703 yet: Windows 10 release information.

And how should you determine if you want to update your systems to CB or wait for CBB? Well that’s up to you. If you need a tracking mechanism and you are using ConfigMgr, you should do what you’ve always done: build and populate collections. What you put in those collections and how you get them there is completely up to you — just don’t use the Defer Updates and Upgrade setting for this.

Intent vs. Actual

One of the sources of the issue here is defining the intent of what build you want your systems on and the actual build those systems are on. Most documentation intermingles these two concepts without distinguishing between the two. If you have a set of systems that you always want on the latest (non-insider) build, i.e., your intent for these systems, you may call or classify those systems as your CB systems. But at some point, those systems will actually be on a CBB build because the next version hasn’t been released yet and the old/current version is already at CBB. So if you continue to call those systems your CB systems, folks might (rightly) assume that you haven’t updated them to the latest cumulative update and are out of support and/or a security risk.

My recommendation: stop using CB and CBB to define intent and only use these terms to define the actual, current build. Use other terms to define your intent.

Note that the ConfigMgr product team foresaw this confusion when creating the user interface for servicing plans and used the terms “release ready” and “business ready”. Unfortunately, this was and is not enough to prevent the confusion.

Documentation Updates

To be clear here, we are working with the content owners at Microsoft to get the documentation corrected (Niall Brady has been fighting the good fight on this for months and months). But it’s more than just a documentation issue at this point as there are a few lingering technical and strategy based issues as well. Windows 10 is moving so fast (as is ConfigMgr) that sometimes things just don’t happy as quickly as we want then to. That’s not an excuse, it’s just a statement of fact.

The ConfigMgr Servicing Dashboard

As confirmed in the comments below by Mr. Niehaus, the Windows 10 Servicing dashboard in ConfigMgr relies on the Defer Upgrade GPO setting (or really the registry value behind this setting) to show CB and CBB systems. These values are collected and accessible in ConfigMgr using the OSBranch attribute of the System Resource class. What this means is that this dashboard and those values, assuming you have the GPO set for your systems, define intent and not the actual, current build of a Windows 10 system. There’s not a lot of value in that IMO particularly if setting this policy breaks software updates on those client systems. If you want to view, audit, or control your intent, then as noted above, use collections just like you always have in ConfigMgr.

24 Comments

  1. Kirk

    A great post as always Jason. PFEs are also giving out advice that A) even with ConfigMgr you need to define ‘defer’ in GPO and B) you’ll be out of support once your build goes CBB if you don’t set the deferral to ‘flag’ it as a CBB PC—obviously not correct.

    Do you know what drives the population of the ‘Windows 10 Rings’ graphic in the servicing dashboard? To my mind it should represent each PC on a CB declared build of Win 10 as ‘release ready’ and each PC on a CBB declared build as ‘business ready’, but this doesn’t seem to be the case. Only when we mistakenly set the deferral through GPO did the ‘business ready’ numbers start to increase (was full ‘CB’ before).

    • Jason

      Great question, specifically, to my knowledge this comes from the OSBranch attribute for the System Resource class. I unfortunately don’t know where it gets the info from — I thought about it while drafting the post but didn’t have an answer. I suspect it comes from the Defer Upgrades setting in the registry but don’t know for sure.

      • Kirk

        Thanks Jason. I guess for now we’ll continue to avoid that GPO and it’s accompanying reg keys. It broke feature update deployments for us. Which is a shame as it made the rings graphic more insightful, removed the creators update advertisement from the Windows Update settings screen on the client, and also removed the ‘go to Microsoft Updates’ button which just lets our users bypass ConfigMgr—all without reg tweaks. We’re yet to find elegant solutions to the 2nd two without impacting the Windows Store and its ability to update the Windows 10 UWP apps.

  2. Michael Niehaus

    Yes, the dashboard is populated by exactly the values you say not to set 🙂 Still, follow that guidance and ignore the dashboard, to avoid problems caused by setting those values in non-WU for Business scenarios (e.g. dual scan).

    Expect some changes soon too that we hope will simplify this whole discussion.

  3. Nick

    It seems that a lot of the confusion on the “Defer” setting seems to be coming from Microsoft itself.
    ConfigMgr seems to use the Defer setting to, at the very least, classify CB vs CBB clients. See https://technet.microsoft.com/itpro/windows/update/waas-manage-updates-configuration-manager

    • Jason

      Yep. See Mike’s comment. I added the documentation section above for this very reason — it’s out of my hands and I’m certainly not privy to details other than I know Microsoft is aware and changes are coming.

  4. Jason, you are right that there are many publications (including Microsoft) that give misleading information.

    I am now ever so more confused about this because with ConfigMgr if I look at the Windows 10 Servicing dashboard most of my computers (all are on 1607) show up as Release Ready, this was concerning because I really wanted them all to be in the Business Ready branch.

    Thinking to myself I somehow need to defer updates for 4+ months (which is CBB), so I found a blog that said we need to change in GPO (Windows Components > Windows Updates > Defer Windows Updates) and set “Select when Feature Updates are received” to Current Branch for Business. I applied this setting.

    Only after I set this setting did I notice that the discovery data in SCCM for my clients started reporting “Operating System Readiness Branch = Defer upgrade”, instead of “Do not defer upgrades”.

    I also noticed that by setting this GPO, the clients were returning SMS_R_System.OSBranch = ‘1’ (CBB) instead of SMS_R_System.OSBranch = ‘0’ (CBB); so my collections based on this query seemed to work now.

    Back in the Windows 10 Dashboard, it also reflected the same as my collections, the clients were reporting as “Business Ready” branch.

    I am now slightly more confused because in your post you state not to use these “defer” settings and that ConfigMgr does not care about it. If I don’t use these settings, the ConfigMgr Dashboard will report all clients as “Release Ready”, meaning they’ll get feature updates as soon as they are available?

    My ultimate goal is to make sure my business computers do not get feature updates as soon as they are made available, instead I want to follow the “CBB” release cycle (4+ months) and get these clients to apply feature updates after they have gone through the “CB” (4 months) cycle.

    By enabling the GPO I described, am I messing up ConfigMgr?

    Sorry for the long post, but I thought it best to put as much information as possible to support my confusion (and frustration) with a lot of the contradicting information on the net.

    • Jason

      I need to change that wording a bit because you are right, as confirmed by Mr. Niehaus, that setting is used for the dashboard. But that’s it.

      “By enabling the GPO I described, am I messing up ConfigMgr?”

      Yes, absolutely. That’s the whole point here. That setting is for WuFB only as noted in the post and has nothing to do with actual ConfigMgr deployment functionality.

    • Hey Jason,

      Thanks for the prompt reply, can’t seem to reply to your comment so I am going to place it under my original. I understand now that by enabling the GPO I am potentially messing up my ConfigMgr which i will go and undo (hopefully there aren’t any residue registry keys that I will need to manually remove).

      So really it should be the ConfigMgr Dashboard that needs to be updated or something, because the whole Business Ready and Release Ready count on the dashboard is what led my down this path.

      • Jason

        Yes the dashboard does need to be updated as does the documentation and the strategy by Microsoft around this particular feature set.

      • Kirk

        Hi Mirza,

        Having been stung by this, I found setting the GPO setting to ‘not configured’ was the correct action and it cleared the reg values.

  5. Simon Bond

    Interesting, wasn’t aware of the dual-scan problem until now and have always read previously that the GPO should be in place for full functionality (ie the Servicing rings screen). I noticed the following page posted as recently as two and half weeks ago on the Microsoft site:
    https://docs.microsoft.com/en-us/sccm/osd/deploy-use/manage-windows-as-a-service

    This also suggests the GPO should be in place. Clearly this needs updating with this caveat.

    • Jason

      I think that page has already been updated and if not, I know they are actively working on updating the documentation.

  6. Chellye

    Hi Jason –

    We use ConfigMgr and SUP to patch and update our systems. Our team is controlling the updates that go out. With that being said we have disabled the Creators Update notice on the Widows 10 clients (we have a mix of 1511 and 1607 versions at the moment) and we do not allow them to go to MS for updates. We have set everyone to CBB by using a configuration baseline that sets the registry keys for deferupgrade and branchreadinesslevel. This allows the dashboard for servicing to show that all of our clients (1511 and 1607) are Business Ready. I am managing our deployment rings based off collections we have defined for IT staff and Early “pilot” Business users. These groups will be the first to receive the 1703 update so they are technically our CB rings. Once 1703 is declared business ready or current branch for business our 4th and 5th deployment rings will be targeted, again the rings are based off collections we have defined based on users and departments. Can you clarify that by us setting everyone to CBB we are not causing any issues with dual scanning or SUP patching?

    Thanks.

    • Jason

      As stated above, you’ve now broken Windows Updates on your Windows 10 systems as well as opened yourself up to premature uncontrolled upgrades due to dual-scan. Please read the Why WSUS and SCCM managed clients are reaching out to Microsoft Online post linked above.

  7. Sandy

    so if we are using ConfigMgr to manages updates/upgrades, we should not use GPO to set anything related the defer updates, if we touch that setting, it will use WUfb, and machine will do dual-scan, one scan from ConfigMgr, another scan from WUfb, and this is not good to use dual-scan. Do I unstand corretly?

    Why Microsoft document about how to intergrate WUfb with WSUS/ConfigMgr? It seems this is not an accident machine when to internet get updates even though they are under control by WSUS or ConfigMgr, it looks more like by designed you can do it both, depends on what updates do you want to get, example third party drivers update from WUfb, Patch Tuesday updates from WSUS/ConfigMgr. (That’s how I understood this MS article)
    https://technet.microsoft.com/en-us/itpro/windows/update/waas-integrate-wufb

    If it is totally a bad idea use WUfb and WSUS/ConfigMgr in the sametime, perhaps MS should add more notes to their article?

    • Jason

      Correct and I concur. As noted in the post, Microsoft is aware of the inconsistencies in their documentation and they are working to correct them. I’m not really sure when or how things went so wrong with the documentation and functionality. I suspect things changed from Win 10 1507 to 1511 and even to 1607 and the documentation didn’t keep up and/or there wasn’t proper testing and communication of what should be happening.

  8. sam

    About time someone did a good job of explaining this in layman terms. I’ve been trying to explain this to management and they kept thinking i was incorrect. Will be great to have this as a reference. Also when you were in Detroit this is why i said the Service Profiles are a nightmare. Not so much the profiles that suck, its just all of it combined. The wording, the amount of data, etc. Perhaps some people are fine with their O/Ss being upgraded automatically and the 3.8 gigs that comes along with it, but I prefer to just leverage the IPU TS. I’m generally not a control freak, but when it comes to this much data and upgrading the OS the extra granularity that IPU gives you is a nice luxury.
    Excellent write up!

  9. Jean-Sebastien Frenette

    I’ve read everything, as well as the other post. I understand the dual-scan and saw why in the other article it says to disable the registry. BUT, it stated it’s to prevent client to connect to Microsoft Update using DO or to update Windows Store Apps since SCCM/WSUS can’t update Apps for now.

    You are saying that Windows update are now broken, but I have this scenario. In my Windows 10 Dashboard, the number of client in Release Ready and Business Ready change every day, though there’s only 1 GPO, deferFeatureUpdate=0 and CBB branch. This mean everyone should be in Business Ready, One day I have 350 RR and 43 BR, the oter it’s 300 BR, 90 RR.

    Now, while I don’t really care about the dashboard, since it take it configuration from the registry, it should show all my devices as Business Ready. But that’s not what I see, even if they have the registry.

    Aside all of that, when Windows 10 was release, I was showed from Microsoft various presentation on Windows 10 and it’s new servicing mode. Then come a graph showing CB, CBB and LTSB support cycle.

    (also talked here: https://technet.microsoft.com/en-us/itpro/windows/update/waas-overview)

    Current Branch have a support cycle up until new Current Branch release. a 60-days grace period exist. After that, no Quality Updates are available anymore. Only the latest version of CB build are supported
    “Organizations that use Windows Server Update Services (WSUS), Microsoft System Center Configuration Manager, or Windows Update for Business, however, can defer CB feature updates to selective devices by withholding their approval and deployment. In this scenario, the content available for CB will be available but not necessarily immediately mandatory, depending on the policy of the management system. Only one CB build of Windows is supported at a time, so those clients not on the most current build will not receive quality updates (after a 60 day grace period) until the most current feature update has been installed.”

    As for Current Branche for Business, the support is for N-1, meaning that latest version and previous version is supported. When a new version come out, the N-2 version become out of support after a 60-days of grace. Each CBB build are supported for a minimum of 18 months.
    “Microsoft will support two CBB builds at a time, plus a 60 day grace period. Each feature update release will be supported and updated for a minimum of 18 months.”

    It is true there isn’t a “CBB Build”, it’s the samething release 4 months later. The link I gave earlier does state that in the CBB section:
    “Basically, CBB is a configuration state, meaning that if a computer has the Defer Updates and Upgrades flag enabled—either through Group Policy, a mobile device management product like Microsoft Intune, or manually on the client—it’s considered to be in the CBB servicing branch. The benefit of tying this servicing model and CB to a configuration state rather than a SKU is that they are easily interchangeable. If an organization accidentally selects CBB on a machine that doesn’t need delayed updates, it’s simple to change it back. ”

    Then there’s LTSB, which is an entire different sku with a support of minimum 10 years.

    Having all this information, if I open a call to microsoft right now using 1511 that is on CB, do I get support or not? Yes I’m a business, but I’m not on the latest CB build on a computer configured for CB. Technically no since I’m in the “out of support” group. But what if I’m CBB configured? That mean I’m on the N-1 version, thus still supported (and under the 18 months). Will they check the registry to see if I’m CBB?

    Microsoft told us many time to check our branch for support because no support will be given on a CB not on latest version, and that’s in person with rep.

    • Jason

      Being in a servicing branch is not the same thing as having a specific version or build installed and that’s where things go wrong; equating the two is just not accurate and so using the same terms for each is not only confusing but ultimately inaccurate. That’s the whole point of my post — or at least one of two main points with the other being don’t use the defer upgrade policy or registry values if you are using ConfigMgr. You’ve confirmed that by all that you’ve written above — your comments are all accurate to the best of knowledge, but potentially confusing as confusing can be.

      This is also highlighted by your statement above: “if I open a call to microsoft right now using 1511 that is on CB”. Do you mean that deferred upgrades are disabled or that the system is on a build of 1511 prior to the declaration and release of the CBB build? There is no way to tell from the context.

      Another point of confusion here that I didn’t explicitly point out but definitely made sure that I got right was “version” vs. “build”. They are two different things. Versions are 1507, 1511, 1607, and 1703. Thus, your last statement should read “no support will be given on a CB not on latest **build**”. This only adds to the terminology quagmire.

      I will change my one heading above from “end of support” to “end of life” as those are two different things from a planning perspective. My intent wasn’t to say that builds themselves don’t have some end of support, it was that the all builds of a version go end of life at the same time. As for consumer support, that’s a good point but honestly, not one that I care about or would ever blog about.

      Finally, for your dashboard, if you have different versions of Windows 10 in your Enterprise, then having deferupgrade=0 will give you different results based upon which version the client is on. All Win 10 1703 systems are RR right now regardless of that setting whereas all 1607 clients are BR regardless of that setting — I think at least. Once again, more confusion over the terms. Way more complicated than it should be.

Leave a Comment