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.
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).
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.
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.
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.
Thank you for confirming Mike!
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
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.
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.
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.
Yes the dashboard does need to be updated as does the documentation and the strategy by Microsoft around this particular feature set.
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.
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.
I think that page has already been updated and if not, I know they are actively working on updating the documentation.
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.
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.
Thanks Jason. Noted and will address.
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?
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.
Noticed that in ConfigMgr TP1703, there is new client setting in Software Update “Manange Windows 10 updates with Wndows Update for Business”, default option is “NO”, but can change to “YES”. So I am confuse now what does that setting do, as same as in GPO? No sure how many IT people can catch up these fast changes every day, in every org. One check box or one setting can make a big different to workstation, and those documents are just confusing and they might even conflict each other. Like one article guide you how to do something, then another one tells you do not do that.. Not everyone have 24 hours time to follow those changes.. What is the point of using “OSBranch” 1 or 0 to make query to define what windows 10 we are using..isn’t it more clear query OS build version..
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!
Thank You
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:
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.
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.
Just a follow-up, nothing changed in my computers, and now I have 234 RR and 291 BR. I can wait and see tomorrow totally different number. I might have a problem somewhere else, but the dashboard surely doesn’t really on version, but on branchreadinesslevel/deferfeatureupdate.
Great post. Thanks Jason.
Regarding the Defer Upgrades setting and the statement that “ConfigMgr doesn’t care about or rely on this setting in any way”… ConfigMgr actually does care because if Defer Upgrades is checked on a 1607 Win10 client, the 1703 feature update is not applicable in my environment. As soon as I uncheck the box, the 1703 update is applicable on the client. So it appears the WUA is looking at this setting when it scans the W10 workstation to see if a feature update is available. All the more reason to make sure Defer Upgrades is unchecked and use collections in SCCM to target Win10 machines.
Also, agree the Windows Servicing dashboard in the SCCM console provides no value since the Release Ready and Business Ready values are based on the Defer Upgrades checkbox.
Finally, since 1703 was released, my 1511 client aren’t able to update to 1607 or 1703. Not sure how the WUA is supposed to evaluate those 2 possible updates on 1511 machines. In reality, I should be able to install either 1607 which is CBB or 1703 which is currently CB. Instead, neither update is available and the windowsupdate.log has this error – Two Swap OSUpgrades are found, Update1 = {7F016D4C-C9A6-4699-A7DA-3D86EF81843F}.201, Update2 = {83695761-2AAC-4890-B68E-94B01BAC720C}.
Because of this, using a Task Sequence to do the in place upgrade seems to be the most attractive at this point. There are pros and cons but it gives me the most control and flexibility.
Kind of sort of. What you are seeing is a result of the WUA doing some unexpected things. Thus, it’s not that ConfigMgr does or doesn’t care really, it’s that the WUA behaves differently and causes “bad” things to happen.
For your issue, this is the result of two 1703 Feature Updates accidentally (to my knowledge) being added to the update catalog. You need to go into WSUS directly and decline one. This blog (which isn’t loading for me right now) has a complete walk-through of fixing this issue: http://www.gregorylab.com/tag/two-swap-osupgrades-are-found/
Jason,
Thank you for the excellent write but I still have a question. I’ve been doing some reading on what’s the best way to use the windows 10 Servicing.
I guess all my plans which is everything you said is NOT the right way of doing it is trashed now.
Do you have any plans on making an article on the best way of using Win10 servicing and keeping Win10 up to latest version?
Thanks in advance!
Hi, Bruce. Sorry that I trashed your hopes and dreams 🙂 I’m not sure what I said to dissuade you from your plans though. The main point of the post was to point out the ambiguity of the terms CB and CBB and that the much of the ConfigMgr centric documentation discussing servicing is inaccurate because of the dual-scan implications.
At this time, no, I’m not planning a follow-up post. Basically, my recommendation, as well as most others, is to use the upgrade task sequence type that’s built into ConfigMgr CB. Servicing can work though and some folks use it. Some folks even use Windows Update for Business.
Hi, still a bit confused: We are using SCCM CB to deploy the Windows security and feature updates as well our users are able to use the “search online for updates” function as a backup. How can I centrally manage the time a new feature update becomes available. So far I thought the defer GPO was able for doing that – turns out it is not.
It’s ok for us to disable the “backup” way (search online for updates). So far the only other corresponding gpo “do not connect to any windows update internet location” will stop the windows store also. Thats not a possible solution for us.
So, how can we just manage the time feature updates come available and still allow the direct microsoft update (including store updates)?
You manage feature updates like all other software and software updates in ConfigMgr: using deployments.
The current recommendation from Microsoft is to Enable the group policy “System/Internet Communication Management/Internet Communication settings/Turn off access to all Windows Update features”. Reference: Demystifying “Dual Scan” (https://blogs.technet.microsoft.com/wsus/2017/05/05/demystifying-dual-scan/).
Hello,
So just to clarify, I am just beginning a Windows 10 rollout using 1703. If I’m using WSUS + SCCM to control updates, are you saying the GPO setting to defer updates should not be switched on?
All the MS documentation mentions to control the CB or CBB states via GPO and then create collections in SCCM which query the OSBranch readiness state values (either 0 for CB or 1 for CBB).
If you don’t set the windows update deferral GPO, how should SCCM know which machines are CB and which are CBB?
Look forward to hearing back soon.
ConfigMgr doesn’t need to know which systems are CB or CBB by detecting a registry value. As noted, if you want to control your systems differently, then you create collections for them; however, what’s your intent here? Tracking which build your systems are on or dictating which build they are on? If you want to track, then you use the build number, if you want to dictate them use collections. As noted in the post, the defer options is merely defining an intent; in ConfigMgr we already have a way to define intent: collections.
Fantastic information. I’ve done same as you’ve suggested and control the CB and CBB computers via collections.
I have a question with regards to the feature upgrades (as in feature upgrade 1703). If this is deployed through the windows 10 servicing plan to a pc that’s running a customised image (as in default windows 10 store apps removed), all the store apps return/are reinstalled during the feature upgrade.
How is everyone else getting around this??
Isn’t this bit the wrong way round?
“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.”
Shouldn’t it be a system on a CBB built can be brought up to CB by applying the latest cumulative update?
No, this is not backwards. You are thinking about upgrading to the next version which would be applying a feature update and not a cumulative update. CBB is the latest build of a version of Windows.
This was an excellent post! I was having issues in our environment with having GPOs alongside SCCM Windows 10 Servicing!
As described, do not use Group Policy to set Current Branch (CBB) or Current Branch for Business (CBB). When these were enabled for CBB, they would appear correctly as CBB on the Windows 10 Servicing dashboard, but they would not download and install Cumulative Updates for the CBB version! This meant they would never patch month on month!
I even observed how Group Policy would apply it’s own WindowsUpdate registry keys for CBB, only for the SCCM Machine Policy Evaluation to then try and override these with a different set to allow updates to be detected properly! However Group Policy would then override them again.
In the end, without the GPO settings, I relied on Windows 10 Servicing & Automatic Deployment Rules to distribute CBB Features Updates & Cumulative Updates. Even though a machine can be listed as being on the CB channel via the Windows 10 Servicing dashboard, it doesn’t mean it cannot apply a CBB update. Providing the Windows 10 Servicing rules only apply to CBB releases, ADRs will never supply updates beyond CBB. This is how you can control CBB without using Group Policy.
After much reading and discussion with my colleagues, I’ve come to the conclusion that if you are using SCCM then CB/CBB is a red herring.
Just going to have a couple of device collections, a smallish representative sample one that gets updates as they come out and one with all the other devices in that gets them a while later if they pass testing.
Like what I do now (manually) with W7 and WSUS.
Good, clear information. Thanks.
You clearly understand what is going on in the Win10 world (and explain it well) more than almost anyone else I have found, so I apologize for my ignorance (or insolence) in advance.
You wrote: “eww yuck, it’s best to avoid LTSB altogether.”
Could you expand on that? I am interested in doing what is best for my (higher-ed) users, not what is best for Microsoft. However, I am having a hard time finding a logical argument for why LTSB is something to be avoided. I’ve tried to ask elsewhere and have not had much luck even getting a response.
If:
– you/users don’t have a need or interest in Edge or the Store,
– you are OK with several versions of LTSB cycling across the enterprise as computers are replaced, (e.g. 6-year replacement cycle = ~3 versions in use)
– one of your largest support holes is assisting users through changes, so feature, appearance and settings stability are critical,
Then why would LTSB such a bad choice for users (or for IT)?
The main reason why LTSB is bad is that you simply won’t be getting all of the new features in a timely manner. It’s kind of like running XP for 10 years. Sure it worked, but you missed out on the of the great new features released in Win Vista, 7 and 8.x and then had lots of pain to get off of it. Yes, you avoided a small amount of trouble by skipping those other versions of Windows, but those troubles were very much overhyped and blown way out of proportion.
> you/users don’t have a need or interest in Edge or the Store
That’s you dictating to your users not evaluating the features for what they are and what they can offer.
> you are OK with several versions of LTSB cycling across the enterprise as computers are replaced
All of those versions will be old and will miss the latest features. Chief among them are security features. IMO, it’s very short-sighted to discount these and say they won’t help your environment.
> one of your largest support holes is assisting users through changes, so feature, appearance, and settings stability are critical,
IMO, if you treat your users like babies, then they’ll never grow up and will always be babies. “Critical” for what though? I simply feel most orgs don’t give their users enough credit.
I understand your points and I think they are all valid, however, I also think it’s a downward spiral of doing business that puts us right back in the running XP 15 years later boat.
LTSB is really not work a user, it’s for critical system like a healthcare machine that, for exemple, keep someone alive by pumping air into his lungs. It’s 24/7 operating machine in a close environnement. The only thing they get are security update, nothing else.
Hi all,
Could you please post your process for removing the built in store apps such as xbox etc and when running either a windows 10 feature upgrade service plan or a task sequence os upgrade via sccm?
As in going from 1607 to 1703 via an sccm deployment and not having all the store apps installed again.
Looking forward to hearinbrg back soon.
Best regards.
I use the scripts removeapps.ps1 : https://blogs.technet.microsoft.com/mniehaus/2015/11/11/removing-windows-10-in-box-apps-during-a-task-sequence/
I use this as well.
When using SCCM, how long can you put off installing Feature Updates for Windows 10? Is there a time when Microsoft will force it on you, or do you keep complete control over when and how with SCCM? Thanks.
With ConfigMgr, it’s completely up to you. That’s the point of having a tool like ConfigMgr — **you** manage your systems and their configuration.
Keep in mind though that each build of Win 10 has a limited lifetime — with the new service release model its a fixed 18 months.
Would a windows 10 build just cease working if it reaches the 18 months?
You probably directed this question to Jason and he definitely knows more about ConfigMgr than I, but I’ll give a try at answering anyway.
No, it won’t stop working. However, it won’t get Quality Updates (a.k.a. patches) anymore. Consequently, it will be deemed as “out of compliance” by any security and/or compliance organization that your business deals with (internally or externally).
The lack of Quality Updates (patches that *include* security updates) are what drives most business that use Windows to stay on the update “train”.
Thank You, Thomas. I concur with your answer.
If there is anything MS can do well, is confusion. I never understood why it cannot be simple (Cough, avoiding mentioning other OS’s).
Honestly, at its core, it is simple. Folks have just made it a much bigger deal than it is and also confused its intent.
Has this situation been rectified now in terms of better documentation or changes in how it works? Is there a ‘go to’ set of instructions for how best to manage Windows 10 updates or do you still stick by your original post? Many thanks
For the most part, yes. Windows 10 itself has also evolved.
Keep in mind, “best” is *always* for you to determine. Don’t blindly follow as only you know your organization’s requirements and how to meet them with the tools.