This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 73%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMB%3C/text%3E%3C/svg%3E)
I have customers whom have opted to move their 2008 and 2008 R2 servers to Azure in order to continue receiving security updates. They also wish to continue to use MECM to provide these updates. The servers have been migrated to Azure. Their MECM version is 2004. The clients are healthy. They can communicate with the Management points available to them. Yet, they never receive any updates that are deployed to them. Customer devices in Azure that are 2012R2 and newer have no problem getting updates through MECM. Am I missing something? Application restrictions at this time prevent them from moving to newer operating system for these servers.
Hi @Mike.Brown ,
Thanks for posting in the Q&A.
The support operating system for SCCM client and device are:
a. Windows Server 2019: Standard, Datacenter Note 1
(Starting with Configuration Manager version 1806.)
b. Windows Server 2016: Standard, Datacenter Note 1
c. Windows Storage Server 2016: Workgroup, Standard
d. Windows Server 2012 R2 (x64): Standard, Datacenter Note 1
e. Windows Storage Server 2012 R2 (x64)
f. Windows Server 2012 (x64): Standard, Datacenter Note 1
g. Windows Storage Server 2012 (x64)
Here is the article about the support operating system:
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/supported-operating-systems-for-clients-and-devices
2008 and 2008 R2 servers are no longer supported as SCCM client, so it could be something wrong with them to receive any updates either on premise or Azure. We could upgrade OS version if possible.
Thank you very much for your kind understanding.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Hi,
May we know the current status of the question? If there is any chance to try above suggestion? If there is any other assistance we can provide, please feel free to let us know, we will do our best to help you.
Thanks and regards,
Amanda
2008 and 2008R2 are STILL supported as SCCM Clients.
These servers have been migrated to Azure
That is not correct. Being in Azure does not change that these OS versions are past their EOL and thus unsupported. As noted, being entitled to the ESU does not make the OS supported.
Okay. So, how do you explain the updates still appearing in ConfigMgr?
2020-11 Security Monthly Quality Rollup for Windows Server 2008 for x86-based Systems (KB4586807) 1 0 11/10/2020 1:00:00 PM Critical
2020-11 Security Monthly Quality Rollup for Windows Server 2008 for x64-based Systems (KB4586807) 0 0 11/10/2020 1:00:00 PM Critical
2020-11 Security Monthly Quality Rollup for Windows Server 2008 R2 for x64-based Systems (KB4586827) 7 4 11/10/2020 1:00:00 PM Critical
2020-11 Cumulative Security Update for Internet Explorer 11 for Windows Server 2008 R2 for x64-based systems (KB4586768) 2 1 11/10/2020 1:00:00 PM Moderate
I read the below to include Server 2008/R2 in Azure.
https://www.microsoft.com/en-us/windows-server/extended-security-updates
Product: ConfigMgr (System Center Configuration Manager)
System Center 2012 and 2012 R2: No
System Center 2016/2019 LTSB: No
System Center Current Branch: Yes**
**For clients covered by Extended Security Updates, the latest released version of ConfigMgr (current branch) can deploy and install any security updates released. Client management features not related to patch management or operating system deployment will no longer be tested on the operating systems covered under by ESU. While they may continue to function in some capacity for a period, there are no guarantees. Microsoft recommends upgrading or migrating to current operating systems to receive client management support.
There's no magic here or about managing systems in Azure -- it's just another datacenter. Thus, the exact same requirements apply: the systems need connectivity to the client-facing site roles just like any network application.
However, Windows Server 2008 and 2008 R2 are past their end of life (which happened in January) so unless you're entitled to Extended Security Updates (ESU) -- because you purchased them, the recent updates (since January) aren't applicable and can't be installed. ConfigMgr in no way changes this. Also note that being entitled to ESUs does not imply support either as the products are still unsupported.
2008 and 2008R2 are STILL supported as SCCM Clients.
These servers have been migrated to Azure
If the servers have been migrated to Azure, they are still supportable for updates. We don't have to purchase ESU licenses if we migrated these servers to Azure.
Please go back and read my question.
2008 & 2008 R2 Servers are in Azure
SCCM (MECM) is on-prem
Servers' clients are still showing as active and client health checks are good.
Servers do not see the updates we have been approved in SCCM.
I am in no way saying this is your technical issue. I am simply stating the fact that Server 2008 and 2008 R2 are beyond their end of life and thus not supported. Full stop. There is no ambiguity on this point and any other interpretation is wrong. Being able to deploy updates to these OSes or seeing them as active in no way means they are supported. We don't intentionally break anything once they become unsupported but we also don't claim or guarantee that anything will actually work either.
2008 and 2008R2 are STILL supported as SCCM Clients.
No. We support deploying updates to them, but the OS itself is unsupported for all purposes. You're reading way too much into the word "can" and misinterpreting what the word support means. Just because you can doesn't mean you should and it certainly doesn't mean we guarantee anything about the scenario. That's the entire point here. You're clinging on to the use of something that we simply don't want you to do and aren't supporting you in either.
At a technical level, my best guess to your issue is that you haven't installed and activated the ESU keys on these systems.