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.

On the strength of its market position, Microsoft has recently been placed in the Leaders Quadrant in Gartner’s Magic Quadrant for Secure E-mail Gateway.

The Secure Messaging solution offers customers a hybrid model of in-the-cloud services – Forefront Online Protection for Exchange – and on-premises software – Forefront Protection 2010 for Exchange Server – to provide defence-in-depth protection.

For the complete report, click here

Client network traffic is area that often generates many questions. This area is frequently the subject of discussion when site consolidation is being discussed which also raises the issues of network cost and sizing.

While there is some information available on how to estimate this client network traffic, this is mostly relevant to Exchange 2007 and Outlook 2007. I am not aware of any changes in Exchange 2010 and Outlook 2010 that will change the client network requirements, so the information below is based on this.

The first bit of information you need are user profiles, use the Microsoft Exchange Server Profile Analyzer tool to collect this information if you don’t already have it. You can download the Microsoft Exchange Server Profile Analyzer tool from the links provided at the bottom of this page.

Next we determine how much traffic is generated by each user profile per day. In the table below, all values are in Kilobytes/User/Day. The table separates sending from all other actions which are labelled as aggregate.

Now that we have these values, how do we use them? The last piece of the puzzle is the formula. The following formula can be used to estimate the network traffic (in KB/Sec) required by your Exchange 2010 clients.

Using this formula and the data in the above tables, if we wanted to calculate the network requirements for 2,500 heavy users who use Outlook in Cached Mode it would look something like this:

Network Traffic (KB/Sec) = 677 KB/Sec. To convert this to Mbps:

Network Traffic (Mbps) = 5.4 Mbps.

This formula assumes all these users are in the same time zone, so they do the majority of the work during an 8 hour day.

This information is based on the original post from MS Exchange Team blog.

Download Microsoft Exchange Server Profile Analyzer (32 bit) here

Download Microsoft Exchange Server Profile Analyzer (64 bit) here