Last Tuesday was December’s Patch Tuesday, it also featured the re-release of Exchange 2010 SP2 RU5 as the V2 of the update.  As a result Exchange administrators have been busy updating servers and installing patches.

If you read no further, remember only this – do not install Windows Management Framework 3.0 onto Exchange 2010 SP2 or Exchange 2007 servers!

Update 28-2-2014:   The system requirements for  Windows Management Framework 3.0 remain the same, and Exchange 2007 and 2010 are not listed.  Windows Management Framework 4.0 is now supported with the release of Exchange 2010 SP3 RU5, and Exchange 2013 SP1. For reference the text is here:

There have now been a few occurrences in the TechNet Exchange 2010 forums where people have just selected all the available updates from Microsoft Update and hit install.  This has caused a bit of an issue and is also on the Exchange Team blog.  Why you may ask?  Well the latest build of PowerShell, version 3.0, is now available as an optional download and is not currently supported with Exchange 2010 SP2.  Well it’s also not supported with Exchange 2007 either, but since I’ve been seeing this in the Exchange 2010 forums let’s focus on that.

While I do not want to dive into additional issues around patch management, and the fact that patch management is a required IT process, the main item I wanted to address in this post is around the fact that some organisations installed this update simply because it was there in the update screen with a particular status.  In an Exchange Risk Assessment interview this would lead to additional questions around testing and validating patches in a separate test lab.

We will look at Microsoft Update and also Windows Server Update Services (WSUS).

One justification posted on the forums for installing update 2506143 is that WSUS showed the update with a status of “important”, and because of that it was installed.  Please note that a WSUS administrator must have manually approved the update for installation, or created an auto–approval rule, and if this is the case then this need to be reviewed within your organisation as all updates that are to be installed onto servers must be carefully reviewed.  This is not an update that should have been approved for any Exchange 2007 or Exchange 2010 SP2 server!

Let’s look to see:

1. What Microsoft Update offered to a test Exchange 2010 server
2. The impact of a default WSUS approval
3. How to use PowerShell to tell WSUS that an update is optional

Microsoft Update

This shows Microsoft Update running on an Exchange 2010 SP2 RU3 server on Windows 2008 R2 SP1.  There are 11 important updates and 3 optional updates.

We can determine if MU or WSUS was checked by looking along the bottom of the screen.

Inspecting the optional updates shows no Windows Management Framework 3.0

Why is this you say?  Well on the Windows Management Framework 3.0 download page there are certain prerequisites, namely .NET 4.0 Framework.  This test lab has .NET 3.51 Framework installed and not 4.0, so Microsoft Update did not offer up the Windows Management Framework 3.0 update.  After installing .NET 4.0 from http://go.microsoft.com/fwlink/?LinkID=212547 let’s retest!

After Installing .Net 4.0 Framework  additional patches now show up from Microsoft Update.  There are now 18 important updates and 7 optional updates.

Inspecting the optional updates shows the below, where the Windows Management Framework 3.0 is now offered for installation:

Please note that this is an optional update, and without even clicking onto the link to get more information we see in the brief summary on the right hand side that this contains updates to WMI, PowerShell along with other bits of plumbing.

WSUS Installation

What if you are installing updates from WSUS?  While the same prerequisites, namely the .NET Framework 4.0, apply to an install of Windows Management Framework 3.0 from WSUS the user interface will vary slightly.  In this example I created a test WSUS group and approved update 2506143 for installation to the same Exchange 2010 server as shown above.    Note that there the important update category and no “Optional Updates”.

Clicking into the available updates, we see the Windows Management Framework 3.0 update that was approved for installation via WSUS.

So what’s going on here?  Why is this now “important” all of a sudden via WSUS and not optional?  Well WSUS does not display an option in the GUI to use the optional category and most people do not go further than that.  It is worthwhile again pointing out that WSUS will ONLY offer updates that the WSUS administrator has manually approved or created a WSUS auto-approval rule.  This shows the Windows Server 2012 WSUS console approving an update, note there is no optional selection.

Mark An Update As Optional In WSUS

WSUS does actually support an option to approve an update as “optional”.  How is this possible?

MSDN documents the API in “How to Approve Updates for Optional Install”.

I’m a simple cable plugger and the code sample there is a wee bit gnarly for me, so how can we proceed?  Well I know PowerShell, and PowerShell can directly load .NET classes – so let’s use PowerShell to fix this – huraaah!    A quick search on Bing using the optional approval method and the phrase “Scripting Guy” (as they always have great examples) led to this cool post.

In the introduction and subsequent Scripting Guy  blog posts they show how to connect PowerShell to the WSUS server, select the update[s] in question and then flag them for optional approval status.  One thing that I noted in the example code was that they run WSUS on port 80 TCP whereas I run on 8530 TCP and could not connect using those instructions.  The following code works when running locally on the WSUS server:

# Load up the required .NET assembly
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

#  Connect to the local WSUS instance
$Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer()

Moving on to actually setting the update as an optional approval.  First we need to know the update in question.   The full title of the Windows 2008 R2 update in WSUS is:

Windows Management Framework 3.0 for Windows Server 2008 R2 for x64-based Systems (KB2506143)

To Search for this in WSUS run:

$Wsus.SearchUpdates('Windows Management Framework 3.0 for Windows Server 2008 R2 for x64-based Systems (KB2506143)')

(Note that the PowerShell commands may wrap but are a single line)

This can then be saved into a variable called $Update

$Update = $wsus.SearchUpdates('Windows Management Framework 3.0 for Windows Server 2008 R2 for x64-based Systems (KB2506143)')

We need to specify to which group the update is to be approved.  All groups can be retrieved by running

$wsus.GetComputerTargetGroups()

In my lab this is the group called “PowerShell-3” and was saved into the variable called $Group”

$Group =$wsus.GetComputerTargetGroups() | where {$_.Name -eq "powerShell-3"}

Finally let’s approve the update for this group:

$Update[0].ApproveForOptionalInstall($Group)

Note that we are specifying the first element in the array, as this is what the method expects.  In my example there is only a single element in the array which is stored in the first available location.  Numbering starts at zero in case you had not figured that part out .

After all of our hard work, lets go back and check what the Exchange server now sees.  Previously there were 22 important updates, now there are still a total of 22 updates but the breakdown is different.  There is one optional update and 21 important ones!

What update is optional?

It’s the one that we marked as optional!

Conclusion

Patch management and testing remains a critical aspect of managing and maintaining any IT system, and  in the above example we saw how the default WSUS approval process can be enhanced to flag updates as “optional” within the corporate WSUS environment.

Cheers,

Rhoderick