locked
Cannot enable "Updates for other Microsoft products" on WSUS client RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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


    • Edited by SenneVL Wednesday, December 17, 2014 2:45 PM
    Wednesday, December 17, 2014 2:36 PM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote

    i cannot enable the checkbox "Give me updates for other Microsoft products when I update Windows" ("Microsoft update" instead of "Windows update").

    This setting is irrelevant on a WSUS client. What the client gets is driven by what is approved on the WSUS server. There is *NO* such distinction between "WU updates" and "MU updates" in a WSUS environment.

    So what is the actual *problem* that you are trying to resolve by changing this setting?

    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.

    • Marked as answer by SenneVL Friday, December 19, 2014 8:22 AM
    Wednesday, December 17, 2014 4:06 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    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.

    • Marked as answer by SenneVL Friday, December 19, 2014 8:22 AM
    Thursday, December 18, 2014 4:40 PM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    i cannot enable the checkbox "Give me updates for other Microsoft products when I update Windows" ("Microsoft update" instead of "Windows update").

    This setting is irrelevant on a WSUS client. What the client gets is driven by what is approved on the WSUS server. There is *NO* such distinction between "WU updates" and "MU updates" in a WSUS environment.

    So what is the actual *problem* that you are trying to resolve by changing this setting?

    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.

    • Marked as answer by SenneVL Friday, December 19, 2014 8:22 AM
    Wednesday, December 17, 2014 4:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I was not aware if that, thanks! Is this documented somewhere?

    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.

    Also odd is that on this server I only have one service in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RequestedAppCategories.

    It seems I do receive updates like for internet explorer or .net so you are probably still right and the keys on other server might be remainders of earlier updates through online services.

    MCP/MCSA/MCTS/MCITP


    • Edited by SenneVL Thursday, December 18, 2014 8:33 AM
    Thursday, December 18, 2014 8:31 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    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.

    • Marked as answer by SenneVL Friday, December 19, 2014 8:22 AM
    Thursday, December 18, 2014 4:40 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Seeing the same issue on a Server 2012 R2 Essentials machine. Installed WSUS a few months ago and it's been working fine. After a hard drive upgrade on the server, the Essentials dashboard now shows a Health Monitoring warning:  "Microsoft Update is not enabled" in reference to the server itself. However the checkbox enabling Windows Update will not stay checked.

    If it doesn't apply in a WSUS environment, the setting should either be removed or grayed out on clients, and Microsoft health checks should know to ignore it. Leaving the check box enabled but not settable seems like a bug.

    Mark Berry
    MCB Systems

    Monday, October 17, 2016 3:23 PM