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.
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
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
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.
There is a known issue with the MS16-072/KB3163622 patch. This update will break GPO’s with faulty rights. Examples: Drives appear on domain systems that should be hidden, mapping drives don’t work, and other typical GPO settings aren’t getting applied.
To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
1. Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
2. If you are using security filtering (WMI), add the Domain Computers group with read permission.
ALT-F1 = Switches to the console
ALT-F2 = Switches to the DCUI
Restart the Management agents on an ESXi or ESX host
From the Local Console or SSH:
Log in to SSH or Local console as root.
Run these commands:
Microsoft is pleased to announce the release of the new MCSA: Windows Server 2016 certification.
The new MCSA can be earned by taking and passing the following three exams:
- 70-740 – Installation, Storage, and Compute with Windows Server 2016
- 70-741 – Networking with Windows Server 2016
- 70-742 – Identity with Windows Server 2016
Exam 740 is scheduled for beta release in early October 2016, with the other exams following soon after.
Individuals who currently hold either an MCSA: Windows Server 2012 or MCSA: Windows Server 2008 certification will be able to upgrade to the new 2016 certification through a single, upgrade exam:
- 70-743 – Upgrade Your Skills to MCSA: Windows Server 2016
Exam 743 is scheduled for beta release in late July 2016.
MOC courses corresponding to all four Windows Server 2016 exams are scheduled for release in September 2016, while practice tests will be available shortly after each exam beta period ends.
New options for specialization and continuing education through the MCSE program will be announced later this summer.
.Net 4.6.1 Support
Support for .Net 4.6.1 is now available for Exchange Server 2016 and 2013 with these updates. We fully support customers upgrading servers running 4.5.2 to 4.6.1 without removing Exchange. We recommend that customers apply Exchange Server 2016 Cumulative Update 2 or Exchange Server 2013 Cumulative Update 13 before upgrading .Net FrameWork. Servers should be placed in maintenance mode during the upgrade as you would do when applying a Cumulative Update. Support for .Net 4.6.1 requires the following post release fixes for .Net as well.
Note: .Net 4.6.1 installation replaces the existing 4.5.2 installation. If you attempt to roll back the .Net 4.6.1 update, you will need to install .Net 4.5.2 again.
AutoReseed Support for BitLocker
Beginning with Exchange 2013 CU13 and Exchange 2016 CU2, the Disk Reclaimer function within AutoReseed supports BitLocker. By default, this feature is disabled. For more information on how to enable this functionality, please seeEnabling BitLocker on Exchange Servers.
SHA-2 Support for Self-Signed Certificates
The New-ExchangeCertificate cmdlet has been updated to produce a SHA-2 certificate for all self-signed certificates created by Exchange. Creating a SHA-2 certificate is the default behaviour for the cmdlet. Existing certificates will not automatically be regenerated but newly installed servers will receive SHA-2 certificates by default. Customers may opt to replace existing non-SHA2 certificates generated by previous releases as they see fit.
Migration to Modern Public Folder Resolved
The issue reported in KB3161916 has been resolved.
This cumulative update fixes the following issues:
This cumulative update also fixes the issues that are described in the KB 3160339 MS16-079: Security update for Microsoft Exchange: June 14, 2016 and KB 3134844 Cumulative Update 1 for Exchange Server 2016
Microsoft Knowledge Base articles.
This update also includes new daylight saving time (DST) updates for Exchange Server 2016. For more information about DST, go to Daylight Saving Time Help and Support Center.
The Windows Server Update Services console gives Unexpected Error after KB3159706
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.
These 4 endpoint bindings are required for supporting both http and https
- Add the multipleSiteBindingsEnabled=”true” attribute to the bottom of the Web.Config file, as shown:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />