Cannot enable "Updates for other Microsoft products" on WSUS client

Question

i cannot enable the checkbox "Give me updates for other Microsoft products when I update Windows" ("Microsoft update" instead of "Windows update").  If I enable it and press ok, the GUI stalls a bit and the check is removed.
Installing updates from the wsus server works. The client is a 2012 R2 install. 
From Windows updatelogs, it is clear the client attempt to connect to <HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=521&L=en-US&P=&PT=0x7&WUA=7.9.9600.17404> when I try to enable
Microsoft update
This is not allowed by firewall/proxy, so this obviously fails.This server is located in a secured vlan and should not have access to internet in any way. I suppose client should fetch the .cab from wsus?
2014-12-17 14:44:45:376 836 137c AU ########### AU: Setting new AU options ###########
2014-12-17 14:44:45:376 836 137c AU # Policy changed, AU refresh required = No
2014-12-17 14:44:45:376 836 137c AU # Policy Driven Provider: https://wsusserver.mydomain.tld
2014-12-17 14:44:45:376 836 137c AU # Detection frequency: 4
2014-12-17 14:44:45:376 836 137c AU # Approval type: Pre-install notify (Policy)
2014-12-17 14:44:45:376 836 137c AU # Auto-install minor updates: No (Policy)
2014-12-17 14:44:45:376 836 137c AU AU settings changed through User Preference.
2014-12-17 14:44:45:376 836 137c AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
2014-12-17 14:44:45:376 836 137c AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
2014-12-17 14:44:45:392 836 137c SLS Retrieving SLS response from server...
2014-12-17 14:44:45:392 836 137c SLS Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=521&L=en-US&P=&PT=0x7&WUA=7.9.9600.17404
2014-12-17 14:45:07:267 836 137c Misc WARNING: Send failed with hr = 80072ee2.
2014-12-17 14:45:07:267 836 137c Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
2014-12-17 14:45:07:267 836 137c Misc WARNING: Send request failed, hr:0x80072ee2
2014-12-17 14:45:07:267 836 137c Misc WARNING: WinHttp: SendRequestUsingProxy failed for <HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=521&L=en-US&P=&PT=0x7&WUA=7.9.9600.17404>. error 0x80072ee2
2014-12-17 14:45:07:267 836 137c Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
2014-12-17 14:45:07:267 836 137c Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
2014-12-17 14:45:07:267 836 137c Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
2014-12-17 14:45:07:267 836 137c SLS FATAL: SLS:CSLSDownloader::GetUrlContent: DoFileDownload failed with 0x80072ee2
I can set the cab path myself if I use
vbscript to register the microsoft update service, but I don't know which cab url I should use for this. 
I've used the same install image before, but I think all servers had access to internet (via proxy) when doing the first windowsupdate. this is no longer allowed. the image is an MDT installation image that attempt to enable the Microsoft update setting
with vbs as described in link above.
Please advice how to resolve this issue. 
MCP/MCSA/MCTS/MCITP

Answer 1

I was not aware if that, thanks! Is this documented somewhere?
Well, no, not really. Presumably there is no need to do so. The two environments use completely different classification methodologies which have almost zero relationship to one another.
The issue is this is checked for in the server security audit, all servers have this setting, but this one hasn't. I will need to be able to motivate/proof this point to our security department.
I would say your security department maybe needs to do some of their own self-education on how Microsoft's patch management system has worked for the past twenty years, and more recently, how it has worked with SUS/WSUS for the past eleven years. This is not
new stuff! :-)
Also odd is that on this server I only have one service in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RequestedAppCategories.
Don't really know much about what's in the ~\CurrentVersion\WindowsUpdate key either as it's also irrelevant to the WSUS environment.
Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.