Installing Exchange 2010 Service Pack 2

Exchange 2010 Service Pack 2 was released-to-web on Monday (December 5, 2011).

Containing literally hundreds of code corrections since service pack 1, plus several significant new features, service pack 2 is an important new release. I will not attempt to cover all of its details, that has been done-to-death on other web sites and blogs, including Microsoft's own. Instead, I'll share one new "gotcha" and give you my opinion on best practices for installing the service pack.

The "gotcha"? First, a little background: Address Book Policies (ABPs) are an important new feature contained within service pack 2. They depend on the Exchange 2010 architecture, where all client communication is routed through the Client Access Server role. However, one of the things happening behind the scenes in the Exchange 2010 architecture is that the CAS role also hosts the "NSPI protocol". NSPI stands for Name Server Provider Interface, and it is the mechanism used by messaging clients to access and manipulate address data stored in Active Directory (paraphrased from Microsoft's NSPI Protocol document, available here). Historically, NSPI was hosted by group catalog servers (i.e., domain controllers), because NSPI information isn't used by only Exchange.

Here is the kicker: when you install Exchange on a domain controller, Exchange will use the NSPI provider from the domain controller and not install it's own as part of the Client Access Server role. This means that Address Book Policies will not work on Exchange Servers that are also domain controllers. This means that ABPs do not work on any SBS servers, or on any other "kitchen-sink" servers that may exist. There is your "gotcha" - to use ABPs, you must run Exchange and domain controllers as separate servers.

Now, on to installing Exchange 2010 Service Pack 2. As always, the role installation order is Client Access, Hub Transport, Unified Messaging, Mailbox. Edge Servers can be done in any order.

In the best of all possible worlds, you simply double-click on setup.exe and you are done, right? In the best of all possible worlds, that may be true. But, few of us live in that special place. :-) So, there are some things that we can do to ensure that our service pack install is "smooth as silk".

My list is:

For CAS, first install the new prequisite required by SP2. To do this:

  1. Open an elevated PowerShell session
  2. Import-Module ServerManger
  3. Add-WindowsFeature Web-WMI
  4. Exit

If you are running Database Availability Groups (DAGs) on Windows Server 2008 R2, and you have not already installed it, install the hotfix from KB2550886 - A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working. For more information about this hotfix, see the Microsoft Exchange Team blog posting: Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2.

Stop all ForeFront services - this includes ForeFront EndPoint Protection (FEP, which is local anti-virus) and ForeFront Protection for Exchange (FPE, which is Exchange anti-virus and anti-spam).

Stop all local anti-virus services.

Stop all System Center agents (this includes services named "MOM" and "System Center Management" and any other agent that may attempt to load PowerShell or the Exchange Management Shell or any Exchange snap-ins or modules).

Stop the "Task Scheduler" service. This prevents any manually scheduled tasks, or those schedule by, for example, System Center Operations Manager, from firing up while you are installing a service pack a screwing it up.

(Optional) Install the schema update manually. To do this:

  1. Open an elevated PowerShell session, under an account which is an Enterprise Admin, Domain Admin, and Schema admin
  2. setup.com /ps
  3. exit

If you are using DAGs on the current server, then you need to mark the current server as "offline - undergoing maintenance". Exchange provides a script for that:

  1. Open the Exchange Management Shell (EMS)
  2. cd $exscripts
  3. .\StartDagServerMaintenance -ServerName ExDag01
  4. exit

Note: you must substitute the proper server name for ExDag01

Almost there! Start Task Manager, check the box for "Show processes for all users", and sort by Image Name. Verify that no instances of PowerShell.exe or MMC.exe are running. If there are, figure out why and get them closed.

Finally, apply the service pack.

From a cmd.exe prompt:

setup.com /m:upgrade

From setup.exe, simply double-click the setup.exe executable and follow the bouncing ball.

Next, I recommend a reboot of the server. Just because I'm old school. 

If you are using DAGs on the current server, then you need to mark the current server as "back online - ready for use". Exchange provides a script for that:

  1. Open the Exchange Management Shell (EMS)
  2. cd $exscripts
  3. .\StopDagServerMaintenance -ServerName ExDag01
  4. exit

Note: you must substitute the proper server name for ExDag01

That's it!

If you follow this process, you will have a very high likelihood of your service pack installation going smoothly and without challenges. Obviously, for any given customer environment, this process can be automated. Doing so for a generic environment would be quite challenging. If I learn of any other service pack challenges that can be mitigated, I'll either update this post or create a new one and link to this one.

Until next time...

If there are things you would like to see written about, please let me know.

Published Wednesday, December 07, 2011 7:52 AM by michael

Comments

No Comments