Since the release of Exchange Server 2016 Cumulative Update 3 (CU3), which added support for installing Exchange 2016 onto Windows Server 2016 servers, there’s been a series of reports in support forums and blog comments about errors that customers are seeing.
Now Microsoft has acknowledged that there is in fact a known issue, and there is no current workaround for it.
If you attempt to run Microsoft Exchange 2016 CU3 on Windows Server 2016, you will experience errors in the IIS host process W3WP.exe. There is no workaround at this time. You should postpone deployment of Exchange 2016 CU3 on Windows Server 2016 until a supported fix is available.
That’s all the detail that has been publicly released by Microsoft at this time, but the guidance is clear. You should deploy Exchange 2016 only on Windows Server 2012 R2 until further notice.
This security update resolves vulnerabilities in Microsoft Exchange Server. The most severe of the vulnerabilities could allow remote code execution in some Oracle Outside In Libraries that are built into Exchange Server. This issue might occur if an attacker sends an email message with a specially crafted attachment to a vulnerable Exchange Server computer. To learn more about this vulnerability, see Microsoft Security Bulletin MS16-108.
More information about this security update
The following articles contain more information about this security update as it relates to individual product versions.
- 3184736 MS16-108: Description of the security update for Exchange Server 2016 and Exchange Server 2013: September 13, 2016
- 3184728 MS16-108: Update Rollup 15 for Exchange Server 2010 Service Pack 3: September 13, 2016
- 3184711 MS16-108: Update Rollup 21 for Exchange Server 2007 Service Pack 3: September 13, 2016
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.