locked
Windows 10 Pro 1703, and Windows Update with WSUS RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    7
    Sign in to vote

    Our firewall now blocks Windows Update online due to the large number of IPs used by thier CDN.

    Since Windows XP, we've had a GPO to control Windows Update, but at a certain point WSUS settings were added to some GPOs used for VDI, image builds, servers, etc.

    We went through the pains with Windows 10 and 1607 and WSUS, but got it corrected.  Never rolled out 1607 due to other issues with that build (Depreciated GPO settings, lack of control over "Spotlight", etc).

    1511 is falling off support, and now 1703 arrives and introduces a whole new load of Windows Update problems... 

    First problem, fresh installs of Windows 10 1703 will not install updates.

    Our or Windows Update GPO was originally built for Windows XP, and modified for Windows 7, 8, and then 10.  When each new ADMX template set for Windows 10 came out, they were added.  One of the first new settings we turned on from the 1511 templates, was "Defer Updates", to prevent those machines that were going to Windows Update online, from installing 1607 or 1703.  We had no problems with 1511 production machines, or 1607 test machines with these changes.

    Then the 1607 and eventually the 1703 ADMX templates were added to the central store.  The Defer Updates settings were again enabled.  I say again, because after the template update we found they were renamed and in a different location.  The old settings were "gone".

    1703 testing begins.  Fresh installs cannot install updates from WSUS.  1703 machines appear to be trying to go to Microsoft Update, ignoring our WSUS settings in the GPO.  A call is opened with MS.  MS eventually directs us to turn off the Defer settings, and enable two additional settings in our GPO.

    • Do not connect to any Windows Update Internet locations
    • Download Mode: Bypass (100)

    This fixes the Windows Update from WSUS for new installs, but introduced unexpected behavior.  Mainly, Microsoft Store, and things like the MS Symbol server and other MS services, being blocked completely. (actually the ADML warns of this)

    In addition, In-Place Upgrades were still unable to get updates during Dynamic Update, Windows Update in the MDT TS, or manually after deployment.

    I went looking in the GPRESULTS from one of these workstations, and noticed under "Extra Registry Settings" there were still 3 "Defer" settings listed.

    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\DeferUpdatePeriod = 0
    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\DeferUpgrade = 1
    • HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\DeferUpgradePeriod = 8

    What I discovered is that these were settings from the 1511 ADMX templates.   These settings were orphaned when the 1607 and 1703 ADMX templates overwrote the 1511 templates.  To correct this I had to:

    1. Backup and clear out our central template store of all ADMX / ADML files.
    2. Load only the 1511 templates into the store
    3. Set Defer settings in all GPOs to “Not Configured.
    4. Delete the 1511 template files and copy back in my production templates files.

    After this the defer settings were no longer being applied to machines.  By why was this setting causing any problems anyway?

    Up until this point I had never head of WUfB (Windows Update for Business) or "Dual-Scan".  But I went digging and found a lot of conflicting information.

    Microsoft TechNet: Why WSUS and SCCM managed clients are reaching out to Microsoft Online – This article suggests that in addition to not configuring the Defer settings, that “Configure Automatic Updates” should also be disabled.

    Microsoft MSDN: Windows Update for Business explained – This article states that if you use either Defer setting in conjunction with “Specify an internal update service location” the Defer / WUfb settings will be ignored.

    Microsoft: Configure Windows Update for Business – This article points out that Defer Updates and Defer Upgrades will cause the Windows Update service to bypass WSUS.

    Microsoft TechNet: Demystifying "Dual Scan" – This article states that enabling Defer Updates or Defer Upgrades in combination with “Specify intranet Microsoft update service location” enables WUfb.

    It goes on to state: 

    “What we are doing to improve this experience We’ve gotten enough feedback on this scenario that we have committed to release a quality update for 1607 that allows you to leverage WU for Business controls even in the on-premises scenario; i.e., for “Check online for updates” scans.  You’ll be able to defer feature updates without automatically shifting into Dual Scan behavior.  This policy will be Not Configured by default, and you’ll have to enable it to ensure that your WU client behaves as intended.  We’ll provide more detailed guidance as to exactly how to do this when the quality update to 1607 is released this Summer.  The same update will be released to 1703 before it is declared Business Ready, and this functionality will be part of the Windows 10 platform going forward. “

    This setting is now available (kinda) for 1607 machines.  Though the ADMX template won't be released until the next Windows 10 official release. (1709?)

    https://blogs.technet.microsoft.com/wsus/2017/08/04/improving-dual-scan-on-1607/

    So now Windows Updates is working for 1703 fresh installs, Windows Store and the MS Symbol server are accessible again, but still no WSUS updates during or post a 1511 to 1703 upgrade.

    Back to the registry.  Searching for "Defer" I com across a few more registry keys.  A few in keys labeled "PolicyManager", and a few in the UX key.

    “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings”

    Pre-Upgrade, there were 2 entries:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
    "DeferUpgrade"=dword:00000001
    "UxOption"=dword:00000000

    Post-Upgrade, there were several entries: 

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
    "ActiveHoursEnd"=dword:00000011
    "ActiveHoursStart"=dword:00000008
    "BranchReadinessLevel"=dword
    "DeferFeatureUpdatesPeriodInDays"=dword
    "DeferQualityUpdatesPeriodInDays"=dword
    "ExcludeWUDriversInQualityUpdate"=dword
    "LastToastAction"=dword:00000000
    "RestartNotificationsAllowed"=dword:00000000
    "UxOption"=dword:00000003


    Since I had a VM sitting Post-Upgrade with WSUS not functioning, I deleted:

    "DeferFeatureUpdatesPeriodInDays"
    "DeferQualityUpdatesPeriodInDays"

    After this, Windows Update detected, downloaded, and installed updates from WSUS with no problem.



    I then took the VM back to a Windows 1511 snapshot and deleted:

    "DeferUpgrade"=dword:00000001

    I also checked with Get-BITSTransfer and found some pending errorred downloads.  I used a Schedule Task to purge them as Local\SYSTEM.

    I then kicked off the MDT In-Place Upgrade from 1511 to 1703.  It was successful, and I was able to manually check for updates afterward as well.

    Just to note, this is the registry AFTER the upgrade, but after deleting that key above before the upgrade:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
"ActiveHoursEnd"=dword:00000011
"ActiveHoursStart"=dword:00000008
"BranchReadinessLevel"=dword:00000010
"DeferFeatureUpdatesPeriodInDays"=dword:00000000
"DeferQualityUpdatesPeriodInDays"=dword:00000000
"ExcludeWUDriversInQualityUpdate"=dword:00000000
"LastToastAction"=dword:00000000
"RestartNotificationsAllowed"=dword:00000000
"UxOption"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"AcceptTrustedPublisherCerts"=dword:00000001
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Group"
"WUServer"="http://WSUS.domain.com:8530"
"WUStatusServer"="http://WSUS.domain.com:8530"
"UpdateServiceUrlAlternate"=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"AUPowerManagement"=dword:00000001
"IncludeRecommendedUpdates"=dword:00000001
"NoAUAsDefaultShutdownOption"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000003
"AutomaticMaintenanceEnabled"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"AllowMUUpdateService"=dword:00000001

    The only issue I'm still running into, is when I include a "Windows Update" task in the In-Place Upgrade MDT Task Sequence, it will hang at "Working on updates  %100”?   I've let it set for 8 hours and it never progresses.  I'm pretty sure this isn't directly related to the issues above though and am working with MS and digging through logs to see if I can find a cause for this last issue.

    -Matt


    There's no place like 127.0.0.1

    Tuesday, August 8, 2017 4:01 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    This post was extremely helpful. Thank you for sharing, Matt.

    P.S. If you could add a few zeros to my checking account that would be great :-P

    Thursday, September 14, 2017 8:31 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I haven't followed up on it yet, because we STILL do not have WSUS working with 1511 to 1703 upgrades.  Same MS ticket is still open, so far we have had no fix for it.  The "Windows Update %100" will eventually end, but takes anywhere from hours to days.  Checking the Windows Update logs, we see it was trying to talk to Microsoft the whole time, then eventually times out.

    2017/08/01 09:48:02.7933816 360   4356  SLS             [0]0168.1104::08/01/2017-09:48:02.793 [sls]Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/10.0.15063.0/0?CH=278&L=en-US&P=&PT=0x30&WUA=10.0.15063.0&MK=VMware%2C+Inc.&MD=VMware+Virtual+Platform
    2017/08/03 15:24:15.6675608 1108  3880  SLS             [0]0454.0F28::08/03/2017-15:24:15.667 [sls]Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/10.0.15063.0/0?CH=278&L=en-US&P=&PT=0x30&WUA=10.0.15063.0&MK=VMware%2C+Inc.&MD=VMware+Virtual+Platform
    2017/08/03 15:27:03.8569101 1108  5920  ComApi          [0]0454.1720::08/03/2017-15:27:03.856 [comapi]* END *   Federated Search failed to process service registration, hr=0x80072EE2 (cV = EelhEfv1EkObfGFB.0.1.0)
    2017/08/03 15:27:03.8592798 1108  2796  ComApi          [0]0454.0AEC::08/03/2017-15:27:03.859 [comapi]ISusInternal:: DisconnectCall failed, hr=8024000C
    2017/08/03 15:32:54.5788482 1108  2840  Misc            [0]0454.0B18::08/03/2017-15:32:54.578 [endpointproviders]Got WSUS Client/Server URL: http://wsusserver.domain.com:8530/ClientWebService/client.asmx""

    I have a feeling this won't be resolved until the 1703 update to disable Dual-Scan is released, meaning after 1709 is released.

    -Matt


    There's no place like 127.0.0.1

    Friday, September 15, 2017 6:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I haven't read the FULL post (it was quite long)

    I pick out 2 things of the post though that I may have an answer to.

    First, you may actually have a dirty database. Use my script to check if you have a dirty database, and if you do, automatically fix it.

    Download my script below and run:

    .\Clean-WSUS.ps1 -DirtyDatabaseCheck

    If the Database is clean, it will report clean, however it the database is Dirty, it will fix it. You may have to either try 2 times on a client to get it to install after a cleaning or clear the SoftwareDistribution Folder on the client.

    The second point I took away from this without reading the whole story is, my script may help you. As long as the issue is not a GPO (like with Dual-Scan), my script may fix your issues. If it doesn't, it sure will make your life a lot easier as I automate the WSUS Maintenance that should be happening.

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need!

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Add WSUS Index Optimization to the database to increase the speed of many database operations in WSUS by approximately 1000-1500 times faster.
    2. Remove all Drivers from the WSUS Database (Default; Optional).
    3. Shrink your WSUSContent folder's size by declining multiple types of updates including by default any superseded updates, preview updates, expired updates, Itanium updates, and beta updates. Optional extras: Language Packs, IE7, IE8, IE9, IE10, Embedded, NonEnglishUpdates, ComputerUpdates32bit, WinXP.
    4. Remove declined updates from the WSUS Database.
    5. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    6. Compress Update Revisions.
    7. Remove Obsolete Updates.
    8. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    9. Application Pool Memory Configuration to display the current private memory limit and easily set it to any configurable amount including 0 for unlimited. This is a manual execution only.
    10. Checks to see if you have a dirty database, and if you do, fixes it. This is primarily for Server 2012 WSUS, and is a manual execution only.
    11. Run the Recommended SQL database Maintenance script on the actual SQL database.
    12. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use so don't over think it. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment (email settings only if you are accepting all the defaults), simply run:

    .\Clean-WSUS.ps1 -FirstRun

    If you wish to view or increase the Application Pool Memory Configuration, or run the Dirty Database Check, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.

    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Sunday, September 17, 2017 4:12 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Already have it running nightly.  Added this to the WSUS server during the 1607 / ESD MIME-Type issue.

    -Matt

    There's no place like 127.0.0.1

    Monday, September 18, 2017 5:04 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    What about the DirtyDatabaseCheck - it's a manual check.

    .\Clean-WSUS.ps1 -DirtyDatabaseCheck

    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Monday, September 18, 2017 5:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    What about the DirtyDatabaseCheck - it's a manual check.

    .\Clean-WSUS.ps1 -DirtyDatabaseCheck

    Adam Marshall, MCSE: Security
    http://www.adamj.org

    PS C:\Scripts> .\Clean-WSUS-3.1.ps1 -DirtyDatabaseCheck
Starting the connection to the SQL database and WSUS services. Please wait...
Connected to the WSUS server wsus.domain.com
Executing DirtyDatabaseCheck

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command                  
--     ----            -------------   -----         -----------     --------             -------                  
1      Job1            BackgroundJob   Completed     True            localhost            sqlcmd -S np:\\.\pipe\...
You have a clean database.


    There's no place like 127.0.0.1

    Monday, September 18, 2017 7:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I'm out of ideas.

    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Tuesday, September 19, 2017 1:27 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I know what it is.  It's Dual-Scan / WUfB.  I just don't know what's causing it, or how to correct it.  Apparently either does MS, or they are not sharing that information with Premier support.

    I've removed all the registry settings suggested by MS to turn it off, but it still calls out to MS and delays the upgrade for hours.  The only way I've been about to get around it, is adding this to the HOSTS file before starting the upgrade.  I could script this into the TS but I'm not going to do that.   But with this set my upgrades complete in less than an hour.

    192.168.0.1	sls.update.microsoft.com
192.168.0.1	tsfe.trafficschaping.dsp.mp.microsoft.com
192.168.0.1	fe3.delivery.mp.microsoft.com

(Sub your WSUS server IP for 192.168.0.1)


    Probably going to have to wait for the 1703 update to disable Dual-Scan via GPO, which isn't being released (or the ADMX files) until 1709 is released.

    https://blogs.technet.microsoft.com/wsus/2017/08/04/improving-dual-scan-on-1607/

    -Matt

    There's no place like 127.0.0.1

    Wednesday, September 20, 2017 4:16 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I have been fighting the exact same issue for just over a week, and have stumbled on your post.  I will start testing this today!

    One thing I noticed on our machines is that "updateserviceurlalternate" is set to "http://localhost:8005".  Had you noticed that on any of your machines?  Do you think that could be causing grief as well?

    I wish there would be a defined correct way of setting windows updates so that it only checks wsus/sccm.  I have found so many mixed ways of how things "should" be setup.  

    Thanks for the great info.

    Wednesday, September 20, 2017 3:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Previously to this year, it was not set.  Then during 1607 testing Microsoft had us set it to the WSUS server.  But when 1703 testing started I cleared it back and and it's currently not set in the registry.


    But yes, that could be causing some problems...


    From Microsoft:


    Added in the January service release of Windows 10, version 1607. Specifies an alternate intranet server to host updates from Microsoft Update. You can then use this update service to automatically update computers on your network.

    This setting lets you specify a server on your network to function as an internal update service. The Automatic Updates client will search this service for updates that apply to the computers on your network.

    To use this setting, you must set two server name values: the server from which the Automatic Updates client detects and downloads updates, and the server to which updated workstations upload statistics. You can set both values to be the same server. An optional server name value can be specified to configure Windows Update agent, and download updates from an alternate download server instead of WSUS Server.


    -Matt

    There's no place like 127.0.0.1


    • Edited by Matt5150 Wednesday, September 20, 2017 8:56 PM HTML
    Wednesday, September 20, 2017 8:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Were you able to resolve your upgrade issues? I was able to upgrade from 1511 to 1703 via WSUS after recreating the policy that contains our WSUS settings. I didn't want to dive into the registry or make changes to the central store to revert the defer upgrade settings that got orphaned so I recreated the policy from scratch.
    • Edited by acompton Wednesday, October 18, 2017 4:31 PM spelling
    Wednesday, October 18, 2017 4:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Not yet.  The KB4041676 update was recently released, and without an updated ADMX package, I've been applying the setting to the registry to enable the Disable Dual-Scan feature:

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 

Value name DisableDualScan 
Value type REG_DWORD 
Value data 0x1 (1)


    This seems to result in Dual-Scan being stopped (no more connections to Microsoft that I can tell during ZTIWindowsUpdate, but now is generating an error with ZTIWindowsUpdate.

    Ready to Opt-In to Microsoft Update: WUA Version: 10.0.15063.674     ZTIWindowsUpdate 10/12/2017 12:41:23 AM     0 (0x0000)
Microsoft Update Service:  Enabled = False  ZTIWindowsUpdate 10/12/2017 12:41:23 AM     0 (0x0000)
Command Line Procesed Query=False Registered=False  UpdateCommand=[IsInstalled = 0 and IsHidden = 0] ZTIWindowsUpdate     10/12/2017 12:41:23 AM     0 (0x0000)
Start Search... ZTIWindowsUpdate 10/12/2017 12:41:23 AM     0 (0x0000)
FAILURE (Err): -2145124295  0x80240039: Windows Update, search for updates. -    ZTIWindowsUpdate 10/12/2017 1:43:40 AM 0 (0x0000)
Restore NoAutoUpdateKey to 0     ZTIWindowsUpdate 10/12/2017 1:43:40 AM 0 (0x0000)
ZTI ERROR - Non-zero return code by ZTIWindowsUpdate, rc = 1     ZTIWindowsUpdate 10/12/2017 1:43:40 AM 0 (0x0000)
Event 41002 sent: ZTI ERROR - Non-zero return code by ZTIWindowsUpdate, rc = 1  ZTIWindowsUpdate 10/12/2017 1:43:40 AM 0 (0x0000)

    I'm getting this error even with the Windows 7 x64 machine that was previously upgrading and updating flawlessly.

    Still have the same Premier ticket open.  Current tech is focusing on WSUS settings / health.

    -Matt

    There's no place like 127.0.0.1

    Wednesday, October 18, 2017 4:51 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Just updated my PolicyDefinitions with the 1709 ADMX files and tried installing the VLS Win10 x64 1709 ISO via MDT.  I set the DisableDualScan during the task sequence and rebooted.

    ZTIWindowsUpdate STILL calling out to MS.

    2017/10/19 23:19:05.8946940 4744  8052  ProtocolTalker  Existing cookie is valid, just use it
2017/10/19 23:19:05.8946968 4744  8052  ProtocolTalker  PTInfo: Server requested registration
2017/10/19 23:19:05.9802619 4744  8052  Misc            Got WSUS Reporting URL: http://WSUS01.domain.com:8530/ReportingWebService/ReportingWebService.asmx""
2017/10/19 23:19:05.9802895 4744  8052  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents) started; operation # 227; does use network; is at background priority
2017/10/19 23:19:05.9805419 4744  8052  WebServices     Auto proxy settings for this web service call.
2017/10/19 23:19:05.9890757 4744  8052  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents, operation # 227) stopped; does use network; is at background priority
2017/10/19 23:19:10.0491559 6888  7080  Handler         CBS called Progress with state=0, ticks=449, total=1000
2017/10/19 23:19:15.5449277 6888  7080  Handler         CBS called Progress with state=0, ticks=449, total=1000
2017/10/19 23:19:16.6963953 6888  7080  Handler         CBS called Progress with state=0, ticks=449, total=1000
2017/10/19 23:19:19.5118670 4744  6768  Misc            *FAILED* [80072EE2] Send request
2017/10/19 23:19:19.5118800 4744  6768  SLS             *FAILED* [80072EE2] GetDownloadedOnWeakSSLCert
2017/10/19 23:19:19.5119535 4744  6768  SLS             *FAILED* [80072EE2] Method failed [CSLSClient::GetResponse:525]
2017/10/19 23:19:19.5120192 4744  6768  IdleTimer       WU operation (CDiscoveryCall::Init ID 32, operation # 195) stopped; does use network; is not at background priority
2017/10/19 23:19:19.5250497 4744  6744  SLS             *FAILED* [80248007] Method failed [SlsDatastoreLookup:797]
2017/10/19 23:19:19.5250579 4744  6744  SLS             Retrieving SLS response from server...
2017/10/19 23:19:19.5252962 4744  6744  SLS             Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/10.0.16299.0/0?CH=255&L=en-US&P=&PT=0x30&WUA=10.0.16299.15&MK=VMware%2C+Inc.&MD=VMware+Virtual+Platform
2017/10/19 23:19:19.5281507 1936  7764  ComApi          *RESUMED* Discovery
2017/10/19 23:19:19.5281606 1936  7764  ComApi          Exit code = 0x00000000, Result code = 0x80072EE2
2017/10/19 23:19:19.5281627 1936  7764  Api             * END *   Discovery ClientId
2017/10/19 23:19:19.5305363 1936  1564  ComApi          *FAILED* [80072EE2] Method failed [CSLSClientProxy::GetSLSDataChunk:247]
2017/10/19 23:19:19.5306803 1936  7808  ComApi          * START *   SLS Discovery
2017/10/19 23:19:19.5323692 4744  6604  IdleTimer       WU operation (CDiscoveryCall::Init ID 35) started; operation # 232; does use network; is not at background priority
2017/10/19 23:19:19.5324960 1936  7808  ComApi          *QUEUED* SLS Discovery
    -Matt

    There's no place like 127.0.0.1

    Thursday, October 19, 2017 11:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We are also struggling with updates in Windows 10 1703, for us the confusion revolves around the fact that the compliance reports are showing some machines as requiring KB4041676, while the majority say that the updates is "not required".

    The confusing part is that the update installs successfully, when run manually on a "not required" machine. 

    Tuesday, October 24, 2017 6:22 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Is the .ESD application/octet-stream setting still needed? In our WSUS, as soon as it is added, the WSUS website dies.  We are using Wsus stand alone, not with SCCM which may be different.  Anyways thought I would mention it as it may have been needed earlier or specifically for sccm with wsus.  However our testing shows wsus stand alone appears to die with that setting.  May be worth a try removing ESD temporarily to test.

    FYI, We are still in the beginning stage of our testing/research.  Thanks for this article.

    Tuesday, October 24, 2017 2:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I just want to say THANK YOU for posting this information, particularly for being really thorough about documenting it. I was aware of most of the registry entries but had no idea there is a new set being created by 1703 in the "HKLM>Software>Microsoft>WindowsUpdate>UX" key.

    Like you, I had no trouble getting WSUS updates to work with machines upgraded from 1607 to 1703, but the one clean install of 1703 I did refused to update and I could not for the life of me figure out why. I've gone through just about every hassle you could think of with each barely documented change Microsoft throws at WSUS users with every single upgrade and finally thought I had everything dialed in. Your post save me a huge amount of time and effort, I have no doubt.

    As soon as I deleted the entire key & subkeys for "UX" and updated GP on the machine, everything started working as it should.

    Wednesday, November 1, 2017 7:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Is the .ESD application/octet-stream setting still needed? In our WSUS, as soon as it is added, the WSUS website dies.  We are using Wsus stand alone, not with SCCM which may be different.  Anyways thought I would mention it as it may have been needed earlier or specifically for sccm with wsus.  However our testing shows wsus stand alone appears to die with that setting.  May be worth a try removing ESD temporarily to test.

    FYI, We are still in the beginning stage of our testing/research.  Thanks for this article.


    Have you made sure that MIME type is not already present and being inherited, resulting in you having two entries? This happened to me once on a WSUS server running Server 2012 R2, and it caused client errors until I removed the explicit entry I had added.


    • Edited by Walker Macy Wednesday, November 1, 2017 7:25 PM
    Wednesday, November 1, 2017 7:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you, this post has been a life saver.

    I put the 1709 ADMX templates into our domain, and updates for Windows 10 stopped.

    The GP changes suggested got things back updating!

    Friday, November 24, 2017 4:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thank you for sharing Matt, was extremely helpful!

    Just to add some help "Demystifying" Microsoft Policy options: "Allow Telemetry" policy "enabled" and the Options value is set to "0 (Security)” is also WUfB group policy setting that enables “dual scan mode”!

    On another note, it also makes the "Defer upgrades by", "Defer updates by" and "Pause Updates and Upgrades" settings have no effect.

    It's fun when your PCs start installing unapproved (WSUS) updates, and your Laptops using WUfB, upgrade to a new OS (1709) without your knowledge or control!
    • Edited by Jose Costa Tuesday, January 23, 2018 9:04 AM
    Monday, January 22, 2018 10:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote


    As soon as I deleted the entire key & subkeys for "UX" and updated GP on the machine, everything started working as it should.

    Is this an action you would recommend doing in a Business-environment or does this have any (unexpected other) side effects?

    Monday, January 29, 2018 4:45 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I feel your pains too pal.  We are on Windows 10 Enterprise 1607 and have seen the same exact issues when upgrading to 1703.  Same, exact, issues. 

    I have a ticket in with Microsoft Premiere support too but let's be honest with ourselves; Premiere support has been pure $hit since Windows 8.1 and they fired their internal QC/QA test group.

    I'll update my reply with any info I get too. We are trying to get Windows Updates working on 1703.  We also had disabled Dualscan since we didn't want any unapproved updates going to users.  Like you mentioned, WSUS and DualScan and Windows Updates for Business has been a complete and utter nightmare figuring out since no one, including WSUS Support, seems to know how it all should really work.

    As a fellow admin, i feel you.  I've done windows administration since XP days and the last year has been the worst year of my 14 years in IT.  Microsoft, just listen to us enterprise admins and what we want/don't.  Consumers don't bring in any money for Microsoft; us enterprise users.  Remember that one Microsoft.  Btw, XBOX is where you really make your money and Azure so stop catering to the consumers and cater to the money makers; enterprises.  /RANT  and most likely not the last one since we'll see a horrible 18xx build this year that will probably completely change the way things worked on 1709... because us IT admins don't have better things to work on.. /s

    Paid IT Geek; mobile/desktops/deployments

    Wednesday, January 31, 2018 9:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    @Matt the requests to sls.update.microsoft.com are for the Service Locator Service which is just a way for WUA to make sure it knows about all available services (fe2.update.microsoft.com [MU], fe3.update.microsoft.com [Store apps updates], etc). This will not cause the scan to fail, if we do not have an internet connection.

    By setting the policy/reg key below, you can block all connections to MU during the MDT TS:

    1. Enable the group policy System/Internet Communication Management/Internet Communication settings/Turn off access to all Windows Update features

    Only if you see fe2.update.microsoft.com as the Server URL, then it means that the updates are coming from the MU servers.

    @Jimmy, Steve Henry our former WSUS PM has detailed all common scenarios and when or when not we should use/not use Dual Scan:

    https://blogs.technet.microsoft.com/wsus/2017/08/04/improving-dual-scan-on-1607/

    Setting DisableDualScan will override any other registry keys that might or might not exist and disable the dual scan behavior.

    Just a tip from me, if you have any problem or feedback, please use the Feedback Hub, as the requests go directly to the responsible product group.

    I do this on my own time, but I will get the alerts from this thread in case you have further questions or concerns.

    Hope this helps,

    Andrei

    We could change the world, if God would give us the source code.

    Wednesday, January 31, 2018 10:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    THANK YOU Matt.  I've been trying to implement WSUS for the last few months and you have inspired me to stop wasting my time!  I wish I read your post earlier. 
    Tuesday, March 13, 2018 1:55 PM