Server 2016 configured for internal WSUS but going to Internet for patches.

Question

I have servers configured to update weekly and reboot on a schedule. My control for what it updated weekly is approval by WSUS. If I do not approve in WSUS, I do not expect install and reboot that weekend. I have found some servers recently that are updating a week early, with updates that have not been approved in WSUS. However, they are applying other policy settings like the install time and reboot after, and I can see the wsus server noted in the log, but don't know how to parse the messages. However, WUA appears to be checking online from Microsoft first, then downloading and installing those updates. My goal is for the client not not go to the Internet for updates and only check against WSUS. If nothing is approved in WSUS, there should be no download of updates.

(Ideally, I would also like to retain the option to check manually for updates against Microsoft in scenarios where the client may need additional updates in the online catalog that are not usually managed classifications in our WSUS server. But, more important is just making sure the client is not going to the internet for updates instead of waiting for WSUS approvals. )

Possible to help identify what I am missing in my configuration? (domain scrubbed in log, but is verified correct, can dl iuident.cab and no noted blocked traffic between server and client during processing).

183306-windowsupdatelog03152022.txt

Answer 1

Sounds like Dual Scan
https://www.ajtek.ca/wsus/dual-scan-making-sense-of-why-so-many-admins-have-issues/

Also, your policies have some outdated policies being specified. Remember to read through the descriptions CRITICALLY.

https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-4-creating-your-gpos-for-an-inheritance-setup/

Answer 2

I LOVE people who think that way.... (sarcasm)

No leveraging that policy is NOT a good idea.

You got to ask what Microsoft was thinking... make policies that cause a problem, and then make another policy to NEGATE that original policy....

Your best bet is to UNDO the bad policies.... not use another policy that negates it.... why?

BECAUSE MICROSOFT did it again - https://techcommunity.microsoft.com/t5/windows-it-pro-blog/why-you-shouldn-t-set-these-25-windows-policies/ba-p/3066178 (search for "Do not allow update deferral policies to cause scans against Windows Update")

This policy works on Windows 10, but is not supported and will have no effect on Windows 11 devices. We recommend using the new scan source policy instead.

Essentially - if you use a policy to negate a bad policy AND that policy no longer is effective, THE BAD POLICY PREVAILS.

If you remove the bad policies - GOOD policies prevail.

Answer 3

@Affiliatesoft-1037
It sounds like one important policy to leverage is Do not allow update deferral policies to cause scans against Windows Update to prevent reaching out to Windows Update?
Yes, the policy will prevent the clients from scanning updates from the Internet and disable Dual Scan.

Here is the related Official Document for you.
https://techcommunity.microsoft.com/t5/configuration-manager-archive/using-configmgr-with-windows-10-wufb-deferral-policies/ba-p/274278

Also we could run the below PowerShell commands on one affected device and check the default update source:

$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"  
   
$MUSM.Services | select Name, IsDefaultAUService  

Reference screenshot in my lab:

In my opinion, the screenshot means that the clients will scan for updates from WSUS first.

Best 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.