WSUS | Ward Vissers

Keeping WSUS Happy using PowerShell

Some time ago i found a great WSUS cleanup script. I used this at my demo lab and customer sites. WSUS need a little help

Someone need to deny all patches that are superseeded, this does not happen automatically.
Someone needs to cleanup old content, computers, patches and such, this does not happen automatically.
Someone needs to care for the database, this does not happen automatically.

https://github.com/DeploymentBunny/Files/tree/master/Tools/Invoke-WSUSMaint

The script will do the following

Connect to a database

you might need to change this in the script.

#For Windows Internal Database, use $WSUSDB = ‘\\.\pipe\MICROSOFT##WID\tsql\query’
#For SQL Express, use $WSUSDB = ‘\\.\pipe\MSSQL$SQLEXPRESS\sql\query’

Get the Superseeded Updates

Here is the Posh that fixes that:

$SuperSeededUpdates = Get-WsusUpdate -Approval AnyExceptDeclined -Classification All -Status Any | Where-Object -Property UpdatesSupersedingThisUpdate -NE -Value ‘None’ -Verbose
$SuperSeededUpdates | Deny-WsusUpdate –Verbose

Cleanup WSUS

We run each step sepratly, however, you can change that and run everything in one line…

Cleanup the DB

Last part runs sqlcmd using a .SQL file from MSFT Gallery, and yes, you can download and install the PowerShell tools for SQL and use that instead. Most of your customers dont have thoose tools installed, so sqlcmd.exe it is

Source: https://deploymentbunny.com/2016/02/03/working-in-the-datacenter-keeping-wsus-happy-using-powershell/

Tags: App, Change, Clean, CleanUp, Deploy, Deployment, Microsoft, Powershell, Script, SQL, Tools, Update, Updates, Windows, WSUS

Windows 10 1607 Windows Update Change

For those of you who have started deploying Windows 10 1607, you might notice a change in the behavior of the Windows Update agent for PCs that are configured to pull updates from WSUS. Instead of pulling the updates from WSUS, PCs may start grabbing them from peers on your network, leveraging the Delivery Optimization service for referrals to other PCs that have already obtained the content. This change should generally help reduce the amount of network traffic being generated for both quality (monthly) updates and feature updates, offloading that traffic from the WSUS server. It will add some additional traffic between each client PC and the Delivery Optimization service on the internet, as it has to talk to this internet-only service in order to get a list of peers.

If the Windows Update agent can’t talk to the Delivery Optimization service (due to firewall or proxy configurations), or if there are no peers able to provide the content, it will then go ahead and grab the content from the WSUS server.

There is a new Group Policy setting available if you want to disable this behavior, e.g. because you are already using BranchCache for peer-to-peer sharing. To do this, you need to set the “Download Mode” policy under “Computer Configuration –> Administrative Templates –> Windows Components –> Delivery Optimization” to specify “Bypass” mode, which will result in the client always using BITS to transfer the content from WSUS (with BranchCache jumping in to provide the peer-to-peer capabilities through its integration with BITS):

Of course to set this policy, you need the latest ADMX files, which can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=53430 and are also included in Windows 10 1607 and Windows Server 2016. (The “Bypass” setting wasn’t available in previous versions.) See https://support.microsoft.com/en-us/kb/3087759 for details on how to update the Group Policy central store with these latest ADMX files, if you are using a central store.

Source: https://blogs.technet.microsoft.com/mniehaus/2016/08/08/using-wsus-with-windows-10-1607/

Tags: 1607, 60, ADMX, BranchCache, Change, Delivery Optimization service, Deploy, Group Policy, Microsoft, Server, Server 2016, Template, Update, Updates, Version, Windows, Windows 10, WSUS

The Windows Server Update Services console gives Unexpected Error after KB3159706

Solution:
Manual steps required to complete the installation of this update

Open an elevated Command Prompt window, and then run the following command (case sensitive, assume “C” as the system volume):
```
"C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall /servicing
```
Select HTTP Activation under .NET Framework 4.5 Features in the Server Manager Add Roles and Features wizard.
Restart the WSUS service.

If SSL is enabled on the WSUS server

Assign ownership of the Web.Config file to the administrators group (run at an elevated command prompt):

takeown /f web.config /a

icacls "C:\Program Files\Update Services\WebServices\ClientWebService\Web.config" /grant administrators:f

Locate the Web.Config file in the following path:
C:\Program Files\Update Services\WebServices\ClientWebService\Web.Config

Make the following changes in the file.

Note This code sample represents a single text block. The line spacing is used only to emphasize the text changes, which are shown in bold.

<services>
          <service
                name="Microsoft.UpdateServices.Internal.Client"
                behaviorConfiguration="ClientWebServiceBehaviour">

               <!-- 
                  These 4 endpoint bindings are required for supporting both http and https
                -->
                <endpoint address=""
                        binding="basicHttpBinding"
                        bindingConfiguration="SSL"
                        contract="Microsoft.UpdateServices.Internal.IClientWebService" />
                <endpoint address="secured"
                        binding="basicHttpBinding"
                        bindingConfiguration="SSL"
                        contract="Microsoft.UpdateServices.Internal.IClientWebService" />

               <endpoint address=""
                        binding="basicHttpBinding"
                        bindingConfiguration="ClientWebServiceBinding"
                        contract="Microsoft.UpdateServices.Internal.IClientWebService" />
                <endpoint address="secured"
                        binding="basicHttpBinding" 
                        bindingConfiguration="ClientWebServiceBinding"
                        contract="Microsoft.UpdateServices.Internal.IClientWebService" />
          </service>
    </services>

Add the multipleSiteBindingsEnabled=”true” attribute to the bottom of the Web.Config file, as shown:

</bindings>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
</system.serviceModel>

https://support.microsoft.com/en-us/kb/3159706

Tags: 2012 R2, KB3159706, Microsoft, Server, Server 2012, SSL, Tools, Unexpected Error, Update, Updates, Windows, WSUS

Windows 8.1 Update (KB 2919355) prevents interaction with WSUS 3.2 over SSL

There is a known issue which causes some PCs updated with the Windows 8.1 Update (KB 2919355) to stop scanning against Windows Server Update Services 3.0 Service Pack 2 (WSUS 3.0 SP2 or WSUS 3.2) servers which are configured to use SSL and have not enabled TLS 1.2.

Issue Description

The problem is specific to the following scenario when all of the following are true

Client PC has installed Windows 8.1 Update KB 2919355
Windows 8.1 with Windows 8.1 Update KB 2919355 attempts to scan against WSUS 3.2 running on any affected platform:
- Windows Server 2003 SP2, or
- Windows Server 2003 R2 SP2, or
- Windows Server 2008 SP2, or
- Windows Server 2008 R2 SP1
HTTPS and Secure Sockets Layer (SSL) are enabled on the WSUS server
TLS 1.2 is not enabled on the server

Only users who have enabled HTTPS and have not enabled TLS 1.2 on their WSUS 3.2 servers and who are also using these WSUS 3.2 servers to manage PCs running the Windows 8.1 Update KB 2919355 are affected by this issue. Please note, while we do recommend the use of HTTPS on WSUS servers, HTTPS and TLS 1.2 are not enabled by default.

Workarounds

If you are using WSUS 3.2 on Windows Server 2008 R2, you may perform either of the following steps to restore the scan functionality if you have deployed the Windows 8.1 Update KB2919355.

Enable TLS 1.2 (follow the instructions under More Information > SCHANNEL\Protocols subkey), or
Disable HTTPS on WSUS

If you are using WSUS 3.2 on an operating system other than Windows Server 2008 R2, you may perform the following step to restore the scan functionality.

Disable HTTPS on WSUS

When Microsoft releases an update that resolves the issue, you may re-enable HTTPS on WSUS.

Microsoft plans to issue an update as soon as possible that will correct the issue and restore the proper behavior for Windows 8.1 Update KB 2919355 scanning against all supported WSUS configurations. Until that time, we are delaying the distribution of the Windows 8.1 Update KB 2919355 to WSUS servers.

You may still obtain the Windows 8.1 Update (KB 2919355) from the Windows Update Catalog or MSDN. However, we recommend that you suspend deployment of this update in your organization until we release the update that resolves this issue. You may also find the workarounds discussed in this article to be useful for testing this Windows 8.1 Update for your organization. Thank you for your patience during this time.

Tags: Deployment, Microsoft, Server 2003, Server 2008, Server 2008 R2, Windows, Windows 2012 R2, Windows 8, Windows 8.1, WSUS

MDT Packages & WSUS a very nice feature.

I long time ago I wrote a acticle mdt-automatisch-updates-via-wsus-laten-installeren-tijdens-het-deployen-van-het-os (Dutch) about using wsus with MDT.

After you deploy a Windows 7 SP1 machine updating takes a lot of time.

You can slipstream windows security updates when you deploy a machine… Windows 7 / Windows 8 / Windows 2008 R2 / Windows 2012.

How you do this: It’s quit simpley. Import de WSUS Content in to Packages.

The error is normal because not everything is imported.

Important:

Delete every time you do this. Update & Hotfix packages. If you don’t you will end in a error state when you deploy a machine.

Tags: MDT, Windows, Windows 2008, Windows 2008 R2, Windows 2012, Windows 7, Windows 8, WSUS

Windows 8 Features on Demand (.Net Framework 3.5)

Features on Demand

“Features on Demand (FoD)” is a new concept in Windows 8 that allows administrators and image builders to reduce the amount of space. .

When you install an application that’s ask for .Net Framework 3.5 that will be automatically installed. You don’t have to deploy it automatically with it…

In Windows 8, .Net Framework 3.5 is now a Feature on Demand. And to simplify the installation of common legacy versions of the .Net Framework, .Net 3.0 and 2.0 have been included in the same feature package as 3.5. That means if any of those three versions need to be installed, all the administrator needs to do is enable the single .Net Framework 3.5 feature in Windows 8.

Installation Sources

The .Net Framework 3.5 payload can be obtained from any of the following sources:

· Windows Update (WU)

· A Windows Image file (.wim) to which the payload has been added

· The \sources\sxs folder on the installation media

There are unique advantages to using each. The source can be specified for the environment using a new Group Policy setting. It can also be specified when installing .Net 3.5 manually on an individual machine or image.

The simplest scenario is one in which WU is accessible to both the machine and the user, and the machine is not configured to obtain updates from Windows Server Update Services (WSUS). In this case, when the feature is enabled, the user will be prompted for permission to download the update. If permitted, Windows will download the payload directly from Windows Update and install the feature. Done!

In more controlled environments, administrators might want to redirect such download requests to an alternate source such as a Windows Image file (.wim) to which the payload was added, or the\sources\sxs folder from the installation media. There might also be network , proxy, or security configurations that prevent users from directly accessing Windows Update. Additionally, WSUS does not currently support the payloads for Features on Demand, although it does support the subsequent patching of the features. So in environments where machines are configured to obtain updates from WSUS, administrators will need to configure the source for initial FoD installations.

To allow administrators to manage these scenarios, a new Group Policy setting was introduced in Windows 8 / Windows Server 2012: “Specify settings for optional component installation and component repair”, located under Computer Configuration\Administrative Templates\System:

This policy allows the administrator to configure the installation of Features on Demand and feature store repair operations to use only authorized locations.

When this policy is enabled, a network location (for example, a file server) can be specified for both repair of the feature store, and enabling features whose payloads were not originally added. The Alternate source file path can point to a \sources\sxs folder or a Windows image (WIM) file using the WIM: prefix. The repair WIM can be different than the initial WIM file used for installation. You can specify multiple paths by using “;” between the paths. Valid syntax is “wim:<path to wim>:<index>”. Or “<path to sxs folder>”.

Examples:

\\server\Win8Media\sources\sxs

wim:\\server\sourcewim\install.wim:3

If you select Never attempt to download payload from Windows Update, WU is not contacted during an installation or repair operation.

If you select Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS), attempts to add features (for example, .NET Framework 3.5) or repair the feature file store use Windows Update to download files. Target computers require Internet and WU access for this option. Normal servicing operations continue to use WSUS if it has been configured as a source.

Tags: Server 2012, Windows, Windows 8, WSUS

Issue with Windows Management Framework 3.0 on Exchange 2007 and Exchange 2010

Recently, Windows Update began offering the Windows Management Framework 3.0 as an Optional update. This includes all forms of update distribution, such as Microsoft Update, WSUS, System Center Configuration Manager and other mechanisms. The key bit here is that the Windows Management Framework 3.0 includes PowerShell 3.0.

Windows Management Framework 3.0 is being distributed as KB2506146 and KB2506143 (which one is offered depends on which server version you are running – 2008 Sp2 or 2008 R2 Sp1).

What does that mean to you?

Windows Management Framework 3.0 (specifically PowerShell 3.0) is not yet supported on any version of Exchange except Exchange Server 2013 (which requires it). If you install Windows Management Framework 3.0 on a server running Exchange 2007 or Exchange 2010, you will encounter problems, such as Rollups that will not install, or the Exchange Management Shell may not run properly.

We have seen rollups not installing with the following symptoms:

If rollup is installed through Microsoft Update, the installation might error with error code of 80070643
If rollup is installed from a download, the error displayed is “Setup ended prematurely because of an error.”
In both cases, event log might show the error with an error code of “1603”

Exchange Team adviced that Windows Management Framework 3.0 should not be deployed on servers running Exchange 2007 or Exchange 2010, or on workstations with the Exchange Management Tools for either version installed. If you have already deployed this update, it should be removed. Once the update is removed, functionality should be restored.

Tags: Exchange, Exchange 2007, Exchange 2010, Microsoft, Powershell, System Center, Tools, Windows, Workstation, WSUS

Microsoft Virtual Machine Servicing Tool (VMST) 2012

Virtual Machine Servicing Tool (VMST) 2012 is designed to work with System Center 2012 –Virtual Machine Manager (VMM), System Center 2012 Configuration Manager and Windows Server Update Services (WSUS) 3.0 SP2.
VMST 2012 helps you reduce IT costs by making it easier to update your offline virtual machines, templates, and virtual hard disks with the latest operating system and application patches—without introducing vulnerabilities into your IT infrastructure.
This Solution Accelerator includes the following components:

Brief Overview. Available online only on Microsoft TechNet. Summary for business and technical managers that briefly explains how this Solution Accelerator can fit into an organization’s IT infrastructure management strategy.
VMServicing_x64 and VMServicing_x86. Setup files for the tool, for 64 bit and 32 bit versions of Windows with System Center 2012 – Virtual Machine Manager.
Virtual Machine Servicing Tool Getting Started Guide. Provides information about how the tool works, explains prerequisites for the tool, and describes how to install and configure the tool.
VM_Servicing_Tool_2012_Release_Notes Notes provide information about this release, describe known issues in the tool, and include feedback instructions.

Download

Tags: Microsoft, System Center, View, Windows, WSUS

Microsoft Virtual Machine Servicing Tool

Brief Overview. Available online only on Microsoft TechNet. Summary for business and technical managers that briefly explains how this Solution Accelerator can fit into an organization’s IT infrastructure management strategy.
VMServicing_x64 and VMServicing_x86. Setup files for the tool, for 64 bit and 32 bit versions of Windows with System Center 2012 – Virtual Machine Manager.
Virtual Machine Servicing Tool Getting Started Guide. Provides information about how the tool works, explains prerequisites for the tool, and describes how to install and configure the tool.
VM_Servicing_Tool_2012_Release_Notes Notes provide information about this release, describe known issues in the tool, and include feedback instructions.

Download

Tags: Microsoft, System Center, View, Windows, WSUS

Running Windows Update on a TMG Firewall Fails with Result Code 80072EE2

Recently I have encountered a problem with the Windows Update client on a server with Forefront Threat Management Gateway (TMG) 2010 installed. The Error is: Windows could not search for new updates with error code: 80072EE2.