Improving Dual Scan on 1607

發行項
08/04/2017

As mentioned in Demystifying "Dual Scan", configuring a combination of policies on Windows 10 1607 can result in those clients automatically [and unexpectedly] scanning against Windows Update, as well as subsequently ignoring deployment instructions from WSUS. We heard feedback from on-premises administrators that they needed the deferral policies only for ad hoc scans against Windows Update, a scenario which was not supported. The previous post mentioned a summer release of a policy on 1607 that would address the issue, and we are pleased to announce that this policy has arrived.

The package containing this policy is available today from KB4034658, which is the August cumulative update released to the WSUS channel on 8/8/2017. After installing this update (or any update released on July 18th or later), you will see this group policy under Windows Components/Windows Update:

[caption id="" align="alignleft" width="599"] Policy to disable Dual Scan New policy available in 1607 with the August cumulative update installed[/caption]

How Dual Scan works with this policy
In order for Dual Scan to be enabled, the Windows Update client now also requires that the "Do not allow update deferral policies to cause scans against Windows Update" is not configured. In other words, if this policy is enabled, then changing the deferral policies in a WSUS environment will not cause Dual-Scan behavior. This allows enterprise administrators to mark their machines as "Current Branch for Business," and to specify that feature updates should not be delivered before a certain amount of days, without worrying that their clients will start scanning Windows update unbidden. This means that usage of deferral policies is now supported in the on-premises environment. While the new policy (dubbed "Disable Dual Scan") is enabled, any deferral policies configured for that client will apply only to ad hoc scans against Windows Update, which are triggered by clicking "Check online for updates from Microsoft Update":

How to use this policy
There are several relevant scenarios in your update management strategy. For the sake of completeness, here are the most common update management scenarios, updated for use with this policy:

Windows updates from WU, non-Windows content from WSUS - the canonical Dual Scan scenario. Enabling the policy described in this post would disrupt Dual Scan operation and should not be done.
Windows updates from WSUS, blocking WU access entirely - the "workaround" scenario. If you have blocked access to Windows Update, then enabling the policy described in this post is irrelevant. Note that this workaround is no longer necessary and that you can control WU access by combining deferral policies with Disable Dual Scan.
Windows updates from WU, not using WSUS at all - the "consumer" or "WU for Business" scenario. If WSUS is not part of your update management infrastructure, then neither the Disable Dual Scan policy nor the change that introduced Dual Scan will have any effect. The same is true if all your Windows clients are running 1511, as Dual Scan was introduced in 1607.
Windows updates from WSUS, supplemental updates from WU - the "on-premises" scenario. Here you expect your users to perform ad hoc scans every so often to get updates that are necessary, but have not been deployed by the enterprise admins. You want quality updates, but do not want feature updates offered during these scans. The policy to disable Dual Scan was created for this scenario: you can enable the new policy, along with your deferral policies, and those deferral policies will only take effect when scanning against Windows [or Microsoft] Update.
Windows updates from Configuration Manager, supplemental updates from WU - a modified "on-premises" scenario. Here the expectations are the same as with the previous scenario, except that Config Manager recently took a change to remove some underlying policies that make this scenario work differently than described above. The Configuration Manager team has published its own guidance for this scenario.

Note that WSUS still ignores all deferral policies that have been configured, and that any deferral policies you do configure will only affect offering and download of updates for Microsoft products.

Now available: ADMX and MDM
We prioritized getting this update out to the broadest install base on 1607. In parallel, we ported the changes to 1703 and 1709. Installing the latest cumulative update on any of these platforms will allow you to access the Disable Dual Scan policy via MDM. You can also configure it centrally via the new administrative template that was released in conjunction with the 1709 feature update.

Comments

Anonymous
August 04, 2017
When can we expect guidance on the "Windows updates from Configuration Manager, supplemental updates from WU" scenario? Also, where should we look for it?
- Anonymous
  August 07, 2017
  We haven't seen a release date yet, but we know that a change is in the works. We'll update the scenario you called out on this page when updated guidance is available and will link to the appropriate page that Configuration Manager publishes.
Anonymous
August 05, 2017
Hi Steve,The new "Do not allow update deferral policies to cause scans against Windows Update" policy is not part of KB4022723 or KB4025339 but it's included in KB4025334 https://support.microsoft.com/en-us/help/4025334 download http://www.catalog.update.microsoft.com/Search.aspx?q=KB4025334Thanks,Tero
- Anonymous
  August 07, 2017
  Good catch, Tero. The KB article numbers were mixed up: we were one month behind. Updated the post to reflect that this change went into the July 18th update and will be part of that releasing on August 8th, as well as all future cumulative updates.
Anonymous
August 07, 2017
Would there be new ADMX templates available to deploy this policy through GPMC in DC ?
- Anonymous
  August 07, 2017
  Yes, new ADMX is published along with the next feature update release, whose exact date is not yet public knowledge.
  - Anonymous
    August 07, 2017
    So the ADMX template update for a 1607 / 1703 setting will be supplied after 1709 or 1803 is released?
    - Anonymous
      August 07, 2017
      Yes, in conjunction with the 1709 release (the naming of which does not imply a specific release date, by the way). Unfortunately this solution did not come together until well after 1703 had shipped, so we're refreshing at the next available opportunity.
      - Anonymous
        October 11, 2017
        Just found this posted yesterday, that claims the October update includes the new deferral policy for 1703. Is this true?https://blogs.technet.microsoft.com/configurationmgr/2017/10/10/using-configmgr-with-windows-10-wufb-deferral-policies/I don’t see it listed as a fix.https://support.microsoft.com/en-us/help/4041676/windows-10-update-kb4041676
        
        Anonymous
        October 12, 2017
        Yes, installing the October cumulative update should add this policy to the 1703 client.
Anonymous
August 07, 2017
I just updated to 1703. When will this policy be injected into that release?
- Anonymous
  August 07, 2017
  You should see this policy in 1703 around the time that 1709 is released.
  - Anonymous
    August 08, 2017
    So, the patch wasn't released in time to prevent most Dual Scan machines from upgrading to 1703, and there is no rush to release the same fix to 1703 until "around the time that 1709 is released." So what is stopping this scenario from happening again on release of 1709?Can't you understand how removing update control from Admins is a huge bird-flip to any businesses with an IT department?
    - Anonymous
      August 09, 2017
      The delay is not for lack of understanding, but for want of prioritizing some relief (i.e., for 1607) over no relief in the short term. If you are on 1703, then you'll potentially face the issue: the best course of action there is to block Windows Update entirely if you don't want any feature updates (e.g., 1709) to be pushed to your clients. While not altogether ideal, we thought waiting until we could ship the 1607 and 1703 changes simultaneously would have put more folks in an undesirable state, given that 1607 was and is more prevalent. If there is feedback to suggest that waiting for both to be ready before shipping anything would have been preferred by admins, then we'd love to hear it.
    - Anonymous
      August 09, 2017
      Regarding removing update control: the vision is that Cloud-first management obviates the need to explicitly approve every update that is deployed in your environment. Ideally the updates simply flow while the IT department monitors for issues, at which point it can pause the operations and mitigate as necessary. The policy described in this post is specifically catering to the on-premises admins who are not aligned with this Cloud-first management philosophy.
Anonymous
August 08, 2017
I've installed 1607 and installed KB4022723 with the RSAT and I still don't see the new policy. Any ideas what I could have missed?THks
- Anonymous
  August 08, 2017
  Sorry for the confusion, stephane: we previously updated the link to point to KB4025334, but the text still showed 4022723. The content you need is in the July 18th update, as well as every update afterward. We recommend installing the latest, which would be KB4034658 (August 8th). Updated the post to avoid confusion.
  - Anonymous
    August 09, 2017
    I've installed KB4034658 and rebooted but I still can't see the new policy in group policy management running on my 1607 wks.
Anonymous
August 08, 2017
Anyone notice that this latest set up updates killed WSUS for 2016 servers???After installing KB4034658 and the servicing KB4035631, my 2016 machines cannot talk to the WSUS server.Uninstalling the KB does not fix the issue. The servicing KB cannot be uninstalled it seems.All W10 machines can connect no issues with the WSUS server.Nothing special on the setup. Assuming another failed update (after last year's 2012R2 fiasco, I expected this).Looks like I have to restore the VM from a backup and wait for a patch again next month.I am hoping that restoring the WSUS server will fix it. Otherwise all the VM's will need restoration.
- Anonymous
  August 08, 2017
  Edit, posting here as it could be related to the post above.Also this is the only place there were good comments after last year's failed WSUS updates (needed manual steps to fix after the issue was identified and had to hunt to find out where the manual fix information was). Sorry, just left a bad taste, as it was not up to normal MS quality.
  - Anonymous
    August 09, 2017
    We appreciate the expectation of normal MS quality and are striving to live up to it after last year's misstep.
- Anonymous
  August 09, 2017
  Thanks for pointing this out. It's much more likely that 4035631 caused the issue here: Servicing Stack Updates can be tricky to release flawlessly, and they unfortunately cannot be uninstalled. Can others confirm these results? If so, then we'll get a bug filed for the SSU.
  - Anonymous
    August 14, 2017
    I can also confirm that KB4035631 has resulted in our Windows 2016 servers no longer communicating with our Windows 2012 R2 WSUS server. After install of KB4035631 and KB4034658, followed by reboot, Windows Update reports 0x8024401c.
    - Anonymous
      August 15, 2017
      Can you share the forum thread where you've reported the issue? Have you filed an official support request? Any information you have about this failure and your investigation into it so far would be helpful.
      - Anonymous
        August 21, 2017
        +1 for KB4035631 causing subsequent failures to communicate with WSUS from our 2016 WSUS clients. I'll be doing further investigation tomorrow to confirm and then getting a support request in: will update here if I get anything useful back.
      - Anonymous
        August 28, 2017
        The comment has been removed
        
        Anonymous
        August 28, 2017
        Yes, we made a judgment call to keep that traffic on the support-focused communication outlets, rather than cover it on the WSUS blog. Glad to hear that the provided guidance resolved your issue.
- Anonymous
  August 25, 2017
  Yes, confirm seeing the same problem
Anonymous
August 09, 2017
The comment has been removed
- Anonymous
  August 10, 2017
  Your scenario is exactly the one targeted by this improvement to 1607 (and soon 1703), Stacy. Enable this policy and your clients will no longer scan against Windows Update when they have been configured to defer feature or quality updates.
  - Anonymous
    August 11, 2017
    That's what I want to do, but I can't see it in group policy management on the updated machine.Does that has to be done locally on each?
    - Anonymous
      August 15, 2017
      That's correct: after installing the update, you'll see the new policy on each of the machines. Domain group policy (ADMX) will make this easier when it is released with 1709.
      - Anonymous
        September 11, 2017
        Holding off on releasing this update to the ADMX is inconvenient at best. I, as well as many other admins fell prey to the dual scan scenario, however the solution to manually enable this setting on each local machine is generally not feasible for most more mature IT environments. Can MS please consider releasing this ADMX ahead of the next major release to provide us some relief here?
        
        Anonymous
        September 12, 2017
        Thanks for the feedback, Tim. We will certainly keep it in mind for future releases. The intention was twofold:1. Provide immediate relief to smaller businesses and those that are able to set the new policy locally2. Indicate to larger businesses that relief is coming. Until ADMX is released, it makes more sense to continue using the "block WU entirely" workaroundAre you unable to use the short-term workaround until the ADMX is available?
Anonymous
August 11, 2017
Steve,I'm a bit confused, When will ADMX files come out to allow me to set this policy via GPO? Are you saying I need to wait until 1709 is released and new ADMX files are released? I believe the update will modify Local Policy files to show these options in gpedit.msc
- Anonymous
  August 15, 2017
  That's correct, John: local group policy reflects the new functionality immediately, but the convenience of managing via domain group policy will not be available until the next major update (i.e., 1709).
  - Anonymous
    August 24, 2017
    So if we are using ADMX files in a central store, how do we even access this new setting now?
    - Anonymous
      August 28, 2017
      Until the ADMX is published, you can access the "Do not allow deferral policies to cause scans against Windows Update" policy locally on 1607 clients that have been updated to include it. Centrally, there is currently no way to configure this policy.
      - Anonymous
        August 28, 2017
        The comment has been removed
        
        Anonymous
        September 12, 2017
        Understood, James. If that's the case, then you'll want to leverage the workaround policy presented in the original post ("Turn off access to all Windows Update features") until your ADMX becomes available.
Anonymous
August 15, 2017
We are running an environment that has 1511, 1607 and now 1703 - managed by SCCM. With the dual scan issues we have seen many of machines randomly updating from WU. I wish the Microsoft would have given us some heads up and made this process more practical and easier to comprehend and roll out. Got a feeling that we are always trying to play catch up with the updates. What is Microsoft doing to make this process more streamlined?
- Anonymous
  August 15, 2017
  Understood that there are growing pains with the introduction of a new solution. The update stack has largely been untouched for years, and this recent churn can come as a surprise. With that said, we're not clear on what you mean by a process being streamlined: can you provide some examples?
  - Anonymous
    August 15, 2017
    Thank you for your reply, Steve. Referring to the process being streamlined, I meat that it would be useful to be aware of these changes in advance. Patching all workstations/servers in an enterprise is always a challenge and if Microsoft can keep the Engineers who manage SCCM/WSUS and other patching management software informed of these changes - perhaps a location on Technet where information about these changes and new features are released and updated frequently?
Anonymous
August 16, 2017
It would have been good if it were obvious that setting things like 'ExcludeWUDriversInQualityUpdate" would trigger the Dual Scan... !Unfortunately for me, it was too late when I found the list of Policies which caused this behaviour - https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-onlineWith this not being in the current GPO .ADMX templates - you could always push the policy out via registry change to the current 1607 and 1703 clients, which will affect the 1607 clients now, and the 1703 clients when the update to support this functionality is released.I guess that way you don't have to remember to go back and set the GPO...REG ADD "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate" /v "DisableDualScan" /t REG_DWORD /d 0x1 /f
- Anonymous
  August 17, 2017
  Yes, we fixed that bug (about excluding drivers causing dual scan) in 1703. With the new policy enabled, even "exclude drivers" won't trigger Dual Scan. That's true about pushing registry keys: it's not as convenient as an ADMX, but it would get the job done.
Anonymous
August 17, 2017
I have 11 sites and one Internet connection and a mixture of 1511 and 1607 clients. I have random 1511 clients sometimes upgrading to 1607 but not others. When this happens it clogs our WAN. What do I have to do to make it like the old days where I have total control over my patching? How can I ensure machines will NEVER upgrade to a newer version of Windows? How can I ensure clients only goto WSUS? I think these changes and lack of communication from MS not to mention confusing articles like this is unacceptable.
- Anonymous
  August 28, 2017
  Hi Andrew, and sorry for the confusion. For all versions of Windows 10, there is the potential for an ad hoc scan against Windows Update to result in downloading a feature update to a newer build. If you want to guarantee that your machines never download this content from Windows Update and clog your WAN, then you'll want to use the "Turn off access to all Windows Update features" policy to block access entirely. Note that doing so will prevent you from getting quality updates through Windows Update, as well.
Anonymous
August 22, 2017
The comment has been removed
- Anonymous
  August 28, 2017
  Thanks for the feedback, Eric. Windows 10 changes the servicing game in ways that make existing tools work differently than you might expect. Your solution hits on a number of good points that were considered, but unfortunately the implementation is more complex than to allow such a simple interface to serve the purpose. With that said, we'll keep your comments in mind for future changes to this platform.
Anonymous
August 24, 2017
Is there an ETA on when the 1709 ADMX files will be released so we can fix through Group Policy? We are wanting to stay on 1511 (since it works) but that obviously is coming to end of life in the next 2 months. I guess we are just in a pickle because we don't want random upgrades to happen but yet 1511 is at end of life soon."That’s correct: after installing the update, you’ll see the new policy on each of the machines. Domain group policy (ADMX) will make this easier when it is released with 1709."
Anonymous
August 25, 2017
We are running version 1511 and don't want to update to 1607/1703 until the mdmx template is out with the fix. Do you think the new mdmx file will be released for Group Policy before 1511 end of life in October?
- Anonymous
  August 28, 2017
  That's the intention, though WSUS itself is not in control of when 1709 is released.
Anonymous
September 06, 2017
What if a person wants to receive updates from both Windows Update for Business and WSUS/SCCM at the same time. Is this scenario possible? I have had no luck getting this to work, I can only receive updates from WSUS/SCCM. I can see it searching Windows update in the logs, but it never downloads and fails with error 0x8024002E. Apologies if this is the wrong area, but I can't find any information on this. Only disabling this behavior.
- Anonymous
  September 12, 2017
  This is literally the Dual Scan scenario. To enable it, you need only configure one of the deferral policies mentioned in the original post. Under Dual Scan, you will get all Windows content from Windows Update and all non-Windows (as well as non-Microsoft) content from WSUS/ConfigMgr. If this is the mix you're looking for, then Dual Scan should suit your purpose nicely.
Anonymous
September 12, 2017
Thanks for the reply! So if I understand correctly we could receive updates and feature updates for windows from Windows Update for Business, but still receive our updates for Office 365 from SCCM/WSUS? To fully enable dual scan we would also need to disable the "Specify intranet Microsoft update service location" group policy?
Anonymous
September 21, 2017
Can anyone tell me why I don't see the option "Do not allow update deferral policies to cause scans against Windows Update"? I have installed the "Administrative Templates (.admx) for Windows 10 (1703) and Windows Server 2016", RSAT on a Windows 10 machine but no luck so far...
- Anonymous
  October 12, 2017
  ADMX for centrally modifying this policy is added in 1709. RSAT does not include this functionality, but you should be able to locally modify the policy on the 1703 machine even today.
Anonymous
October 11, 2017
Does this "Do not allow update deferral policies to cause scans against Windows Update" also do the same behavior as "Do not connect to any Windows Update Internet locations"?It looks like after applying this policy, running commands like "Get-WindowsUpdateLog" are no longer going to Microsoft sites. Log contains GUID information that wasn't resolved from the Micrososft Symbol server.
- Anonymous
  October 25, 2017
  Matt,If you are using 1709, refer to the following blog article which may explain the behavior you are seeing:https://blogs.technet.microsoft.com/mniehaus/2017/10/10/improved-windows-update-log-formatting-with-windows-10-1709/
Anonymous
October 18, 2017
Has anyone seen or know when the new admx templates will be released for group policy. I figured they would have been released the day that 1709 went public but don't see anything. Was hoping we would be able to fix group policy soon.
- Anonymous
  October 25, 2017
  Steve updated the article. The new 1709 templates have been released.https://www.microsoft.com/en-us/download/details.aspx?id=56121
Anonymous
October 25, 2017
We recently added the 1709 ADMXs to our central store so that we could start using the new policy "Do not allow update deferral policies to cause scans against Windows Update"After doing so, we can no longer find the old deferral policies in our central store anymore. The "Defer Windows Updates" 'folder' is no longer found under "Windows Update." Instead we see "Windows Update for Business"Underneath there, the closest thing I could find to a deferral policy is called:"Select when preview builds and feature updates are received"Why would we want to combine preview build settings in the same policy as feature updates?We do not use WUfB. We use WSUS and we simply want to disable the ability for users to install feature updates from Microsoft and without enabling dual scan. How can that be done using the 1709 ADMXs? What happened to the old deferral policies? Would we have to apply separate deferral policies for 1607, 1703, and 1709?
Anonymous
January 09, 2018
The comment has been removed

共用方式為

Improving Dual Scan on 1607

Comments

其他資源