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(3.2, 73%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERH%3C/text%3E%3C/svg%3E)
I am using SCCM 2107 with ADK for Windows 10 v2004, and MDT 8456. Devices are configured to get Software Updates for Office and Windows 10 via SCCM Software Update Point, and this has been working perfectly. I have also updated the Software Update Point and ADRs to download and deploy OS updates for Windows 11
I've recently started testing the upgrade of Windows 10 devices to Windows 11, by deploying the Windows 11 Upgrade as a software update. The upgrade has gone through smoothly and SCCM client seems to be working properly with Windows 11. Once issue I am noticing however, is that the Windows 11 devices seem to be getting updates directly from Microsoft on Patch Tuesday, and not from SCCM on their scheduled date. We have a 3 phase rollout of updates, on days 1, 3 and 10 AFTER Patch Tuesday, and the Windows 11 machines are in the phases that receive patches on day 3 and day 10 after Patch Tuesday.
In addition, the post update reboot notification after an update is installed on these machines is the standard Windows 11 notification, and not the one configured in SCCM (I have configured SCCM to force a reboot after updates after 24 hours, with a reminder every 30 minutes)
Any idea as to why these Windows 11 machines are getting their updates from Microsoft directly and not from SCCM, even though before being upgraded to Windows 11 they were getting updates from SCCM ?
Other than configuring the Software Update Point and ADRs, do I need to configure anything else differently in SCCM to support Windows 11 updates ?
Thanks for your reply and the troubleshooting information. I've upgraded about 10 machines so far, and on my 2 machines, it seems to be exhibiting this behaviour. I will check the windowsupdate.log files as you suggested on my machines and ask my colleagues to get the log file from their machine too
![](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(297.6, 24%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERH%3C/text%3E%3C/svg%3E)
Thanks for your update.
Looking forward for your feedback.
Have a great day :)
Regards,
Rita
The issue I seem to have is that the WindowsUpdate log only goes back a few days, so it's not showing any updates that were done just after patch tuesday. I'll have to wait for December patch cycle to generate new log files and go through them again
Thanks for your feedback.
Please keep us in touch if there are any updates of the case.
Thanks for your time and have a great day :)
Regards,
Rita
I got a new windowsupdatelog file from someone. Logs show some downloads from Microsoft Store (for store apps), and as the log extracts show, one Security Intelligence update from Windows Update, as well as the 2-21-12 Cumulative update from "OS Flighting" (whatever that is). This particular machine is working remotely, and wasn't on VPN at the time it did updates this morning. As we use an SCCM Cloud Management Gateway, and have configured SCCM to send machines direct to Microsoft for Internet Based Clients, Therefore, this machine might actually be acting as designed, and choosing Microsoft Update (due to being Internet Based) and not simply defaulting to Microsoft Update. I'll have to wait for more machines to receive updates and report back to me
For the record, the person left their machine on overnight, and when logging on this morning, they noticed the reboot icon showing in the system tray 
(Surely if SCCM was doing hte update, it would show the SCCM reboot prompt ??)
They clicked it and it showed this 
They clicked Restart Now and then Update and Restart, and the machine continued update process
@Roger Hendrikse
Thanks for your feedback.
It seems that the clients did try to get updates from Internet. In default, the client will try to scan for updates from the Internet even though the clients are managed by MECM/WSUS and could get the updates from the intranet. That is so called Dual scan. Reference link: https://cloudblogs.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/
As far as I know, we could apply the below two policies to prevent the clients to get updates from the Internet. Please try to deploy the policies to the clients if you don't want to clients to get updates from the Internet.
Turn off access to all Windows Update features
Path:
Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings\Turn off access to all Window update feature
Do not connect to any Windows Update Internet locations
Path:
Computer Configuration\Administrative Templates\Windows Components\Windows Update
Regards,
Rita
Thanks for the info. I don't want to turn off getting updates from Internet, as we rely on this for internet based clients. The issue at hand is that it seems that when on the LAN / VPN, clients are getting updates form internet and not SCCM AND they are ignoring the customized reboot settings we configured in SCCM. I will have more logs in a day or two after more machines receive updates, with hopefully one or two of them on network / VPN at time of update.
@Roger Hendrikse
Thanks for your response.
Please help to confirm what's the customized reboot settings you configured in SCCM and share the screenshot on this forum.
In fact, the updates are deployed by MECM will be placed into the software center. And the clients could install the updates in software center. Please help to confirm whether the updates deployed by MECM are installed successfully on the clients or not. One more thing, I am not sure whether clients will be out of control when the clients try to get updates from the Internet. There is no such document for reference. But we could apply the other policies to reboot at the schedule time after installing the updates. Here is a reference link for your reference: https://learn.microsoft.com/en-us/windows/deployment/update/waas-restart
Regards,
Rita
@Roger Hendrikse
Thanks for your posting on Q&A.
Please help to confirm whether the issue occurred on all the Windows 11 clients or just one client.
We have a 3 phase rollout of updates, on days 1, 3 and 10 AFTER Patch Tuesday, and the Windows 11 machines are in the phases that receive patches on day 3 and day 10 after Patch Tuesday.
To avoid misunderstanding, the three phases are all applied into the same device collection. Am I right? Would you mind describe the phased deployment in detail?
In addition, we could review the windowsupdate.log to confirm where the updates from. We could open PowerShell as an administrator and print get-windowsupdatelog to get the log files. Note that the log file will be placed into the Desktop.
Service ID will indicate where the updates come from. Here is a screenshot for your reference:
Hope the above will be helpful.
Regards,
Rita
If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
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.
While I wait for the log files and look through them, I'll explain the phased approach we have for updates
We have 3 phases of updates, phase 0, phase 1 and Phase 2. The phases are deployed to different collections. Phase 0 is deployed to make updates available to phase 0 devices 3 hours after the ADRs run on Patch Tuesday. Phase 1 is scheduled to make updates available to Phase 1 devices on "day 3" (3 days after patch tuesday), which is first Friday after Patch Tuesday. Phase 2 is scheduled to make updates available on day 10 (second Friday after Patch Tuesday)
So looking at some logs I got back I am seeing the following sources being contacted for updates, with what I can tell are varying levels of success (seeing a lot of failure error messages, most of which I can really understand)
Windows 11 machines
Machine name ox205902PAWS (my machine) (records from 17/11/2021 to today)
Windows Store
Windows Update
Config Manager
OS Flighting
Machine name ox205902VM (also my machine) (records from 19/11/2021 to today)
Windows Store {855E8A7C-ECB4-4CA3-B045-1DFA50104289}
Windows Update {9482F4B4-E343-43B6-B170-9A65BC822C77}
Config Manager {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
OS Flighting {8B24B027-1DEE-BABB-9A95-3517DFB9C552}
Machine Name OX204329VM (Records for today and yesterday)
Config Manager {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
Windows Store {855E8A7C-ECB4-4CA3-B045-1DFA50104289}
OS Flighting {8B24B027-1DEE-BABB-9A95-3517DFB9C552}
Machine Name OX206496 (records from 19/11/2021 to today)
Windows Store {855E8A7C-ECB4-4CA3-B045-1DFA50104289}
Windows Update {9482F4B4-E343-43B6-B170-9A65BC822C77}
Config Manager {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
OS Flighting {8B24B027-1DEE-BABB-9A95-3517DFB9C552}
I also checked a Windows 10 machine and this shows the following sources being contacted
OX200038VM03 (Windows 10 - records from23/11/2021 to today)
Windows Store {855E8A7C-ECB4-4CA3-B045-1DFA50104289}
Windows Update {9482F4B4-E343-43B6-B170-9A65BC822C77}
Config Manager {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
I'm struggling to make sense of what failures to ignore as 'noise' and what is actually constituting a possible issue. Also the errors seen on the Windows 11 machines seem to be different (and more numerous) than those on the windows 10 machine
I'm going to try and find out from the logs what source was used for specific updates by comparing Update History on the machine to the log files
Have you found the other updates which have not been deployed by MECM on the problematic computers? Please help to compare the number of updates deployed by MECM with the number of computers actually installed and check for consistency.
We could look for DownloadManager Updates to download = 1 on the windows update log and confirm whether the updates come from MECM. Here is a screenshot for you:
