I previously posted about the Exchange Server Deployment Assistant. The Deployment Assistant asks you some questions about your particular Exchange environment and, based on your answers, it provides a checklist with instructions that are designed to help you deploy Exchange 2010 quickly and easily. Each step has a huge amount of valuable information to guide you through your deployment.

This great tool has recently been enhanced to include rich coexistence information for those interested in maintaining some users on-premises and some users hosted by Microsoft Office 365 for enterprises in the cloud. As of now, the available scenario is targeted solely at those organizations with a current Exchange 2003 on-premises implementation, but additional scenarios for supporting Exchange 2007 and Exchange 2010 will be coming soon.

The Exchange Server Deployment Assistant can be found here Be sure to bookmark it!

I often talk about the Exchange 2010 Mailbox role calculator, I’m sure everyone uses it (everyone should be using it!) during the planning phases of any Exchange 2010 deployment. If you have no idea what I am talking about, click here now!

There is an area on the input tab where you define the number of processor cores that will have deployed for each mailbox server within your primary and secondary data centres, as well as, enter the SPECint2006 rate value for the system you have selected. The SPECint2006 rate value often causes some confusion so I thought I would write this post to try and clarify what to enter in the SPECint2006 rate value field.

In previous versions of the Exchange 2010 Mailbox role calculator (prior to 12.8) you had to enter the “Adjusted Megacycles / Core” which meant that you needed to normalise your server platform against the baseline platform -Intel Xeon x5470 3.33GHZ processors (2x4 core arrangement) and enter that value. To get to this value, you had to find your rate value and then use the following formula to calculate the “Adjusted Megacycles / Core” value:

In version 12.8, the field name has changed to “SPECint2006 Rate Value” which means you no longer need to normalise your server platform against the baseline platform and you merely enter the rate value.

To find the rate value, go here, click on “Results”, highlight “CPU2006” and then select “Search CPU2006 Results”. Under “Available Configurations”, select “SPECint2006 Rates” and click Go. Under “Simple Request”, enter the search criteria (e.g. Processor matches x5550) and find the server and processor you are planning to deploy and take note of the result value.

For example, let's say you are deploying a Dell PowerEdge M710 8-core server with Intel x5550 2.67GHz processors (2670 Hertz); the SPECint_rate2006 results value is 240, simply go back to the Exchange 2010 Mailbox role calculator and select “8” in the “Processor Cores / Server” field and enter “240” in “SPECint2006 Rate Value” field. Easy, huh?

Exchange 2007 brought about a change in the way Exchange uses certificates and introduced us to the concept of a Unified Communications Certificate which makes use of Subject Alternative Names (SAN). While this is the recommended way to secure Exchange services, every now and then I come across a customer that already owns a wildcard certificate for their entire domain (eg. *.cgoosen.com) and would like to use this certificate instead.

One of the problems with wildcard certificates is that they don’t always play nicely with Outlook Anywhere. If the principle name on the certificate is not the same as the mail server FQDN Outlook may not authenticate correctly. When testing Outlook Anywhere connectivity with Exchange Server Remote Connectivity Analyzer (ExRCA) you may see something like this:

Additional Details would be similar to this:

The certificate common name *.domain.com doesn't validate against the mutual authentication string that was provided: msstd:mail.domain.com

The easiest way to correct this problem is to use Autodiscover to send the correct principle name to your Outlook clients. Use the Exchange Management Shell to configure Autodiscover settings by using the Set-OutlookProvider cmdlet

You can check the existing configuration by issuing the Get-OutlookProvider cmdlet

The command should look something like this:

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domain.com

I’m often asked by my customers and colleagues about Jetstress. While I always recommend that Jetstress be used to validate their storage design during an Exchange implementation, I’ve never really seen any good documentation to refer them to. Until now that is!

Neil Johnson from MCS has recently published a great whitepaper that explains the process and requirements for validating an Exchange storage solution prior to releasing an Exchange deployment into production. His whitepaper explains how Jetstress works, how to plan for and perform a test, and how to automate the process. His whitepaper, “Jetstress Field Guide”, can be used with any version of Exchange.

Download it here

The last month has seen the release of Update Rollup 1 for Exchange 2007 SP3 and Update Rollup 1 for Exchange 2010.

For a full list of the fixes included in Update Rollup 1 for Exchange 2007 SP3, see KB2279665

For a full list of the fixes included in Update Rollup 1 for Exchange 2010 SP1, see KB2407028

Note for Forefront Protection for Exchange users
For those running Forefront Protection for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after installing this rollup. Without these steps, the Information Store and Transport services will not start.

1. Before installing the rollup, disable ForeFront by using the "fscutility /disable" command
2. After rollup installation completes, re-enable ForeFront by running the "fscutility /enable" command

Download Links:

• Update Rollup 1 for Exchange 2007 SP3
• Update Rollup 1 for Exchange 2010 SP1

Earlier this year I post a 6 part post entitled “Securing Exchange 2010 with Forefront Threat Management Gateway (TMG) 2010” which covered colocating Exchange 2010 Edge and Forefront TMG 2010 on the same server to create a a single, secure point of entry for all mail related services.

When Exchange 2010 SP1 was released in late August many people started to report seeing the following error in their event log:

“Microsoft Forefront TMG Managed Control service fails to start and the event viewer will contain a message that the service terminated with the following error : %%-2146233088”

The reason for this is that SP1 removed some of the existing cmdlets, in particular get-antispamupdates which is used by TMG when spam filtering functionality is enabled.

The forefront team recently announced the release of Software Update 1 for Forefront TMG 2010 SP1. This update resolves the issue.

Download Software Update 1 for Forefront TMG 2010 SP1 here

In early 2009 I wrote an post entitled “Exchange 2007 SP1 Moving Mail Queue/Transport Dumpster”. This post is still one of the most frequently viewed posts on my blog so I thought it was time to post an update for Exchange 2010.

In Exchange 2010, the location of the queue database and queue database transaction logs are controlled by the QueueDatabasePath and QueueDatabaseLoggingPath parameters in the EdgeTransport.exe.config application configuration file. This file is located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory. To change the location of the queue database and queue database transaction logs, simple open this file in Notepad and locate the following values under

Change these paths to match your requirements and save the file.

Restart the Microsoft Exchange Transport service for these changes to take effect. Once restarted, you should notice that new Mail.que and Trn.chk files are created at the new QueueDatabasePath location and new Trn.log, Trntmp.log, Trnres00001.jrs, Trnres00002.jrs, and Temp.edb files at the new QueueDatabaseLoggingPath location.

There are a few things to note about this process. Firstly, If the target directory doesn't exist, it will be automatically created if the parent directory has the following permissions:

• Network Service: Full Control
• System: Full Control
• Administrators: Full Control

The existing queue database and log files are not moved. New files are created at the new location and existing database files are left at the old location. These old files are no longer used.

If you would like to change the location of the queue database but reuse the existing queue database files, you must move or copy the database files when the Microsoft Exchange Transport service is stopped.

I recently posted about the availability of Exchange 2010 SP1 and thought I would provide some feedback about the installation process.

Before installing SP1 for Exchange 2010, there are several updates and hot fixes that need to be installed first. An important thing to note is that all the Unified Messaging language packs other than US English (en-US) need to be uninstalled before upgrading the Unified Messaging server role. I have split these up then up by server role:

Hub Transport Role Prerequisites:
Microsoft Knowledge Base article 979099
Microsoft Office 2010 Filter Packs

Client Access Role Prerequisites:
Microsoft Knowledge Base article 982867 *requires a restart
Microsoft Knowledge Base article 979744 *requires a restart
Microsoft Knowledge Base article 983440 *requires a restart
Microsoft Knowledge Base article 977020
Knowledge Base article 979099

Mailbox Role Prerequisites:
Microsoft Knowledge Base article 979099
Microsoft Office 2010 Filter Packs

Unified Messaging Role Prerequisites:
Microsoft Unified Communications Managed API, Core Runtime 64-bit
Microsoft Server Speech Platform Runtime 64-bit
Microsoft Knowledge Base article 979099

In April I posted about some of the new features that will be available in Exchange 2010 SP1. The most notable of these is the ability to provision a user’s personal archive to a different mailbox database from their primary mailbox.

Many people have been eagerly awaiting the release of SP1, the good news is that it is now available for download. For more information, see this Exchange Team Blog entry.

To download Exchange 2010 SP1, click here.

I was running through the Exchange 2010 installation process earlier today, during the installation process, everything went really smoothly and I only had “green ticks”!

Once done, I opened the Exchange Management Console and saw the following error:

‘The following error occurred when searching for On-Premises Exchange server:[myservername.local] Processing data from remote server failed with the following error message: The user "domain\username" isn't assigned to any management roles. For more.... It was running "Discover-ExchangeServer - USeWIA $true -SupressError $true’

It was rather confusing at first as I had completed the installation using an admin account that was a member of the Enterprise Admins group. Digging a little deeper, saw the following error in the event log:

After some further digging, I realised what had happened. A colleague of mine did the AD schema preparation using his admin account a few days ago, during that part of the process, the account being used was automatically added to the “Organization Management” AD security group. When I then resumed the installation process with my account, I was not a member of this group. To rectify the problem, I had to manually add my account to the “Organization Management” AD security group.