Microsoft Information Technology (Microsoft IT) maintains a complex Microsoft® Exchange Server environment that consists of several geographic locations and multiple Active Directory® forests. There are 16 data centers, four of which host Exchange servers, to support more than 515 office locations in 102 countries with more than 180,000 users. These users include managers, employees, contractors, business partners, and vendors. Microsoft IT transitioned this environment to Exchange Server 2010 in less than seven months by taking advantage of its growing automation infrastructure and the enhanced deployment features available in Microsoft Exchange Server 2010, in combination with proven planning, design, and deployment methodologies.

Before an Exchange Server release can ship, it has to be thoroughly tested in the production environment. The deployment of Exchange Server into the corporate environment is quicker with each release. For Exchange Server 2010, production testing began in February 2009, one year before Exchange 2010 was available. The entire company migrated to a release candidate (RC)—several months before release to manufacturing (RTM) occurred in September 2009. Microsoft IT accomplished this despite the challenge of testing the Windows® 7 operating system and Microsoft Office 2010 at the same time.

At Microsoft, Microsoft IT and the Exchange Server product group work together closely. Microsoft IT must sign off on a release before the product group can ship it to customers. This relationship is critical to identifying show-stopping factors during the release process.

This technical white paper discusses the Exchange Server 2010 architecture, design, and technologies that Microsoft IT chose for the corporate environment. This paper also discusses the strategies, procedures, successes, and practical experiences that Microsoft IT gained during the planning and design phase. Common planning and design tasks for many Exchange Server deployment projects include server design, high-availability implementation, and capacity planning. In addition to these tasks, transitioning a complex messaging environment to run on Exchange Server 2010 entails specific planning considerations regarding directory integration, routing topology, Internet connectivity, client access technologies, and unified messaging (UM).

The most important benefits that Microsoft IT achieved with the production rollout of Exchange Server 2010 included:

• A reduction in input/output per second (IOPS) of 70 percent since Microsoft Exchange Server 2007. The database optimizations of Exchange 2010 provide better performance and reduced storage costs. This results in a savings of more than 50 percent in the total cost of ownership (TCO) of storage.

• An increased Mailbox size of 5 GB for all mailboxes in the organization.

• Increased mailbox migration velocity over Exchange Server 2007, which enabled Microsoft IT to migrate the entire company much more quickly.

• Elimination of backups, which saves millions of dollars per year.

This paper contains information for business and technical decision makers who are planning to deploy Exchange Server 2010. This paper assumes that the audience is already familiar with the concepts of the Windows Server® 2008 operating system, Active Directory Domain Services (AD DS), and previous versions of Exchange Server. A high-level understanding of the new features and technologies included in Exchange Server 2010 is also helpful. Detailed product information is available in the Exchange Server 2010 Technical Library at http://technet.microsoft.com/en-us/library/bb124558.aspx.

For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.

In order to obtain the full technical white paper visit http://technet.microsoft.com/en-us/library/ff829232.aspx.

I am pleased to announce that starting today you can download the BETA version of the Exchange UM 2010 troubleshooting tool from Microsoft Download Center. The Exchange Unified Messaging team needs your feedback! Download the tool, use it and let us know your thoughts!

The UM troubleshooting tool is a diagnostic cmdlet which helps Exchange UM administrators to identify misconfigurations in telephony equipment and Exchange 2010 SP1 Unified Messaging settings. It emulates calls and runs a series of diagnostic tests, stating the reason and possible solutions for issues that have been detected. This is the tool you should use whenever someone in your organization complains: “My voice mail is not working!”.

You can download the Exchange 2010 Unified Messaging Troubleshooting (BETA) tool from Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=10d2e48f-0846-40b6-b08f-d282309811a2.

We are preparing a set of articles about the tool in TechNet which will be released soon. A separate email will be sent once the articles are published.

You can invoke the PowerShell Get-Help for the cmdlet to find detailed information about each parameter and usage examples (e.g. Get-Help Test-ExchangeUMCallFlow –detailed).

You can install the tool on a local Unified Messaging server or on any 64 bit computer running:

• Either the Windows 7 or Windows Vista operating systems.
• Either the Windows Server 2008 or Windows Server 2008 R2 operating systems.

Prior to installing the Exchange 2010 Unified Messaging Troubleshooting (BETA) tool, the following components must be installed on a 64 bit version of Windows 7, Windows Vista, or the 64 bit edition of Windows Server 2008:

• Microsoft .NET Framework 3.5 SP1. For information, see Microsoft .NET Framework 3.5 Service Pack 1.
• Microsoft .NET Framework 3.5 Family Update for Windows Vista x64 and Windows Server 2008 x64 updates if the tool will be run on a computer running Windows Vista or Windows Server 2008. For more information, see Microsoft .NET Framework 3.5 Family Update for Windows Vista x64, and Windows Server 2008 x64.
• Windows Remote Management (WinRM) 2.0 and Windows PowerShell V2 (Windows6.0-KB968930.msu). For details, see Microsoft Knowledge Base article 968930, Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0).
• Unified Communications Managed API 2.0, Core Runtime (64-bit) (UcmaRuntimeWebDownloadX64.msi). For information, see Unified Communications Managed API 2.0, Core Runtime (64-bit).

DPM 2010 provides node based protection so the state of the database on the node - whether it is an Active copy or a Passive copy of the Exchange 2010 DB does not matter. The state of the database may switch back and forth from Active to Passive, but DPM will continue to protect the DB as long as the Exchange server is up and running. 

As for how many copies to protect - it is recommended that you protect at least two copies of the DB, especially if your Exchange server implementation is based on JBODs/SATA drives. In this situation, it is possible that the database will switch states due to the higher probability of disk failures with SATA drives.  So if you only protect one copy, you will not have protection when the protected copy goes offline.  You will have to manually add protection for another copy after the failure. This has a further disadvantage that you will incur the heavy cost of Initial Replication where you will be backing up the entire database which could be time consuming and will expose you to the risk of not having a consistent backup in this interim. 

If you choose to protect at least two databases, you will not incur the cost of Initial Replication every time a disk goes offline. It can also be shown that the storage consumed on the Recovery Point volume when protecting two databases  is less than twice the amount  of the space consumed when protecting only one server.  In fact, if you expect to switch the databases from Active to Passive frequently, the space consumed by Recovery Points decreases.

If you are using RAID higher end disks then protecting only one copy of the DB with DPM may suffice. By the way, in either case, we recommend that you use RAID 5 disks.

Log file truncation - when you setup protection, in the Protection Group wizard, you are required to configure a database to either be a "Full Backup" or a "Copy Backup". With DPM 2010 you need to configure at least one Full Backup. The Full Backup will backup the databases and the log files and then truncate the log files. If you are protecting more than one copy of the Exchange database, then you should configure one Exchange database for Full Backup and the rest of the copies for "Copy Backup".  Copy backup will not truncate the log files.

The next challenge we faced was getting DPM to backup using the assigned (using Add-BackupNetworkAddress) backup network. The post at http://technet.microsoft.com/en-us/library/ff399746.aspx seems to indicate that the NICS for the backup network should register their IPs in DNS.

Some customers complain that if they add the primary IP address of the DPM server to another “Add-BackupNetworkAddress” statement (-SequenceNumber2) the backup works but it goes over the primary address. Alternatively this would be a workaround but with the respective risks… Hosts file is the name…

I tested several other approaches first though. On my network the backup network NICs do not register themselves in DNS. In fact, they do not even talk to the domain controllers where DNS is located. As memory serves this is what I found:

• I tried manually entering the backup addresses in DNS, but the problem there is that everyone can see and resolve those addresses. Backup traffic can be restricted to the backup network by DPM using PowerShell, but there is nothing to prevent other SMB traffic from using that network as well. When two machines communicate, both with backup NICs, nothing prevents them from using the backup network. I have internal firewalls, and normal traffic must be be constrained to move through the firewall. The backup network is higher performance and cuts across multiple security zones. Indeed, the fact that it is faster than the firewalled network pretty much guarantees that traffic will flow preferentially through the backup network (I have round robin load balancing via DNS turned off).
• I also tried entering a different host name in DNS for the backup network. For example, if the host name is "Server1" I would manually enter a DNS host record for "Server1-BK" using the backup network address. Same for the DPM server. I can ping from either machine to the other using the "-BK" names just fine, but I could not add the machine to DPM as a client in this case. I think DPM was checking AD for the machine name (with the -BK), and failed to find it.
• The hosts file approach works for backup, but it remains a security risk. All traffic, not just backup traffic, between the DPM server and the DPM clients goes over the backup network and bypasses the firewall.

To use hosts files, put an entry in each client's hosts file with the name of the DPM server and the backup network address of the DPM server. In the DPM server's hosts file put an entry for each client list the client host name and the backup address for that client. Do not create entries for the normal, non-backup network addresses. At that point ping by name in both directions should resolve to and use the backup network. If not, you might have other name resolution methods in place. Check out http://support.microsoft.com/kb/142309 (old, but as far as I am aware the resolution order has not changed) or do a search for "host name resolution". I have no LMHOSTS entries, no WINS, etc. so all I needed to do was put the above entries in the hosts file and it worked. I did not run the PowerShell cmdlet to inform DPM of a dedicated backup network.  As far as DPM was concerned, all communication was over that network.  I verified during backups that the traffic did stay on the backup network.

Would like to thanks Anne Soilleux, one of our brilliant Escalation Engineers, who actually grab me in the office making me DPM questions and coz of that I end up researching, blogging and posting! Cheers Anne!!!

In most environments that plan to implement Exchange 2010, there will probably be an older (legacy) version of Exchange Server running. This document provides information on how Exchange 2003, Exchange 2007, and Exchange 2010 will work together in regards to OWA. If implemented correctly this will provide a single namespace for user access to the Outlook Web App (OWA), regardless of where their mailbox is located.

Because the variations are numerous in customer environments, the steps in this bulletin may not work for every implementation. The steps are tailored for several typical environments and actual steps for configuring this solution may vary.

Planning for Coexistence

Some general planning guidelines for coexistence are as follows:

• Make sure that the Exchange Server 2003 servers are running Service Pack 2 or higher.
• Make sure that the Exchange Server 2007 servers are running Service Pack 2 or higher.
• An Exchange Server 2010 server running the Client Access Server, Hub Transport and Mailbox roles (CAS/HUB/MBX) is present in the Internet-facing site
• Update the main OWA URL to point to the Exchange Server 2010 CAS servers. Consider changing your public DNS records so that the public OWA URL (i.e. mail.contoso.com) points to the new IP address of your Exchange 2010 CAS server, or the virtual IP address of your load-balanced CAS Array.
• Create a legacy URL to point to the Exchange Server 2007 CAS or Exchange Server 2003 FE servers if they exist and make a DNS entry externally to point to the legacy server.
• Create a certificate for the Exchange Server 2010 CAS servers to include the OWA URL, the Legacy URL, and Autodiscover URLs – Other names may be needed for protocols such as IMAP and SMTP.
• Change the External URL setting on the Exchange Server 2007 CAS Server to the legacy URL if applicable
• Update the rules on the firewall/ISA Server to point to the correct locations for Exchange Web traffic.

Single AD Site with Exchange 2007 and Exchange 2010

This scenario is a typical scenario for most of our small to mid-sized customers. Typically, they will have one Active Directory site and the addition of Exchange 2010 into their environment will not change that. If the steps below are followed, users can continue to use their existing URL for OWA. They can also expect to have single sign-on for their OWA users, even if they are on Legacy versions of Exchange.

This is a very clean experience for the users and should help make the migration painless as a user’s learning curve will not be required.

The following list contains the basic instructions for the setup of the single sign-on and a brief explanation of what will happen when a user accesses OWA:

• Change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for 2007 and 2003 but not 2010 so if you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• Create a legacy.company.com Host record to point to the 2007 CAS server. The reason for this is to be able to have a Host record that can be used by the 2010 CAS server to know the location of the 2007 CAS server that can handle the legacy requests.
• Ensure that the ExternalURL value is populated and the InternalURL value is set to $NULL for the OWA virtual directory on the Exchange Server 2007 CAS that is the target of the redirect. If necessary, use the following command to set this: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://legacy.company.com/owa -InternalURL $NULL.
• Create a SAN certificate that will either have the wildcard entry (i.e. *.contoso.com) or contain subject name entries for owa.contoso.com, legacy.contoso.com and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).
• Assign that certificate to the CAS servers. This certificate should be assigned to the 2007 and 2010 CAS servers to prevent any name mismatch certificate warnings. The reason the 2007 CAS servers would need the certificate is because the name that the 2010 CAS servers will be using to access the 2007 CAS servers will be the new legacy name and unless a wildcard certificate was previously used then that name will not be on the certificate.
• On the 2007 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL. The reason we are doing this is to ensure the 2007 and 2010 CAS servers have the same Authentication settings and that we add the new External URL so that the 2010 knows where to go with the legacy requests: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://legacy.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL to match what was being currently used by the users: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.

What happens when a user logs in?

• A user browses to https://owa.contoso.com/owa then authenticates in the FBA page presented by 2010 External facing CAS server.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL set on the 2007 CAS servers in that site in our case https://legacy.cotoso.com/owa.
• CAS2010 will then silently redirect the user’s browser session to https://legacy.contoso.com/owa using a hidden FBA form with the fields populated.  OWA will return a small web page containing a hidden form with the same information as what the user had originally submitted to CAS2010 FBA page (username, password, public/private selector, URL to redirect to after logon) and a submit URL synthesized from URL obtained in step 2, and target Exchange -specific path and query string. The web page will also contain script to automatically submit the form as soon as it is loaded.  This is the last part of the logon process that E2010 CAS will have a role in.
• CAS2007 will consume that hidden form’s data, authenticate the user and:

• Retrieve and render the user’s mailbox data from the Exchange 2007 mailbox server and provide the data view back to the user.  The response will contain an FBA cookie for the legacy namespace, and from that point on all user activity within the session will go to legacy CAS only.
• Or proxy the request to the Exchange 2003 mailbox server and provide the data view back to the user.  The response will contain an FBA cookie for the legacy namespace, and from that point on all user activity within the session will go to legacy CAS only.

Multiple AD Sites with Exchange 2007 and Exchange 2010 (redirect)

In most cases in a 2 internet facing site Environment the users in the internet facing sites would type the name that correlates to the site they are located in but for this example we will assume they did not.

This scenario is typically found in a medium- to large-size company that has multiple Active Directory sites that are not well connected. In this case, you would not want the traffic from a CAS server to return mailbox data from a server in an Active Directory site where the connection is not optimized.
In this case if a user goes to a site where the mailbox is not located and authenticates, the Exchange Server 2010 CAS server would provide a page informing the user to click on a link to take them to the CAS server for the site where the mailbox is located. When the link is clicked, the user will be prompted for authentication again, this time from their local (to the Mailbox server) CAS server. This will not be a single sign-on scenario unless the user accesses the proper link for the site where there mailbox is located.

An explanation of what the user will see follows the instructions to configure the solution:

• As stated above change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for 2007 and 2003 but not 2010 so if you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• The opposing regional site should already have a unique URL such as regional.company.com. If this is an existing setup the naming should still be in place and there would be no need to Change this.
• Create a SAN certificate that will either have the wildcard entry (i.e. *.contoso.com) or the cert should contain subject name entries for owa.contoso.com, legacy.contoso.com and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).
• Make sure that the OWA in the regional site is set for basic Authentication with FBA for OWA and that the external URL value is set correctly similar to the following: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://regional.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.

What happens when a user logs in?

• Browse to https://mail.contoso.com/owa. Authenticate in the FBA page presented by 2010.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL set on the 2007 CAS servers in that site in our example https://regional.coontoso.com/owa.
• CAS2010 will then provide a redirection page for the user to click a link for https://regional.contoso.com/owa and let them know this is the link they should use. The reason this will occur is because the users are located in a different AD site and they have External Facing CAS servers in that site. This process will be the same whether the other site has 2007 or 2010 CAS servers in the internet facing site.
• After clicking the link the user will get another authentication prompt at the CAS server in the site where the mailbox is located and all of the traffic will then go through the users Local CAS servers.

Multiple AD Sites with Exchange 2007 and Exchange 2010 (proxy)

This scenario could apply in a medium- to large-size company that has multiple Active Directory sites that are well connected. This provides a single namespace for the users to connect to for OWA access and minimizes user confusion.

In this case if a user goes to the published OWA URL and authenticates, the Exchange 2010 CAS server silently proxies to the Client Access Server that is local to their Mailbox server. The user would not be prompted again or redirected to another site for action.

This will generate more network traffic, as the rendered mailbox data will be passed to and from the CAS server in the site where the mailbox is located back to the External facing CAS server. The configuration steps and the user experience explanation follow:

• As stated above change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for 2007 and 2003 but not 2010 so if you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• The opposing regional site CAS Servers should not have an External URL value set for the OWA virtual directory they should have just an internal URL value the default values for this are typically fine.
• Create a SAN certificate that will either have the wildcard entry (i.e. *.contoso.com) or the cert should contain subject name entries for owa.contoso.com, legacy.contoso.com and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).
• Assign that certificate to the 2010 CAS servers.
• Make sure that the OWA in the regional site is set for integrated Authentication for OWA using a command similar to the following on the 2007 non internet facing CAS server. The reason for this is because we will be using integrated authentication for requests that are proxied to this server from the Exchange 2010 CAS server. This is the same process as in Exchange 2007: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" –ExternalURL $Null –formsAuthentication $False –WindowsAuthentication $true.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://owa.company.com/OWA -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL Https://owa.company.com/OWA -FormsAuthentication $True -BasicAuthentication $True.
• 7. From the External facing 2010 CAS server go to the 2007 server and copy the latest set of binary files to the 2010 server (every time a rollup is placed on the 2007 CAS servers this process will need to be redone). The reason for this is when you are being proxied the External facing 2010 server has to present the rendered data to the users. Since they are legacy users we need to have a comparable copy of the binary files based on the Exchange Rollup they are on:

• From the 2010 CAS server go to START then RUN then type something similar to \\2007cas\c$\program files\microsoft\Exchange Server\Client Access\OWA.
• Copy the Highest version of the build files from that location and paste them on the internet facing 2010 CAS server in the location similar to the following c:\program files\Microsoft\Exchange Server\V14\ClientAccess\OWA.
• Then restart IIS on the 2010 CAS server and this should allow proxying to work. If the wrong files are copied or this step is not completed you will see an error on the 2010 external facing CAS servers in the application log telling you to copy the files.

What happens when a user logs in?

• Browse to https://owa.contoso.com/owa. Authenticate in the FBA page presented by 2010.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL set on the site where the user is located.
• There will not be an External URL Value set on the site where the user is located, so the user will be authenticated via Proxy using integrated authentication over the internal URL.
• The 2007 non internet facing server will render the data and pass that along to the 2010 server to pass along to the user. The 2010 internet facing CAS server will NOT be out of the loop in this case.

Exchange 2010 and Exchange 2003 within a Single Site or Cross Site

The scenario below is for a company that does not have Exchange Server 2007 installed and is migrating or coexisting with Exchange Server 2010 and Exchange Server 2003, only.

The Exchange2003URL value can be found in Active Directory in the following location using ADSIEdit.MSC:

This will allow the Exchange 2010 server to know where to direct the Legacy users so that they can access OWA using the 2010 CAS servers URL. This parameter was added as there is no longer a /exchange virtual directory in Exchange Server 2010, as there was in Exchange Server 2007. 

It is important to understand that Exchange Server 2010 cannot proxy to Exchange Server 2003 Mailbox role servers. Exchange Server 2010 must redirect this traffic.

In this situation you would use the new Exchange2003URL parameter that is configurable via the Exchange Management Shell with the set-OWAVirtualDirectory commandlet explained below:

• Change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2003 can handle requests for 2003 only. If you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• Create a legacy URL such as legacy.company.com to point to the 2003 FE server. We need this in place so that we have a URL that we can provide the Exchange 2010 CAS server the proper configuration to find the 2003 FE server.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• Configure the Exchange2003URL property on the 2010 CAS server to point to the new Legacy URL. Then new Exchange2003URL value was added to Exchange 2010 as a configurable attribute for the OWA virtual directory to provide a way for Exchange 2010 to know the location to send the 2003 users. In previous versions we used DAVEX for this but since DAVEX was removed we now rely on this property…. The following is an example of how to set this property: set-owavirtualdirectory “2010 CAS server name\owa (default web site)” -exchange2003url https://legacy.company.com/exchange.
• FBA will need to be enabled on the 2003 FE server. The reason for this is because we are passing the credentials from the 2010 CAS server to the 2003 FE server via a hidden form. This is designed to prevent the user from having to authenticate again.

What happens when a user logs in?

• Browse to https://owa.contoso.com/owa. Authenticate in the FBA page presented by 2010.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL/ and in this case Exchange2003URL value.
• The 2010 CAS server will then silently redirect the user to the legacy URL and auto-populate the Credentials provided in step one using a hidden FBA Page.
• The 2003 server will then Authenticate the user silently and will provide the data to the user. This process will allow for a single sign on for the legacy users. At this point the 2010 server would be out of the loop.

Thanks to Timothy Heeney, Chris Lineback and Sam Kamau putting together all of this awesome piece of information which will help so many customers in migration processes.

One corrupted mailbox can have the potential to disrupt service by taking down the entire information store, thereby affecting all users on that server. Mailbox quarantine has been introduced in Exchange Server 2010 to help prevent this situation.

What is Mailbox Quarantine?

Mailbox quarantine is a feature in the Exchange Server 2010 information store. Based on values in the registry, the store detects a mailbox or mailboxes that have the potential to or have caused the store to crash and quarantines them for specific period. The mailboxes that have the potential to crash the store are called Poisoned mailboxes.

When does quarantining happen?

Quarantining of mailboxes can occur in two situations:

• A thread that is doing work for a mailbox has crashed.
• More than 5 threads allocated to process a mailbox, have not progressed for long time.

How does it work?

The store will tag a mailbox that has the potential to crash the store. The tag includes the number of times that mailbox has caused the store to crash and a time stamp. If the store is crashed by a mailbox, a registry key is created. The path to the registry key is:

HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox GUID}

It will have the following two values:

• CrashCount – The number of times the mailbox has crashed the store.
• LastCrashTime – The last time the mailbox crashed the store.

The key is not created until the store has been crashed at least one time by a mailbox.

Each time a database is mounted, the store checks the registry to see if any mailboxes hosted on this particular database is tagged. If the registry indicates that a mailbox has caused the store to crash the mailbox will be quarantined.

By default, if a mailbox has been identified as a threat 3 times in 2 hours then that mailbox will be quarantined for 6 hours.

These default settings can be modified by creating the following key:

HKLM\SYSTEM\CCS\Services\MSexchangeIS\ParameterSystem\Servername\Private-dbguid\Quarantined Mailboxes

Using the following values:

• MailboxQuarantineCrashThreshold – The number of times a mailbox can be identified before the store quarantines it.
• MailboxQuarantineDurationInseconds – The number of seconds a mailbox remains in quarantine before the store releases it.

These two values do not exist by default. They should be created only if there is a need to change the default behaviour.

A background process in the store runs every 2 hours (this default can’t be changed) to check the registry values for each mounted database. The store checks the CrashCount and LastCrashTime values and performs any of the following four actions:

• If all tagged mailboxes have a CrashCount value less than the MailboxQuarantineThreshhold (default value of 3) in the last 2 hours, then the dbguid registry value for the mailbox located at HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes is deleted.
• If a tagged mailbox has a CrashCount is greater than the value MailboxQuarantineThreshhold (default value of 3) and a mailbox is not quarantined then the mailbox will be quarantined immediately.
• If a mailbox has been quarantined longer than the default 6 hours or the time specified in the value MailboxQuarantineDurationInSeconds then it will be released immediately.
• If a mailbox is quarantined for less than the default six hours or time specified in the value MailboxQuarantineDurationInSeconds then it will remain quarantined.

What happens when clients try to access a quarantined mailbox?

When a client attempts to access a mailbox the following occurs:

1. The store will return an error code ecMailboxQuarantined and based on this, XSO throws the transient exception MapiExceptionMailboxQuarantined to signal transport and other XSO clients

2. Every 5 minutes transport tries to deliver message sent to a quarantined mailbox

3. Outlook clients see the following pop up when they try to access a quarantined mailbox

4. OWA displays the following pop up error message when trying to access a quarantined mailbox

Only clients such as MFCMAPI that can pass Open-As-Admin flag can access a mailbox while it is in quarantined state. Even Exchange processes such as content indexing and mailbox assistants cannot access the mailbox.

For example, a move mailbox request will fail with the following pop up error:

Resetting a quarantined mailbox

It is possible to reset a quarantined mailbox by deleting the quarantine registry key for that mailbox located at:

HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox guid}.

The database then has to be dismounted and remounted or the IS service restarted for the reset to take effect immediately. Unless the underlying issue is not resolved, the mailbox could crash the store and become quarantined again.

Troubleshooting

Application log

The following event will be logged when a mailbox is automatically quarantined:

Log Name: Application

Source: MSExchangeIS

Event ID: 10018

Task Category: General

Level: Error

Description: The mailbox for user /o=AMERICAS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.

The following event will be logged when a mailbox is automatically removed from the quarantine:

Log Name: Application

Source: MSExchangeIS

Event ID: 10019

Task Category: General

Level: Error

Description: The quarantine of the mailbox for user /o=AMERICAS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 has expired. Access to the mailbox has been restored.

Shell Command

We can also use the Get- MailboxStatistics cmdlet to see if a mailbox has been quarantined.

Get-MailboxStatistics –identity test1 | FL Isquarantined

Isquarantined : True

Performance Monitor

The store also provides the performance monitor counter: MSExchangeIS Mailbox\Quarantined Mailbox Count. This counter shows the number of quarantined mailboxes on a specific server.

EXTRA

Finally we can used EXTRA to trace data. Select Function from Trace Types and use the tag tagQuarantineMailbox under component Store.

Thanks to Hamza Hassen and Jonathan Runyon for putting all this information together which will help so many of us certainly…