Archive

Archive for December, 2009

Updated: Installing Exchange 2010 Rollups on DAG servers – Now With a Script!

December 29, 2009 1 comment

Having had to install rollups on a bunch of Exchange 2010 servers recently, I took the info from the original post Installing Exchange 2010 rollups on DAG servers and combined it all into a PowerShell script. I also updated the original article to include steps using Exchange Management Console (EMC). Take a look at the original post for the updated info and script.

Installing Exchange 2007 & 2010 Rollups on Servers That Don’t Have Internet Access

December 16, 2009 Leave a comment

In today’s security concious organizations, many internal servers don’t have Internet access. This reduces the attack surface for the servers. However, some tasks require Internet access to some degree, such as Windows Updates. That can be mitigated by WSUS or System Center Configuration Manager. But Exchange rollups also look to the Internet, and not having Internet access can cause the rollup installation to take considerably longer, or even fail.

Exchange rollups use signed code, and IE will check http://crl.microsoft.com/pki/crl/products/CSPCA.crl for certificate revocation to validate the code signing. It’s here we time out if there is no Internet connection to that URL.

We can fix this easily by disabling certification revocation in Internet Explorer. Simply open IE, go to Tools>Internet Options>Advanced>Security. Find the “Check for publisher’s certificate revocation” option and uncheck the box.

Click OK and close everything up. Installing the rollup should go much quicker now, since the server won’t check for cert revocation.

If you’re still having other problems with rollup installation, such as managed services not starting (usually affecting Exchange 2007), you may need to tweak some config files. Microsoft has documented this at http://support.microsoft.com/default.aspx/kb/944752 and http://msexchangeteam.com/archive/2008/07/08/449159.aspx

Script: DAG-InstallRollup.ps1 – Installing Exchange 2010 Rollups on DAG Servers

December 15, 2009 3 comments

As you’ve probably heard, Microsoft recently released the first rollup package for Exchange 2010. Like the Exchange 2007 versions, installation on typical servers is fairly straightforward. However, when we get to Database Availability Group (DAG) servers, there are a few more steps involved. We’ll take a look at those steps here today.

When using DAGs, the idea is to provide a high availability solution. This can include having activated databases spread amongst 2 or more servers. This is a fabulous feature that is quite popular. But we have to take this into account when applying updates that will either stop services, or require a reboot. We’ll need to make sure there are no activated databases on the DAG server we’re installing the rollup on. To do this, we perform two steps: stop the server from activating any more databases, and take the activated databases and activate them (make them “live”) elsewhere. This will leave us with a DAG server that has no live mailbox connections, and thus, available for updating.

First, we’ll stop the current server from activating databases using some PowerShell. On the server you’re about to update, open Exchange Management Shell and run this:

Get-MailboxDatabaseCopyStatus –Server (hostname) | Suspend-MailboxDatabaseCopy –ActivationOnly –Confirm:$false

Note the “(hostname)”, which basically just says the local server – no need to put an actual server name there (ok, I’ll admit, I’m lazy). At this point, the server will continue to have databases kept up to date, but won’t activate any if another DAG member goes down. Now we perform a switchover, which takes all databases activated on this server and activates them on another DAG node instead. In this example, we’ll activate them on Ex2 using this:

Move-ActiveMailboxDatabase -Server (hostname) -ActivateOnServer Ex2

However, if this is a case where there are more than two nodes in the DAG, we could let the system automatically determine the best mailbox server to use by not specifying the -ActivateOnServer parameter, such as this:

Move-ActiveMailboxDatabase -Server (hostname)

In either case, enter “Y” at the prompt.

This can also be accomplished via the Exchange Management Console a couple of different ways. We can manually activate the individual databases on other DAG members. To do so, open EMC, and navigate to Organization Configuration>Mailbox. Find the database(s) that need to be activated on another server, right click, and choose Move Active Mailbox Database. Click Browse and pick the server you’d like to activate it on, as shown below, and click Move. When it’s done, click Finish. Do this for each of the databases currently activated on the server you want to update.


(click for larger image)

We can also do a full switchover, activating all databases on a single DAG server, or letting the wizard pick. To do so, in EMC, go to Server Configuration>Mailbox. Right click on the server you’re going to update, and choose Switchover Server. In the resulting box, as shown below, choose “Automatically choose a target server” to have Exchange pick the best server to activate a database on, or “Use the specified server as the target of the switchover” to manually pick a server (and then click browse and pick the server).


(click for larger image)

Click Ok, and the switchover will take place. When it’s finished, there is no confirmation that it’s done. You can look in EMC at Organization Configuration>Mailbox. On the Database Management tab, verify that all databases are mounted on a server other than the one you’re updating.

Once that’s finished, we install the rollup. There really isn’t much need to detail that here – just pick ‘next’ all of the way through. It will take some time to run. Click Finish when it’s done.

Once we’re sure the installation was successful, and all services are started, we enable the server to activate databases again using this:

Get-MailboxDatabaseCopyStatus –Server (hostname) | Resume-MailboxDatabaseCopy

This doesn’t activate databases right away – it just allows the server to do so if the activated copy on another DAG node (or the node itself) goes down.

Follow this same process for the remaining servers in your DAG. Disable activation, switchover, install the rollup, and resume activation.

Once all of the servers are updated, we need to make sure that each database is active on the correct server. Each database has a parameter called ActivationPreference that lists the order of preference that a database is activated on servers that hold a copy. This can be viewed in EMS by using

Get-MailboxDatabase | Select Name, ActivationPreference, Server

The Server field shows which server the database is currently activated on, as seen here:


(click image for larger version)

You could use EMC to manually activate the databases back on the original server, or use the code or script below.

Paul Flaherty posted a couple of one liners that we’ll use here. First, we’ll activate the databases on the correct servers using this:

Get-MailboxDatabase | Sort Name | ForEach {$db=$_.Name; $xNow=$_.Server.Name ;$dbown=$_.ActivationPreference| Where {$_.Value -eq 1};  Write-Host $db "on" $xNow "Should be on" $dbOwn.Key -NoNewLine; If ( $xNow -ne $dbOwn.Key){Write-host " WRONG" -ForegroundColor Red; Move-ActiveMailboxDatabase $db -ActivateOnServer $dbOwn.Key -confirm:$False} Else {Write-Host " OK" -ForegroundColor Green}}

This will essentially look at each database, determine which server has the preference of ’1′, and make sure the database is activated on that server.
(click image for larger version)

Then, we can verify that they are all activated correctly using another one liner from Paul:

Get-MailboxDatabase | Sort Name | ForEach {$db=$_.Name; $xNow=$_.Server.Name ;$dbown=$_.ActivationPreference| Where {$_.Value -eq 1};  Write-Host $db "on" $xNow "Should be on" $dbOwn.Key -NoNewLine; If ( $xNow -ne $dbOwn.Key){Write-host " WRONG" -ForegroundColor Red; } Else {Write-Host " OK" -ForegroundColor Green}}


(click image for larger version)

At this point, we have the rollup installed on all DAG members, and the databases are activated on the correct server. We can also take a script written by Bhargav Shukla to verify which servers have which rollup(s) installed. This is helpful in an environment with a lot of servers to help validate that they are all at the same patch level.

Update: I’ve created a quick PowerShell script that will perform many of these tasks. I used the commands listed here, as well as some basic error handling. Thanks to the contributions of others listed here, it’s now much easier. Perform steps 1 and 2 before installing the update, and 3,4, and 5 after the update.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Download

DAG-InstallRollup.zip

Also – if you’re installing the rollup on servers that don’t have Internet access, take a look at Installing Exchange 2007 & 2010 rollups on servers that don’t have Internet access

Set-Exchange2010FilterConfig.ps1 – Cleaner Configuration of the FilterPack for Exchange Server 2010

December 14, 2009 Leave a comment

One of the prerequisites for installing Exchange 2010 Hub Transport and/or Mailbox roles is the installation of the Microsoft Filter Pack. This registers IFilters so that Office 2007 attachements can be indexed. Once Exchange 2010 is installed, the filters must be registered in Exchange. Microsoft provides a PowerShell script that can be copied/pasted and used to acommplish this. But if you’ve run that script, you notice a bunch of messages about settings already existing. Also, once you’re done, you must restart the Exchange Search service.

I’ve cleaned up the PowerShell script a little to check if the setting already exists, and only attempt those that don’t. This yields a much cleaner console output. Also, the script will prompt, and execute, restating the search service. Once you’ve installed Exchange 2010, simply run the script.

Between this script and the previous script released under Automated prerequisite installation via PowerShell for Exchange Server 2010 on Windows Server 2008 R2, installation of Exchange 2010 is getting much more streamlined.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Download

Set-Exchange2010FilterConfig.zip

Set-Exchange2010FilterConfig.ps1 – changelog

December 14, 2009 Leave a comment

This is the changelog page for Set-Exchange2010FilterConfig.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v2.0 – 05-08-2010

  1. better detection of installed filter packs
  2. uses Filter Pack 2
  3. includes PDF iFilter pack
  4. menu

v1.0 – 12-14-2009

  1. initial version

Script: Set-Exchange2010Features.ps1 – Automated prerequisite installation for Exchange Server 2010

December 12, 2009 23 comments

Update: This version resolves two bugs and adds the Adobe PDF Filter Pack and Windows Update menu options.

A while ago, fellow Exchange MVP Anderson Patricio released a script to help automate some of the tasks required before installing Exchange 2010 on Server 2008 R2. While it’s fairly straightforward to do it manually, automating the tasks can help reduce errors and issues – especially for consultants who may install Exchange 2010 often. Not long after Anderson released his script, Paul Flaherty released a revised version Bhargav Shukla released a revised version that streamlined it a little and added some functionality. Now it’s my turn.

More of an exercise to learn a method in PowerShell than anything else, I took Paul’s version and added functionality to the script. Over time, that has increased exponentially, and has become the most popular script on this site.

While SP1 added the functionality to install the required Windows features, I find this method a little nicer, as some tasks can be performed in a more structure manner. This is handy if you’re building a bunch of servers and want a standardized, error-free installation. Tasks such as disabling IPv6, downloading the latest updates, installing required Windows features, etc. are now just a menu option away.

I’ll likely tweak this some more when I have more time. But I’ve used this to build probably a dozen Exchange 2010 boxes so far, and it’s worked well. I welcome any comments or suggestions.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Download

v3.3 Set-Exchange2010Features.v3.3.zip

v3.2 Set-Exchange2010Features.v3.2.zip

v1.0 Set-Exchange2010Prereqs.zip

Changelog

See the changelog for information on features added in each version

Update Rollup 1 (UR1) for Exchange Server 2010 Released

December 9, 2009 Leave a comment

Microsoft has released the following update rollup for Exchange Server 2010:

  • Update Rollup 1 for Exchange Server 2010 (976576)

If you’re running Exchange Server 2010, you need to apply Update Rollup 1 for Exchange 2010 to address the issues listed below.

Remember, you only need to download the latest update for the version of Exchange that you’re running.

Here is a list of the fixes included in rollup 1:

  1. 977439 Exchange Server 2010 users cannot open certain attachments when they access their mailboxes by using Outlook Web App
  2. 977551 Meeting requests that are sent to a room mailbox are not processed in Exchange Server 2010
  3. 977552 Exchange RPC Client Access service crashes in the Handler.dll that is located on an Exchange 2010 Client Access service server
  4. 977553 Exchange RPC Client Access service crashes in Parser.dll on the Exchange Server 2010 CAS server
  5. 977554 The subject or body of a message that is hosted in an Exchange Server 2010 mailbox is not set as expected
  6. 977555 The message body is inaccessible when the property conversion from PR_BODY_HTML to PR_BODY fails
  7. 977556 The body text of an e-mail message is invisible after you create exceptions for a recurring appointment or for a recurring meeting by using a CDO application together with Exchange Server 2010
  8. 977557 An E_FAIL error occurs when you create an exception to a meeting request by using a CDO application for a Microsoft Exchange Server 2010 mailbox
  9. 977558 A folder name is not changed when you try to move and then rename the folder in an Exchange Server 2010 mailbox by using the CopyFolder method of the IMAPIFolder interface
  10. 977559 The location of a meeting or an appointment is not updated on an Exchange Server 2010 mailbox
  11. 977560 Update fails when you use a CDO application to update a recurrence task on Exchange Server 2010
  12. 977561 VSS backup process stops responding when you try to perform a Volume Shadow Copy Service (VSS) backup for Exchange Server 2010 databases

Download the rollup here. It is also available on Microsoft Update.

UPDATE
NOTE:
 Microsoft Update can’t detect rollups for servers that are members of a Database Availability Group (DAG). Scott Schnoll has written an article at MSExchangeTeam.org about how to install the rollup on DAG members.

Installation Notes:

If you haven’t installed Exchange Server yet, you can use the info at Quicker Exchange installs complete with service packs and rollups to save you some time.

Microsoft Update can’t detect rollups for Exchange 2010 servers that are members of a Database Availability Group (DAG). See the post Installing Exchange 2010 Rollups on DAG Servers for info, and a script, for installing update rollups.

Update Rollups should be applied to Internet facing Client Access Servers before being installed on non-Internet facing Client Access Servers.

If you’re installing the update rollup on Exchange servers that don’t have Internet access, see “Installing Exchange 2007 & 2010 rollups on servers that don’t have Internet access” for some additional steps.