When upgrading to Configuration Manager (ConfigMgr) Current branch (CB) or even implementing it from scratch, there is an unspoken requirement. It’s not really a requirement for ConfigMgr itself, but more of a requirement for WSUS. This requirement comes into play if you plan to use the new Windows 10 servicing feature in ConfigMgr CB. The servicing feature enables ConfigMgr CB to deploy in-place upgrades to Windows 10 systems using servicing plans which in turn use the software updates feature set behind the scenes.
For these upgrades to be available you need to have two things in place:
- Your WSUS instance(s) must be hosted on Windows Server 2012 or 2012 R2
- The server(s) hosting WSUS be have the hot fix from KB 3095113 applied.
Both of these are well documented and certainly not unspoken. What is unspoken here is that your site server must also be on a system running Windows Server 2012 or 2012 R2. This is obvious if you have a software update point (SUP) on the site server itself but it isn’t so obvious if your site server doesn’t have the SUP role on it. In this case, the site server stills requires installing the WSUS SDK on it which is done by installing the WSUS console. To be supported, the version of the WSUS SDK on the site server must match the version of WSUS used for any and all SUPs, which as noted above must be on Windows Server 2012 or 2012 R2 to support the servicing feature. Put this together and you have the unspoken requirement that a site server must be on Windows Server 2012 or 2012 R2 to support Windows 10 servicing.
If your site server is not on Windows Server 2012 or 2012 R2, you have three options to get it there:
- Upgrade ConfigMgr CB to the 1602 build which supports an in-place OS upgrade from Windows Server 2008 R2 to Server 2012 R2.
- Migrate to a new site where the site server is hosted on Windows Server 2012 R2 (and get rid of that CAS that you don’t need and never did).
- Use backup and recovery to move the site server to a new system running Windows Server 2012 R2.
Which you choose is up to you and not really the subject of this post so I won’t go into any detail here.
For reference, the WSUS version match requirement is documented at https://technet.microsoft.com/en-us/library/mt613198.aspx.
[ms_panel title=”Note” title_color=”#f5f5f5″ border_color=”#00274c” title_background_color=”#00274c” border_radius=”2″ class=”” id=””]The servicing feature is for deploying new Windows 10 builds to systems with Windows 10 already installed only. It is not for upgrading down-level Windows systems to Windows 10. Also, it is only for upgrading to and from Windows 10 Current Branch and Current Branch for Business (CBB) builds. The servicing dashboard will show information about systems running other branches including Inside Build but can upgrade to from them.[/ms_panel]
Good information Jason, thanks for sharing!
I wish I had read this document before I broke our SCCM / WSUS Software deployment solution! 🙁
We only upgrades out SUP server which is separate to our Server 2008 R2 Site Server.
So many thanks for this article, and I can confirm that this is very much the case! 🙂
Hi Jason, Good morning! I know it’s been a while you have created this post, and I really hope you can answer my questions, even though I dont think you are still following this post. Anyways, I will post my question and hope for the best.
I have applied the required KBs on my CAS and three more SUPs in my environment. I have also run the post-configuration command on my WSUS to decrypt the Windows 10 Upgrades.
My CAS is getting the Updates from Microsoft while the other are using upstream.
I Checked on my WSUS on my CAS, I can see the feature windows 10 anniversary update there, but I cant see it on my SCCM Console.
Do you have any idea why I cant find the feature anniversary update?
Thank you
Have you added the “Upgrade” classification to the configuration of your SUP?