WSUS Product Team Blog https://docs.microsoft.com/archive/blogs/wsus/feed.xml Information on recent and upcoming changes to WSUS, straight from the team making them Sat, 03 Mar 2018 09:39:23 GMT en-US hourly 1 WSUS Catalog import failures https://docs.microsoft.com/archive/blogs/wsus/catalog-import-failure Fri, 02 Mar 2018 16:24:31 GMT https://blogs.technet.microsoft.com/wsus/?p=2795 We are aware of the issue and presently working on a fix. In the meantime, the following workarounds can be used to unblock your deployment:
  • After clicking on the “Import Updates…” option in the WSUS console, an Internet Explorer window will open on the following URL: https://catalog.update.microsoft.com/... &Protocol=1.20
  • Before proceeding with importing the updates, change the “1.20” protocol value in the URL to the previous protocol value “1.8”. The URL should look like this when you’re done: https://catalog.update.microsoft.com/... &Protocol=1.8
Going forward, please visit the Tech Community Windows 10 Servicing Page for future WSUS-related posts.]]> Improving Dual Scan on 1607 https://docs.microsoft.com/archive/blogs/wsus/improving-dual-scan-on-1607 Fri, 04 Aug 2017 17:10:01 GMT https://blogs.technet.microsoft.com/wsus/?p=2755 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": 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. ]]> Microsoft .NET Framework 4.7 coming to WSUS https://docs.microsoft.com/archive/blogs/wsus/microsoft-net-framework-4-7-coming-to-wsus Mon, 12 Jun 2017 11:17:28 GMT https://blogs.technet.microsoft.com/wsus/?p=2725 (this post contributed by the .NET team. Note that WSUS 3.0 will fail to install if .NET 4.6 or later is already installed on the machine, per our previous article describing this behavior)   Hi WSUS Admins, The Microsoft .NET Framework 4.7 will be made available via Windows Server Update Services for Windows 7 SP1, Windows 8.1, Windows 10 Anniversary Update (Version 1607), Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016 on June 13, 2017.   The .NET Framework 4.7 is a highly compatible, in-place update to all the previous 4.X versions of the .NET Framework including .NET 4, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1 and 4.6.2. Applications built against and running on previous versions of .NET Framework will automatically roll forward to using the newer .NET 4.7 runtime without recompilation of the apps. .NET 4.7 can be installed on a fresh machine or can be used to upgrade your previous .NET 4.X installation.   The .NET Framework 4.7 installs side by side with older Framework versions such as .NET 3.5 SP1. Applications compiled against .NET 3.5 SP1 will continue to run on .NET 3.5 SP1 and will not automatically roll forward to .NET 4.7. You can learn more about .NET Framework 4.7 here:   More information about this release:
  1. The .NET Framework 4.7 update bundles for Windows 7 SP1, Windows Server 2008 R2 SP1 and Windows Server 2012 carry a DirectX dependency check (D3DCompiler: %windir%\system32\d3dcompiler_47.dll). This file needs to be present before the .NET 4.7 bundles will offer on these platforms.
 

The DirectX dependency is available in the May 2017 Monthly Rollup under the following Knowledge Base Articles:

The DirectX dependency is also available outside of the Monthly Rollup as an independent/standalone package in the Microsoft Update Catalog here.

 
  1. The .NET Framework 4.7 Language Packs will also be available via WSUS, both to support the upgrade of previous language packs for .NET Framework and for computers, that either have the localized version of the base operating system or have one or more Multilingual User Interface (MUI) packs installed.
 
  1. Enterprises that have a specific need to block offering .NET Framework 4.7 on computers that directly connect to Microsoft Update servers can do so by deploying the blocker registry key described in following Microsoft Knowledge Base:

KB4024204:  How to temporarily block the installation of the .NET Framework 4.7 and its corresponding language packs

]]> Demystifying "Dual Scan" https://docs.microsoft.com/archive/blogs/wsus/demystifying-dual-scan Fri, 05 May 2017 11:28:54 GMT https://blogs.technet.microsoft.com/wsus/?p=2665 Update: a new post on the upcoming feature to support Dual Scan in the on-premises scenario has been published. Please refer to that post for details on how to use the new policy and what to expect going forward. How Dual Scan came to be With the combination of Windows Update for Business and Windows as a Service, we effectively created a new paradigm for update management, one that does not require administrators to approve every update manually before it can be deployed.  We believe that this automated management solution is the future, and we want to ensure that everyone who wants to move to modern (i.e., Cloud-first) update management can do so.  The biggest adoption blocker facing prospective customers of this new management paradigm was that they had their own third-party and line-of-business applications that were just as necessary as Microsoft updates, and Windows Update for Business wouldn’t serve those.  Until modern update management supported this scenario, those needs would certainly keep on-premises admins tethered to their current infrastructure.   What Dual Scan is Dual Scan is a Windows Update (WU) client behavior that debuted in 1607 and was designed to bridge exactly this gap.  It is for the enterprise that wants WU to be its primary update source while Windows Server Update Services (WSUS) provides all other content.  In this scenario, the WU client automatically scans against both WSUS and WU, but it only accepts scan results for Windows content from WU.  Stated another way, anything on WSUS that resides in the “Windows” product family is ignored by the Dual Scan client.  This is to avoid the “two masters” problem that can occur when there are multiple equally valid sources of truth for a given set of updates.  Dual Scan is automatically enabled when a combination of Windows Update group policies [or their MDM equivalents, or the underlying registry keys corresponding to either set of policies] is configured:
  • Specify intranet Microsoft update service location (i.e., WSUS)
  • Either of the policies belonging to Windows Update for Business
    • Select when Feature Updates are received
    • Select when Quality Updates are received
  How Dual Scan might affect you Prospective Cloud-first customers might appreciate this feature, but what about those that want to continue managing updates the way they have for years?  To those customers, Dual Scan introduces an unwanted loss of control.  Prior to Windows 10, you couldn’t accidentally upgrade a managed machine to a new build simply by scanning against Windows Update (WU) because only quality updates were provided via that channel.  At that time, administrators were unconcerned about their clients scanning against WU because it could never lead to any significant changes in the client state.  With feature updates being offered on WU, there is now a possibility that a client managed through WSUS or Configuration Manager can receive a feature update that was not approved by its administrator.  This will happen if a managed user clicks the “Check online for updates from Microsoft Update.” link: dual-scan-with-link Because on-premises admins were justifiably concerned about this scenario, they elected to enable the WU for Business policy that allowed them to select when feature updates were received (specifically, setting Branch Readiness to Current Branch for Business), which had the intended effect: scans against Windows Update no longer pushed the unapproved feature updates.  However, this configuration also satisfied the criteria for enabling Dual Scan, which resulted in the machine essentially no longer being controlled by WSUS or Configuration Manager for the purposes of Windows updates.  Therein lies the confusion: how can you keep unapproved feature updates from installing while maintaining control of update management with your existing on-premises tools?       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.    What you can do in the meantime If you need to unblock this scenario immediately, then we recommend the following workaround applied to all managed clients:
  1. Set all WU for Business policies to Not Configured.  This ensures that you are not in Dual Scan mode. 
  2. Verify that you have installed the November 2016 Cumulative Update for 1607, or any Cumulative Update more recent. 
  3. Enable the group policy System/Internet Communication Management/Internet Communication settings/Turn off access to all Windows Update features
  4. In an elevated command prompt, run “gpupdate /force”, followed by “UsoClient.exe startscan”
  5. Open the Windows Update UI (wait for the scan to complete), and observe:
Windows Update UI with no Check online link These steps allow you to perform scans against WSUS/Configuration Manager and access the Microsoft Store, and will prevent feature updates from being installed unexpectedly on machines with this configuration.  This configuration does not allow for any update content to be installed via Windows Update, so if this is a key requirement for your deployment, then our recommendation is to wait for the update to 1607 coming in a few months. You might have also heard something about “Remove access to all Windows Update features,” which sounds very much like the policy recommended above.  Please note that the behavior of “Remove access to all Windows Update features” is quite different, and should not prove useful in this scenario. ]]> Steps to resolve error 0xc1800118 https://docs.microsoft.com/archive/blogs/wsus/resolving-error-0xc1800118 Wed, 21 Sep 2016 18:04:09 GMT https://blogs.technet.microsoft.com/wsus/?p=2635 (Alternative title: "Help, I followed the steps provided earlier and I'm still seeing failures!" This applies to anyone who missed KB 3159706 when it was offered as a hotfix to Windows Server 2012/R2, and who subsequently enabled synching of Upgrades in their environment before patching WSUS.  The Upgrades that were likely downloaded most recently happen to be for the Windows 10 1607 feature update, but the steps referenced could be modified to suit a different set of content.) In this scenario, WSUS has downloaded content that it cannot use.  Because parsing only happens once, and WSUS does not know what “Upgrades” are without having installed KB 3159706, it incorrectly identifies the upgrade as a quality update and saves it to the SUSDB (and managed clients) as such.  This will cause any future deployment of this content to fail until the patch is applied, unusable content is purged, and WSUS properly syncs the information. If the symptom seems familiar, it is because the guidance for KB3095113 addresses a similar class of issue.  The steps detailed in that post are sufficient for repairing a WSUS that has downloaded unencrypted feature updates, but encrypted content involves a few more steps in order to fully clean your WSUS and its affected clients.  For information on why Upgrades are now being encrypted, please refer to our earlier blog post. Full coverage of error 0xc1800118 (and how to clean your environment after downloading unsupported encrypted Upgrades to WSUS) can be found in KB 3194588, which was created to help address these failures in the wild.  Feel free to share questions and feedback for that KB by using the comments section for this post.  Finally, several folks shared some PowerShell advice in the comments section for the post regarding KB3095113: you may find it worthwhile to review that if the steps published do not quite fit your needs.  ]]> Update on WSUS 3.0 SP2 End of Life https://docs.microsoft.com/archive/blogs/wsus/update-on-wsus-3-0-sp2-end-of-life Thu, 15 Sep 2016 10:34:12 GMT https://blogs.technet.microsoft.com/wsus/?p=2615 update to the extended support lifecycle for WSUS 3.0 SP2 (WSUS 3.2).  We received feedback that ending this product's life in July 2017 would cause a significant disruption for those Windows Server 2008/R2 deployments that planned to rely upon it until January 2020.  As such, the end of life for this product is now January 2020. For those that currently rely on WSUS 3.2, please use this extension as an opportunity to plan a smooth transition to WSUS 4.0 (Windows Server 2012 or 2012 R2) or even our newest offering (Windows Server 2016) that will be available later this year.  Especially for larger businesses, migrating a WSUS hierarchy is nontrivial, and may take much of the extra time that has been granted for this operation.  We've assembled a collection of resources that will help inform your migration efforts; should you have any trouble with the process, feel free to reach out on our TechNet forum for assistance. Finally, it bears repeating: if you plan to deploy Windows 10 your environment, yet are still using WSUS 3.2, then we strongly recommend considering a migration sooner rather than later.  WSUS 3.2 cannot today and will not in the future be able to fully support Windows 10 servicing (specifically feature updates), and in order to experience the true vision for Windows as a service, you'll need to use WSUS 4.0 or later.]]> The long-term fix for KB3148812 issues https://docs.microsoft.com/archive/blogs/wsus/the-long-term-fix-for-kb3148812-issues Thu, 05 May 2016 11:44:42 GMT https://blogs.technet.microsoft.com/wsus/?p=2575 new update is available for Windows Server 2012 and 2012 R2.  This update requires manual steps in order to complete the installation. While the KB itself covers those steps, this post provides additional details on the release.  

What KB3159706 does

Windows 10 feature updates (denoted by the "Upgrades" classification in WSUS) are staged in encrypted packages to Windows Update several days prior to the actual go-live date.  This is to ensure that we can release to all regions simultaneously.  The Windows 10 client has been able to decrypt these packages since RTM; however, WSUS was not able to do this.  Until now, we have been manually decrypting these packages prior to releasing to the WSUS channel, the process of which is both time consuming and error prone.  KB3159706 introduces this functionality to WSUS for Windows Server 2012/R2, such that it can now natively decrypt this content.  Skipping this KB means not being able to distribute the Windows 10 Anniversary Update, or any subsequent feature update, via these platforms.  Note that Windows Server 2016 will have this functionality at RTM.  

How to deploy KB3159706

This update has been released through the WSUS and Catalog channels, so that it may be synched or imported to and subsequently deployed from your WSUS. For those that are currently unable to deploy using WSUS, we’ve also shipped this fix to Windows Update. If multiple WSUS servers in your environment are affected by the previous issue, then you can repair the topmost server using Windows Update, and the rest through WSUS itself.  You'll need to manually select this KB for installation if you get it from Windows Update, as the update is marked Optional.  

If you installed KB3148812 or the test package

Both these updates modify the same files as KB3159706; since the latter is newer, it will simply replace the binaries. You can remove KB3148812 (if you don't recognize this KB, then no action is needed), but it is not necessary. In any case, your “For testing purposes only” watermark will disappear after you’ve removed the test package.  Our recommended order for this deployment is:
  1. Uninstall test package
  2. [Optional] uninstall KB3148812
  3. Install KB3159706
  4. Reboot your WSUS server
 

Still having issues?

This update involves changing some fundamental aspects of WSUS operation, and it may cause friction for some customers.  We're committed to getting you ready for the Anniversary Update (as well as ensuring that you can continue to take monthly updates), and we invite you to visit the WSUS forum if you're having issues deploying KB3159706 after following the KB guidance.]]> What you need to know about KB3148812, Part Two https://docs.microsoft.com/archive/blogs/wsus/what-you-need-to-know-about-kb3148812-part-two Fri, 22 Apr 2016 08:36:00 GMT https://blogs.technet.microsoft.com/wsus/2016/04/22/what-you-need-to-know-about-kb3148812-part-two/
  • KB3148812 requires some manual steps to complete its installation
  • Failure to perform these steps leads to two issues: loss of WSUS console and client scans against WSUS
  • Performing these steps (as listed today) fully resolves the WSUS console issue
  • There is a chance that you will see client scan failures even after performing the steps
    • This update contains critical functionality that needs to be in place before the Anniversary Update, but it does not need to be installed this week (e.g., there is no security fix that patches a known vulnerability).  Therefore, here are our recommendations:
    1. Until further notice, if you have not already installed this update, do not install KB3148812.
    2. If you have installed it and not yet performed the "wsusutil postinstall" step, then uninstall KB3148812.  If you're still seeing issues, then please Email Blog Author.
    3. If you have installed it and have already performed the manual steps recommended in a previous post, then please Email Blog Author so that we can work directly with you.
    UPDATE 5/5 The official repair for this issue (KB3159706) has been released.  A new blog post covers the details of this update.]]>         Known Issues with KB3148812 https://docs.microsoft.com/archive/blogs/wsus/known-issues-with-kb3148812 Tue, 19 Apr 2016 16:35:00 GMT https://blogs.technet.microsoft.com/wsus/2016/04/19/known-issues-with-kb3148812/ UPDATE: A newer post regarding KB3148812 is published at https://blogs.technet.com/b/wsus/archive/2016/04/22/what-you-need-to-know-about-kb3148812-part-two.aspx.

    Hi WSUS admins, just a quick post to let you know that we've received word of some issues happening (e.g., WSUS admin console is inaccessible, clients can't contact WSUS) in the wild after installing KB3148812.  It is critical functionality; however, you don't lose anything by skipping installation until we publish media that leverages this scenario, which will not be happening this month.  For now, feel free to remove the patch if it's causing you problems, and we'll get to the bottom of the issues that have been reported.  If you'd like to assist in resolving this, then please Email Blog Author and we'll follow up with you. 

    We appreciate your patience while we get this sorted.

    ]]>         Office 365 Client Updates via WSUS https://docs.microsoft.com/archive/blogs/wsus/office-365-client-updates-via-wsus Wed, 13 Apr 2016 16:43:24 GMT https://blogs.technet.microsoft.com/wsus/2016/04/13/office-365-client-updates-via-wsus/ Many of you have already seen the announcement that Configuration Manager can now be set up to sync Office 365 ProPlus updates directly.  This scenario is a direct response to requests for control of distributing these updates, and is an improvement on the past model (wherein Office 365 ProPlus updates circumvented Microsoft Update and WSUS altogether); however, there may be a nonzero cost to WSUS administrators that do not use Configuration Manager.  This post discusses how to mitigate that cost if you are affected by the change.

     

    The Office 365 Client category now appears in the WSUS Products and Classifications pane:

     

    If you’ve configured WSUS to sync this content, then you’ll see new updates in the console:

     

    Deploying these updates without Configuration Manager is not supported, so the content described above is essentially useless to a WSUS standalone administrator.  Depending on your situation, we recommend that you take one of the following actions:

    1. Deselect the Office 365 Client product so that WSUS does not sync this content from Microsoft Update. 

    2. For those running Small Business Server or other flavors that do not allow product filtering, decline all updates for the Office 365 Client product, which can be identified by the update title.

     

    Please let us know if there are any questions on this new content in WSUS.

    ]]>