Hi WSUS Admins,

The Microsoft .NET Framework 4.5.2 will be made available via Windows Server Update Services on 13 January 2015 .

You can learn more about .NET Framework 4.5.2 here.

Useful information about this release:

1. The .NET Framework 4.5.2 is being released for the following supported platforms: Windows Vista SP2, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows RT* and Windows 8.1 RT*.
2. The .NET Framework 4.5.2 Language Packs will also be available via WSUS for the same platforms. This is to both support the upgrade of previous language packs for .NET Framework 4 or 4.5 or 4.5.1 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.
3. Enterprises that have a specific need to block offering .NET Framework 4.5.2 on computers which can directly connect to Microsoft Update servers can do so by deploying the blocker registry key as described in following Microsoft Knowledge Base:
   KB2971109:  How to temporarily block the installation of the .NET Framework 4.5.2 and its corresponding language packs

* For Windows RT and Windows 8.1 RT the update will only be offered on Automatic Updates (not WSUS) channel.

Some of you may know that we are releasing the Windows 10 1511 feature upgrade, which is the first in-place upgrade for Windows 10, to WSUS in the next couple weeks.  To fully enable this deployment scenario, we shipped a patch to WSUS for WS12 and WS12R2 (KB 3095113).  Following this release, we received some questions regarding the applicability of this update.  Such questions included:

• Is this patch required to support Windows 10?

• What happens if I don’t install it?

• Should I wait for the DLC or other non-Hotfix release?

• Are there any known issues with the release?

The simple translation of "Support Windows 10"

You might be asking whether WSUS can recognize, sync/import, and distribute Windows 10 updates without having to receive a patch itself to enable this functionality.  If this is your concern, then you will not need any patches to enable this behavior.  While Windows 10 is indeed a monumental release in our history, from the WSUS perspective it's just another product in the list, and there's nothing new to Windows 10 updates (including security updates) that requires WSUS to be modified in order to handle them.  Administrators of WSUS 3.0 SP2 (including SBS 2011) and unpatched WSUS 4.0 will be able to deploy Windows 10 updates, but not feature upgrades.

Our preferred translation of "Support Windows 10"

One feature that makes Windows 10 special is delivering Windows as a service.  For the WSUS or Configuration Manager administrator, this means enabling feature upgrades to a new build of Windows.  These upgrades will be processed just like the usual updates, except that once they are approved for installation on WSUS/ConfigMgr-managed machines, they upgrade the entire build, not just some of its binaries.  If you're a member of the Windows Insider Program, then you've already been using this technology for a while (though not via WSUS).  Wiping and loading images in order to refresh your Windows builds can be nothing but a memory, and that's what is offered here.  It's especially useful because new Windows 10 builds will be released much more frequently than the one-to-three-year release cycle to which you might be accustomed.  In order for WSUS to support these feature upgrades, it needs to install a patch.  Feature upgrades introduce a new update content file type (and classification, called Upgrades) that will likely only be apparent to the WSUS admin: we've done our best to abstract the details from non-enterprise users.

As for the quality

Some folks are cautious about updates like KB 3095113 being released with boilerplate text that include verbiage such as “do not install unless you are experiencing this issue.”  Hotfix is our most expedient release vehicle, and we wanted to provide as much time to deploy this ahead of the Windows 10 1511 feature upgrade release to WSUS as possible.  We have tested it the same as we would any Windows Update release, so there is no reason to wait to install the update on your WSUS 4.0 servers.  For your convenience, we’ll be releasing the update more broadly to DLC and Catalog, as well as to WSUS itself, in the first quarter of 2016.  If you prefer to wait for those releases, then please review the caution described next.

Important caution

WSUS may be able to see the Windows 10 1511 feature upgrade even if it can’t properly download and deploy the associated packages.  The feature upgrades will become visible as soon as the “Upgrades” classification is checked in the WSUS options for Products and Classifications.  If you attempt to sync any Upgrades without having first installed the recent patch, then you will populate the SUSDB with unusable data that must be cleared before Upgrades can be properly distributed.  This situation is recoverable, but the process is nontrivial and can be avoided altogether if you make sure to install the update before enabling sync of Upgrades.

What this means for you

If you are content to wipe and load images for Windows 10 in order to stay on a current build, then simply do not enable sync of Upgrades in your WSUS, and do what you usually do to upgrade your Windows builds.  However, if you ever intend to deploy Windows 10 and fully enable Windows as a service for your enterprise, then you'll want to deploy the recent patch.  Furthermore, the safest route is to enable sync of Upgrades in your WSUS only after you have installed this patch on all WSUS 4.0 serversthat service Windows 10 machines in your environment.

Your 1511 upgrade experience

The Windows 10 1511 feature upgrade will be available via WSUS in the next 1-2 weeks (which is when you’ll see the new Upgrades classification), and it will apply to Windows 10 RTM as well as Windows 7 and Windows 8.1 machines.  If you are upgrading from Windows 10 RTM, then the process is highly automated: it will skip the application provisioning stage and all setup steps that require user interaction, and will preserve file associations and other settings by default.  Upgrading from Windows 7 and Windows 8.1 via WSUS will require some end user interaction because the entire platform is changing, not just a build.

Feel free to post any questions below, and we'll clarify as needed.

Hi WSUS Admins,

The Microsoft .NET Framework 4.6.1 will be made available via Windows Server Update Services for Windows 7 SP1 and Windows Server 2012 R2 platforms on 26 January 2016 and this blog highlights some of the key aspects.

The .NET Framework is a development platform for building apps for Windows, Windows Phone, Windows Server, and Windows Azure. The .NET Framework 4.6.1 is a highly compatible, in-place update to the .NET Framework 4, 4.5, 4.5.1, 4.5.2 and 4.6. The .NET Framework 4.6.1 can be installed fresh or can be used to upgrade your previous .NET 4 or 4.5 or 4.5.1 or 4.5.2 or 4.6 installation. Applications built against and running on .NET 4, 4.5, 4.5.1, 4.5.2 or .NET 4.6 will automatically roll forward to using the newer .NET 4.6.1 runtime without any need to recompile the application. 

The .NET Framework 4.6.1 installs side by side with older Framework versions lower than .NET 4 such as .NET 3.5 SP1. Applications that are based on earlier versions of the Framework such as .NET Framework 3.5 SP1 will continue to run on .NET 3.5 SP1 and will not automatically roll forward to using .NET 4.6.1.

You can learn more about .NET Framework 4.6.1 here.

Useful information about this release:

1. The .NET Framework 4.6.1 and its corresponding language packs are being released via WSUS and WU for Windows 7 SP1 and Windows Server 2012 R2.  For other platforms, such as Windows 8.1, Windows Server 2008 R2 SP1 or Windows Server 2012, an offline installer is available here.
2. The .NET Framework 4.6.1 Language Packs will also be available via WSUS, both to support the upgrade of previous language packs for .NET Frameworks 4, 4.5, 4.5.1, 4.5.2, 4.6 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.
3. When you synchronize your WSUS server with Microsoft Update server (or use Microsoft Update Catalog site for importing updates), you will see that there are two updates with .NET Framework 4.6.1 being published for each platform. The difference in the updates is scoped to the different applicability logic for targeting different computers. Please read the details included in the description of the respective update to get more information. We recommend that you import both the updates, if you plan to deploy .NET Framework 4.6.1 in your Enterprise.
   
   • One of the .NET Framework 4.6.1 updates will install only on computers that have an earlier version such as .NET 4, 4.5, 4.5.1, or 4.5.2 installed
   • The other .NET Framework 4.6.1 update will install on those computers that either have .NET 4.6 installed or no .NET Framework installed.
4. Computers that do not have .NET Framework 4.5.2 or a higher version installed with be offered both .NET Framework 4.5.2 and .NET Framework 4.6.1. You have an option to choose the .NET Framework version you need.
5. Enterprises that have a specific need to block offering .NET Framework 4.6.1 on computers which can directly connect to Microsoft Update servers can do so by deploying the blocker registry key as described in following Microsoft Knowledge Base:  

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

As indicated in a previous post, we are making changes to WSUS 4.0 and later that will provide a smoother Windows 10 servicing experience.  Because WSUS 3.0 SP2 is already in extended support (receiving no support at all after July 2017), and we are not shipping these improvements further down-level, it is a good idea to start planning your WSUS migration now.  Here is some guidance on how to respond to the recent changes based on your current situation, with the assumption that you intend to deploy Windows 10 in your environment.

WSUS 3.0 SP2 standalone

For this scenario, Microsoft recommends setting up a new WS12R2 or (depending on when you deploy) WS16 server with WSUS and migrate your existing SUSDB to it.  For those unfamiliar, this is supported: TechNet has guidance on how to perform a WSUS migration.  Making this investment ensures that your environment will be capable of taking advantage of all the Windows 10 servicing improvements coming to WSUS in future updates.

WSUS 3.0 SP2 with Configuration Manager

The operative question is whether you want to deploy feature upgrades via WSUS instead of using task sequences, MDT, or other media-based deployment tools.  If you need this functionality, then Microsoft recommends migrating to a newer WSUS platform, same as for the standalone scenario.  If you intend to rely on media-based deployment for your upgrades, then you could continue using your setup as it is today; however, please be aware that any difficulties you experience with using WSUS 3.0 SP2 for Windows 10 servicing might not be addressed, and that hotfixes cannot be requested for this product.

SBS 2008 and SBS 2011 (which uses WSUS 3.0 SP2)

Here the recommendation is slightly different.  If you have need of third-party software update management, then investigating your options to migrate your WSUS deployment to a member server running Windows Server 2012 or later will prepare your environment for the best Windows 10 servicing experience.  If you do not require third-party software updates to be distributed via WSUS, then you might consider configuring your Group Policy settings to let Windows Update for Business manage your Windows 10 updates instead.  This solution is ideal for administrators that want minimal daily complexity because it can provide a mostly hands-off experience after initial configuration, and it makes staying current with the latest Windows 10 builds and cumulative updates significantly easier.

To summarize

Our story for how we support the new servicing model in existing tools will continue to improve in subsequent releases through additional features that support key scenarios.  During this time, WSUS 3.0 SP2 will remain in the old servicing model.  Technically, it can provide minimal Windows 10 update support (i.e., sync and distribute security updates), but the experience is less than ideal.  As an example, the Windows 10 machines will display as “Windows Vista” for those remaining on WSUS 3.0 SP2.

As we move forward, we will continue to update existing guidance and provide recommended best practices for smoother navigation through our new servicing model.

(Alternative title: "Help, I synched Upgrades before installing the patch!" 

This applies to anyone who missed KB 3095113 when it was offered as a hotfix, and subsequently enabled synching of Upgrades in their environment.  The upgrades that were downloaded happen to be from the Windows 10 1511 feature upgrade, but these steps could be modified to suit a similar purpose for 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 3095113, it incorrectly identifies the upgrade as a regular update and saves it to the SUSDB as such.  In order to remedy this, you must perform the following sequence of steps on the WSUS servers as specified in the table below (where "USS" represents "upstream server"):

Some workarounds propose that you delete these entries from the SUSDB via SQL queries, but we do not recommend directly modifying database content.  The supported way to remove update content is with PowerShell commands [from an elevated session] as described below.  Again, be sure that you perform the deletion step on the WSUS server that is highest in your hierarchy first, and then work your way down; otherwise, your deletions may be replaced by the USS on the next sync attempt. 

// disable Upgrades classification on local WSUS server

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable  

// delete all update content on the current server belonging to the 1511 release

$s = Get-WsusServer

$s.SearchUpdates(“version 1511, 10586”) | foreach { $s.DeleteUpdate($_.Id.UpdateId) } 

// enable Upgrades classification

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification 

// perform full sync

$sub = $s.GetSubscription()

$sub.StartSynchronization()

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.

UPDATE: A newer post regarding KB3148812 is published at http://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.

Here are the facts:

1. KB3148812 requires some manual steps to complete its installation
2. Failure to perform these steps leads to two issues: loss of WSUS console and client scans against WSUS
3. Performing these steps (as listed today) fully resolves the WSUS console issue
4. 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:

• Until further notice, if you have not already installed this update, do not install KB3148812. 
• If you have installed it and not yet performed the "wsusutil postinstall" step, then uninstall KB3148812. 
• 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

We have identified the root cause for the issue and are currently testing a fix.  Thanks to those that reached out to us for a more expedient solution than waiting for the next update; we look forward to hearing your results.  Anyone else who is in the last scenario in the list above (i.e., broken and cannot uninstall or restore to a previous WID), please Email Blog Author so that we can get you up and running as soon as possible.  We'll be sending out a second round of invitations to test on Monday (PDT), for those that are in major pain.

Marta Barillas also wrote a significant portion of this blog posting.

Some customers have indicated that some update files are not being downloaded by WSUS after approval, which results in those updates being unavailable to clients.

For an update to be offered to clients, the following needs to happen:

1. Update must be approved to a target group in WSUS.

2. Update files must be available; so if WSUS is configured to store content locally, the update files must be successfully downloaded by WSUS.

Check if WSUS is configured to store content locally

The setting is controlled by a checkbox in the WSUS console.

When this is selected, if the update files fail to download to WSUS, the update will not be offered to Clients even though it has been approved.

Troubleshooting when WSUS is configured to store content locally

First, check if WSUS is syncing from another (upstream) WSUS server. (We’ll refer to the upstream WSUS server as USS and the downstream WSUS server as DSS henceforth).

If WSUS is syncing from another WSUS server, verify that the USS has the update files available by looking in the content directory on the USS. If the update files do exist on the USS, make sure that the DSS has access to:

1. the WsusContent folder on the USS
2. the root folder of the DSS WsusContent folder

If files are missing because they were never downloaded; ensure that files are downloaded by the Upstream WSUS (USS) and retry the download of the files on the Downstream WSUS (DSS).

If files are missing because the update has been declined and Cleanup Wizard has deleted the files from USS; proceed to decline the update from the DSS as well.

Note that in a WSUS hierarchy the Cleanup Wizard is recommended to be run from the bottom to the top in order to avoid DSS requesting updates that are no longer available on the USS.

Instructions for using the Server Cleanup Wizard are available on TechNet.

If files are missing because somehow they got deleted (not through WSUS Clean Up wizard); run Reset on USS and after files are available, retry the download of the files from the DSS. Please note that resetting a WSUS server can be a time consuming operation, as the reset happens for all the updates.

In order to run Reset, run the following command as an administrator:
%SystemDrive%\Program Files\Update Services\Tools\WsusUtil.exe reset

For help information run:
%SystemDrive%\Program Files\Update Services\Tools\WsusUtil.exe help reset

If WSUS is syncing from MU (there is no USS), verify that the update has not been Expired; otherwise it means that the update is no longer available. To verify that the update exists, search for it in the Microsoft Update Catalog.

•  If the update is no longer available from MU, Decline the update from the WSUS.

•  If the update exists, verify that WSUS has access to the root folder of the WsusContent folder.

The WSUS Team

We recently announced on the Microsoft Update Product Team Blog a set of changes made to the Windows Update Agent. In an effort to provide additional protection for our WSUS customers, we are releasing an update that enhances the security of Windows Update, the Microsoft Update (WU/MU) Client, and Windows Server Update Services. The update applies to WSUS 3.0 SP2, as well as the WSUS role running on Windows Server 2012 and Windows Server 2012 R2.

Improvements include further hardening of the infrastructure used by WU/MU client and the communication channel between WU/MU Client and Service. Additionally, the communication channel between WSUS and WU/MU service has been hardened. This update to WSUS also rolls up all prior updates.

Details on the changes to the WU/MU client can be found at KB 2887535.

Details and additional considerations for the update to WSUS can be found at KB 2938066.

Downloads

The following files are available for download from the Microsoft Download Center:

Hi WSUS Admins,

The Microsoft .NET Framework 4.5.2 will be made available via Windows Server Update Services on 13 January 2015 .

You can learn more about .NET Framework 4.5.2 here.

Useful information about this release:

1. The .NET Framework 4.5.2 is being released for the following supported platforms: Windows Vista SP2, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows RT* and Windows 8.1 RT*.
2. The .NET Framework 4.5.2 Language Packs will also be available via WSUS for the same platforms. This is to both support the upgrade of previous language packs for .NET Framework 4 or 4.5 or 4.5.1 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.
3. Enterprises that have a specific need to block offering .NET Framework 4.5.2 on computers which can directly connect to Microsoft Update servers can do so by deploying the blocker registry key as described in following Microsoft Knowledge Base:
   KB2971109:  How to temporarily block the installation of the .NET Framework 4.5.2 and its corresponding language packs

* For Windows RT and Windows 8.1 RT the update will only be offered on Automatic Updates (not WSUS) channel.

Most of you know that we released the Windows 10 1511 feature upgrade, which is the first in-place upgrade for Windows 10, to WSUS in December 2015.  To fully enable this deployment scenario, we shipped a patch to WSUS for WS12 and WS12R2 (KB 3095113) in October 2015.  Following this release, we received some questions regarding the applicability of this update.  Such questions included:

• Is this patch required to support Windows 10?

• What happens if I don’t install it?

• Should I wait for the DLC or other non-Hotfix release?

• Are there any known issues with the release?

The simple translation of "Support Windows 10"

You might be asking whether WSUS can recognize, sync/import, and distribute Windows 10 updates without having to receive a patch itself to enable this functionality.  If this is your concern, then you will not need any patches to enable this behavior.  While Windows 10 is indeed a monumental release in our history, from the WSUS perspective it's just another product in the list, and there's nothing new to Windows 10 updates (including security updates) that requires WSUS to be modified in order to handle them.  Administrators of WSUS 3.0 SP2 (including SBS 2011) and unpatched WSUS 4.0 will be able to deploy Windows 10 updates, but not feature upgrades.

Our preferred translation of "Support Windows 10"

One feature that makes Windows 10 special is delivering Windows as a service.  For the WSUS or Configuration Manager administrator, this means enabling feature upgrades to a new build of Windows.  These upgrades will be processed just like the usual updates, except that once they are approved for installation on WSUS/ConfigMgr-managed machines, they upgrade the entire build, not just some of its binaries.  If you're a member of the Windows Insider Program, then you've already been using this technology for a while (though not via WSUS).  Wiping and loading images in order to refresh your Windows builds can be nothing but a memory, and that's what is offered here.  It's especially useful because new Windows 10 builds will be released much more frequently than the one-to-three-year release cycle to which you might be accustomed.  In order for WSUS to support these feature upgrades, it needs to install a patch.  Feature upgrades introduce a new update content file type (and classification, called Upgrades) that will likely only be apparent to the WSUS admin: we've done our best to abstract the details from non-enterprise users.

As for the quality

Some folks are cautious about updates like KB 3095113 being released with boilerplate text that include verbiage such as “do not install unless you are experiencing this issue.”  Hotfix is our most expedient release vehicle, and we wanted to provide as much time to deploy this ahead of the Windows 10 1511 feature upgrade release to WSUS as possible.  We have tested it the same as we would any Windows Update release, so there is no reason to wait to install the update on your WSUS 4.0 servers.  For your convenience, we’ll be releasing the update more broadly to DLC and Catalog, as well as to WSUS itself, in the first quarter of 2016.  If you prefer to wait for those releases, then please review the caution described next.

Important caution

WSUS may be able to see the Windows 10 1511 feature upgrade even if it can’t properly download and deploy the associated packages.  The feature upgrades will become visible as soon as the “Upgrades” classification is checked in the WSUS options for Products and Classifications.  If you attempt to sync any Upgrades without having first installed the recent patch, then you will populate the SUSDB with unusable data that must be cleared before Upgrades can be properly distributed.  This situation is recoverable, but the process is nontrivial and can be avoided altogether if you make sure to install the update before enabling sync of Upgrades.  If you have encountered this issue, then please stay tuned for an upcoming KB article that details the recovery steps.

What this means for you

If you are content to wipe and load images for Windows 10 in order to stay on a current build, then simply do not enable sync of Upgrades in your WSUS, and do what you usually do to upgrade your Windows builds.  However, if you ever intend to deploy Windows 10 and fully enable Windows as a service for your enterprise, then you'll want to deploy the recent patch.  Furthermore, the safest route is to enable sync of Upgrades in your WSUS only after you have installed this patch on all WSUS 4.0 servers that service Windows 10 machines in your environment.

Your 1511 upgrade experience

The Windows 10 1511 feature upgrade is available via WSUS today, and it will apply to Windows 10 RTM as well as Windows 7 and Windows 8.1 machines.  If you are upgrading from Windows 10 RTM, then the process is highly automated: it will skip the application provisioning stage and all setup steps that require user interaction, and will preserve file associations and other settings by default.  Upgrading from Windows 7 and Windows 8.1 via WSUS will require some end user interaction because the entire platform is changing, not just a build.

Feel free to post any questions below, and we'll clarify as needed.

Hi WSUS Admins,

The Microsoft .NET Framework 4.6.1 will be made available via Windows Server Update Services for Windows 7 SP1 and Windows Server 2012 R2 platforms on 26 January 2016 and this blog highlights some of the key aspects.

The .NET Framework is a development platform for building apps for Windows, Windows Phone, Windows Server, and Windows Azure. The .NET Framework 4.6.1 is a highly compatible, in-place update to the .NET Framework 4, 4.5, 4.5.1, 4.5.2 and 4.6. The .NET Framework 4.6.1 can be installed fresh or can be used to upgrade your previous .NET 4 or 4.5 or 4.5.1 or 4.5.2 or 4.6 installation. Applications built against and running on .NET 4, 4.5, 4.5.1, 4.5.2 or .NET 4.6 will automatically roll forward to using the newer .NET 4.6.1 runtime without any need to recompile the application. 

The .NET Framework 4.6.1 installs side by side with older Framework versions lower than .NET 4 such as .NET 3.5 SP1. Applications that are based on earlier versions of the Framework such as .NET Framework 3.5 SP1 will continue to run on .NET 3.5 SP1 and will not automatically roll forward to using .NET 4.6.1.

You can learn more about .NET Framework 4.6.1 here.

Useful information about this release:

1. The .NET Framework 4.6.1 and its corresponding language packs are being released via WSUS and WU for Windows 7 SP1 and Windows Server 2012 R2.  For other platforms, such as Windows 8.1, Windows Server 2008 R2 SP1 or Windows Server 2012, an offline installer is available here.
2. The .NET Framework 4.6.1 Language Packs will also be available via WSUS, both to support the upgrade of previous language packs for .NET Frameworks 4, 4.5, 4.5.1, 4.5.2, 4.6 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.
3. When you synchronize your WSUS server with Microsoft Update server (or use Microsoft Update Catalog site for importing updates), you will see that there are two updates with .NET Framework 4.6.1 being published for each platform. The difference in the updates is scoped to the different applicability logic for targeting different computers. Please read the details included in the description of the respective update to get more information. We recommend that you import both the updates, if you plan to deploy .NET Framework 4.6.1 in your Enterprise.
   
   • One of the .NET Framework 4.6.1 updates will install only on computers that have an earlier version such as .NET 4, 4.5, 4.5.1, or 4.5.2 installed
   • The other .NET Framework 4.6.1 update will install on those computers that either have .NET 4.6 installed or no .NET Framework installed.
4. Computers that do not have .NET Framework 4.5.2 or a higher version installed with be offered both .NET Framework 4.5.2 and .NET Framework 4.6.1. You have an option to choose the .NET Framework version you need.
5. Enterprises that have a specific need to block offering .NET Framework 4.6.1 on computers which can directly connect to Microsoft Update servers can do so by deploying the blocker registry key as described in following Microsoft Knowledge Base:  

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

As indicated in a previous post, we are making changes to WSUS 4.0 and later that will provide a smoother Windows 10 servicing experience.  Because WSUS 3.0 SP2 is already in extended support (receiving no support at all after July 2017), and we are not shipping these improvements further down-level, it is a good idea to start planning your WSUS migration now.  Here is some guidance on how to respond to the recent changes based on your current situation, with the assumption that you intend to deploy Windows 10 in your environment.

WSUS 3.0 SP2 standalone

For this scenario, Microsoft recommends setting up a new WS12R2 or (depending on when you deploy) WS16 server with WSUS and migrate your existing SUSDB to it.  For those unfamiliar, this is supported: TechNet has guidance on how to perform a WSUS migration.  Making this investment ensures that your environment will be capable of taking advantage of all the Windows 10 servicing improvements coming to WSUS in future updates.

WSUS 3.0 SP2 with Configuration Manager

The operative question is whether you want to deploy feature upgrades via WSUS instead of using task sequences, MDT, or other media-based deployment tools.  If you need this functionality, then Microsoft recommends migrating to a newer WSUS platform, same as for the standalone scenario.  If you intend to rely on media-based deployment for your upgrades, then you could continue using your setup as it is today; however, please be aware that any difficulties you experience with using WSUS 3.0 SP2 for Windows 10 servicing might not be addressed, and that hotfixes cannot be requested for this product.

SBS 2008 and SBS 2011 (which uses WSUS 3.0 SP2)

Here the recommendation is slightly different.  If you have need of third-party software update management, then investigating your options to migrate your WSUS deployment to a member server running Windows Server 2012 or later will prepare your environment for the best Windows 10 servicing experience.  If you do not require third-party software updates to be distributed via WSUS, then you might consider configuring your Group Policy settings to let Windows Update for Business manage your Windows 10 updates instead.  This solution is ideal for administrators that want minimal daily complexity because it can provide a mostly hands-off experience after initial configuration, and it makes staying current with the latest Windows 10 builds and cumulative updates significantly easier.

To summarize

Our story for how we support the new servicing model in existing tools will continue to improve in subsequent releases through additional features that support key scenarios.  During this time, WSUS 3.0 SP2 will remain in the old servicing model.  Technically, it can provide minimal Windows 10 update support (i.e., sync and distribute security updates), but the experience is less than ideal.  As an example, the Windows 10 machines will display as “Windows Vista” for those remaining on WSUS 3.0 SP2.

As we move forward, we will continue to update existing guidance and provide recommended best practices for smoother navigation through our new servicing model.

(Alternative title: "Help, I synched Upgrades before installing the patch!" 

This applies to anyone who missed KB 3095113 when it was offered as a hotfix, and subsequently enabled synching of Upgrades in their environment.  The upgrades that were downloaded happen to be from the Windows 10 1511 feature upgrade, but these steps could be modified to suit a similar purpose for 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 3095113, it incorrectly identifies the upgrade as a regular update and saves it to the SUSDB as such.  In order to remedy this, you must perform the following sequence of steps on the WSUS servers as specified in the table below (where "USS" represents "upstream server"):

Some workarounds propose that you delete these entries from the SUSDB via SQL queries, but we do not recommend directly modifying database content.  The supported way to remove update content is with PowerShell commands [from an elevated session] as described below.  Again, be sure that you perform the deletion step on the WSUS server that is highest in your hierarchy first, and then work your way down; otherwise, your deletions may be replaced by the USS on the next sync attempt. 

// disable Upgrades classification on local WSUS server

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable  

// delete all update content on the current server belonging to the 1511 release

$s = Get-WsusServer

$s.SearchUpdates(“version 1511, 10586”) | foreach { $s.DeleteUpdate($_.Id.UpdateId) } 

// enable Upgrades classification

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification 

// perform full sync

$sub = $s.GetSubscription()

$sub.StartSynchronization()

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.

UPDATE: A newer post regarding KB3148812 is published at http://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.

Here are the facts:

• 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 4/28

You may have noticed some changes to the blog format.  These changes were not planned by our team, and they resulted in some comments being deleted from the history, as well as the Email Blog Author link disappearing.  We’ve hyperlinked mentions of Email Blog Author in the post to allow you to still communicate with us (at the risk of being targeted by spam bots), so please use those.  In the meantime, we’ll see about getting those comments restored.  The changes were a surprise to us, so we’re still adjusting to the new layout and feature set.

Regarding the issue at hand:

We have identified the root cause for the issue and are currently testing a fix.  We’ve gotten a good number of positive results from those that offered to test the package, and are working out some corner case scenarios with the few that had issues.  Anyone else who is in Scenario #3 in the list above (i.e., broken and cannot uninstall or restore to a previous WID), please Email Blog Author (posting in the comments below is insufficient on its own) so that we can get you up and running as soon as possible.  Thanks to all who have helped out so far with road-testing this on short notice.  The original KB has been unpublished, along with the package, and we’re planning a new release to replace this one under a different KB.  Look for more specific timeline estimates in the next 1-2 days–and don’t worry, we aren’t releasing this on Friday.

A 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.

As you may have seen, there has been an 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.