We have received some great feedback and questions from last month's post on Perry Clarke's blog and Geek Out with Perry series of videos on e-mail archiving.  This has been a hot and somewhat controversial topic that comes up often amongst our customers and partners so we wanted to share the latest edition of Geek out with Perry with you.

In this next installment, Perry addresses two main items: tiered storage as a method to help customers reduce costs and the use of stubbing in archives.  Do these two approaches make sense for archives? Check out this new video and blog post to see what Perry thinks about these subjects and share your thoughts and questions with us. 

- Ann Vu

In discussions with some of our friends over in the DPM team (System Center Data Protection Manager), we’ve found that there is a rather high incidence of VSS errors in installations where DPM is being used to back up Exchange 2010. Turns out that in many instances, this is because of an incorrect configuration of circular logging on the mailbox databases being backed up, so we thought we would quickly discuss circular logging, what it is, and how it affects VSS backup scenarios.

Circular logging has been around for a long time in the Exchange world. I found KB147524, which references Exchange 4.0, and discusses circular logging. When you configure an Exchange database with circular logging turned on, Exchange doesn’t wait until a backup occurs to truncate transaction log files. Rather, as soon as the log files have been played forward into the database, Exchange is free to delete those transaction logs. In Exchange 2003 and before, this was always handled by the Information Store service.

With Exchange 2007 and later there is actually another form of circular logging, known as continuous replication circular logging (CRCL). There is a great discussion of this in the Continuous Replication Deep Dive white paper, so I’m not going to delve into the mechanics of how it works, other than to state that the system ensures that logs are not truncated on the source until all copies agree with the deletion.

Circular Logging is useful in a few scenarios:

• Customers leverage circular logging on mailbox databases that do not contain any user data.
• Customers leverage circular logging on mailbox databases within lab environments.
• Customers leverage circular logging on mailbox databases in Exchange 2010 when they utilize the Exchange Native Data Protection built into the product because there is no traditional VSS backup solution used to manage the log file truncations.

Customers occasionally leverage circular logging on mailbox databases when performing mass mailbox moves to a single mailbox database target within a small period of time to minimize the capacity impacts that could cause an outage event on the target database. If you are deploying an Exchange solution that will continue to leverage a VSS backup infrastructure and enable circular logging it is imperative that you remember to disable circular logging prior to your next backup window, otherwise your next full or incremental backup will fail. For example, some VSS solutions perform incremental backups of Exchange data by capturing the transaction log files generated since the previous backup that managed/truncated the transaction logs (a full backup, or the previous incremental backup). If you have circular logging turned on, when the incremental backup is performed, the log files that are expected to be there since the previous backup are not there – they have been truncated – causing the backup to fail.

So, what are we saying here? We know that there are some valid and supported scenarios where circular logging is very useful. The idea here we want to reinforce is that when you are performing VSS backups that rely on the transaction logs, make sure that your normal run state is with circular logging turned off. If you have a reason to turn circular logging on when utilizing VSS incremental backups that rely on the transaction log files, remember to turn it back off as soon as reasonable, and understand that while circular logging is on that your incremental backups will fail to complete as expected!

-- Robert Gillies

Just a quick heads-up that we have published a new Exchange 2010 whitepaper:

White Paper: Understanding the Relative Costs of Client Access Server Workloads In Exchange Server 2010
http://technet.microsoft.com/en-us/library/ff803560(EXCHG.141).aspx

Here is what it is about:

Estimating your Exchange Server 2010 Client Access server capacity needs is a critical setup task. The Client Access server is the entry point for all users. In addition, the Client Access server hosts important services used by the other Exchange server roles. This white paper presents an estimate of the relative CPU weights of the different protocols on the Client Access server that can be used to produce a more detailed estimate of hardware needs when you design a new Exchange 2010 deployment or expand an existing one. As part of the testing performed while researching this white paper, the effect of MailTips and the cost of NTML versus Basic authentication were also compared.

- Nino Bilic

As many of you know I review Exchange books for fun (yea... an odd hobby of mine), and I always look forward to new Exchange books coming out. Today it is my pleasure to note that two of our very own TAPs (Siegfried Jagott and Joel Stidley) had a new book coming out that covers Exchange 2010 SP1! You can order it here. I can tell you it's a good read, having reviewed the book myself! But don't just take my word for it; Tony Redmond (also a noted Exchange author) also reviewed the book as well.  And if that was not enough - many TAPs and others wrote interesting sidebars that added interesting short topics to the book. TAP names you can recognize like Gary Cooper, Henrik Walther and Brian Day. A host of internal Exchange folks as well - like Kristian Andaker, Ross Smith, Todd Luttinen, Ed Banti, Greg Taylor, Andrew Ehrensing, and many, many more (see the acknowledgment page for a complete list). 

If you are wondering about what the "TAPs" are and want to get a little bit more about the people behind this book, here is an excerpt from the book Foreword that I wrote for it:

Microsoft's Technology Adoption Program is designed to validate new versions of Exchange by having customers test and run production deployments of pre-release builds of the next version of Exchange. This gives participants the opportunity to provide real-time design feedback to the Exchange product development team. Microsoft deployed the first production Exchange 2010 server on April 16, 2007 and on January of 2008 released bits to TAP customers and partners for review. Shortly thereafter, the authors and other customers were running Exchange 2010 in their production deployments. When Microsoft officially shipped Exchange 2010 on November 9th, 2009, TAPs had already deployed over 200,000 mailboxes into production! Through this preliminary process, the authors were there every step of the final design, gaining valuable experience with each TAP release for deployment. During this TAP deployment phase, all TAPS work together with Microsoft to find the best product and best ways to deploy. Here is what one TAP had to say on this process:

"We have learned a lot through this process and not only about Exchange 2010. By interacting with other TAP members and the product group on a daily basis we have been able to remove the blinders we sometimes wear from administering the same system day in and day out. This has allowed us to consider alternate approaches we could take to improve our system overall and to identify where some of our own shortcomings are. I've seen things posted I've never even thought of before and hope that our contributions have done the same..."

Individually and collectively the authors who wrote this book have been working with Exchange 2010 for as long as many senior developers at Microsoft. They have done an awesome job of providing readers with the ins and outs of the full range of features of Exchange 2010, which will help you get the most out of the product. Exchange administrators will find the experienced hands-on approach of this book invaluable in designing and deploying Exchange 2010. You wouldn't want a book that only skimmed and introduced new features. Fortunately for you, this book is based on the experience of years of successful deployments in complex environments and a teamwork approach to the final design process. Microsoft and TAPS have built a product that we are truly proud of, and this book brings you the right way to walk through it. This book definitely belongs on the shelf of every serious Exchange Administrator or IT Manager.

So, if you are looking for some good summer reading, look no further!

- David Espinoza

EDIT 8/12/2010: Added a note about the necessity to manually enable MSProxy in remote forest.

We are seeing some trends where quite a few customers are migrating mailboxes to a new Exchange organization, in a different Active Directory (AD) forest. This blog post is aimed at helping to explain the fundamentals of what is required to move mailboxes across forests so that you can be prepared with the correct data, make better plans, and successfully perform a migration without encountering painful problems. The blog post doesn't cover how to setup and configure shared address space or Free/busy.

After reading this blog post, you should have better understanding of:

• How to plan your migration by understanding your current forest configuration and your desired configuration.
• Different ways for you to synchronize user data between different AD forests.
• Networking and Administrator permissions required to perform a successful cross-forest mailbox move.

The trends we are seeing currently show that companies are having more trouble understanding the different scenarios than performing the migration. There are several scenarios here, and Microsoft has tools, documentation, and scripts to assist in each one of them.

There are many reasons companies choose to have multiple forests or maybe find themselves with multiple forests, requiring cross-forest moves of users and mailboxes. For instance:

1. Companies that merge, are bought out, or have absorbed another company in some manner.
2. Companies who want to start fresh and leave a lot of legacy issues behind.
3. Companies that have subsidiaries; segment their environment by Department, Geography, or for Security considerations.

The common Active Directory topologies that are supported in Exchange 2010 are as follows:

• Single forest, single Active Directory site
• Single forest, multiple Active Directory sites
• Multiple forest, multiple Active Directory sites

Exchange deployment topologies vary due to organizational size and business complexity. Variations may include Single Forest, Resource Forest, Hybrid Forest, and Cross Forest topology. For purposes of discussion the following forest definitions will be used going forward:

Forest Name	Active Directory user object status	Mailbox Status
Exchange Forest	Enabled User Object	Mailbox Enabled
Account Forest	Enabled User Object	No mailbox enabled objects
Resource Forest	Disabled User Object (linked to a separate enabled user object in an Account Forest)	Mailbox Enabled
Hybrid Forest	Both 1.) AD Enabled Mailbox Enabled 2.) AD Disabled Mailbox Enabled	Both mailbox enabled and disabled objects

Most of the Cross-Org Move Mailbox scenarios are closely related to the Active Directory Forests involved in the migration. There are 3 major scenarios to be considered:

1. Move from Exchange Forest A to Exchange Forest B. This means that the user is a security principal in forest A and after he is moved to forest B, he is a security principal in forest B as well.

• This may be a hybrid-forest scenario, typical during inter-forest migrations, because the user is security principal in both.
• Hybrid is when there are both enabled and disabled users in the same forest.

2. Move from Account Forest to Exchange Resource Forest.

• Company is splitting Exchange off to its own forest. Maybe due to outsourcing it, complex business organization, or desire to de-couple the Exchange org (e.g. messaging services) from the other infrastructure.

3. Move from Exchange Resource Forest to Account Forest. This is the reverse of #2.

• Company is bringing Exchange back into the same forest for simplicity, to better integrate with OCS (though they are not required to be in the same forest), or collapsing/consolidating previously separate Exchange orgs into one user forest.

Cross-forest is when all users from the same organization are only contacts or mail enabled user objects in the other forest.

• This is not referenced as a common scenario because it's usually in place between two separate legal entities and there would not be much movement (e.g. migrations) between them.

Active Directory Forest Configuration examples:

Below are some AD forest configuration examples. The forest scenarios don't necessarily imply there is a "move" or migration going on, some are long-term configurations.

Resource Forest

A Resource Forest scenario is a deployment that has at least one Exchange Resource Forest that hosts user mailboxes (but not active user accounts or enabled user accounts) and at least one other forest that hosts the AD user accounts. In other words, Exchange is installed into an AD forest which is separate from the "user account" AD forest.

• A one-way forest trust where the resource forest trusts the account forest is created.
• Each mailbox in the Exchange forest must have a corresponding user in the account forest, which is granted access to logon to the mailbox. This is referred to as a "Linked Mailbox".

The user objects in the Exchange forest are never logged onto by an end user and are disabled.

Hybrid Forest

Typically this scenario is maintained initially for co-existence while migrating and decommissioning a forest. It is different from a typical cross-forest scenario because there may be both enabled and disabled users in both forests for the same organization. In some cases, an organization may actually need to maintain the Hybrid Forest scenario over the long-term. While this is a supported scenario, it comes with additional complexity that must be addressed:

• Mastering User and Exchange attributes occurs on both sides.
• A tool such as Forefront Identity Manager (FIM), is needed to maintain consistent data on both sides, including the GAL.
• Free/Busy and Public Folder access requires additional configuration, tools, and in some cases maintaining an Exchange 2007 server. (Please note that the IOREPL tool isn't currently supported with Exchange 2010 as a target server and in fact follows the Exchange 2003 Product support life cycle.)
• Free/Busy, over the long-term will be best managed using the new Federation services (Microsoft Federation Gateway)

For more information refer to Understanding Federation

Cross-forest

Both forests contain mailboxes and user accounts and contacts. This type of configuration has user accounts always enabled and mailbox enabled, with a corresponding contact in the other forest. The following diagram depicts how different objects are represented in the corresponding forest:

For more information on forests related to Cross Org migrations, refer to http://msexchangeteam.com/archive/2006/11/02/430289.aspx

Three Migration paths you need to choose from:

Depending on the current topology you have employed, you may find yourself planning to move users into the new forest and then following with moving their mailboxes as well. There are essentially three ways of planning to move your resources:

1. A customized deployment in which you write ILM rules extension code to create the target Mail Enabled User (MEU). You should already have a custom ILM deployment for cross forest GALSync. Microsoft Identity Lifecycle Manager Service Pack 1 Feature Pack 1 (ILM 2007 SP1 FP1) GALSync Management Agent (MA) doesn't include several attributes now required in Exchange 2010, most importantly, msExchMailboxGUID. The out of the box GALSync MA cannot be used since it creates contact object instead of user object required for Online Mailbox Move. The ILM sample code demonstrates how to sync source mailbox as Mail Enabled Users (MEU).

Note: Customers using "out of the box" GALSync MA may probably not know how to customize ILM.

2. Use Prepare-MoveRequest.ps1 script to create the target MEU. It is important to note that the PrepareMoveRequest script works in conjunction with "out of the box" Exchange GALSync MA for ILM (or FIM). This means the script has built-in logic to convert target Mail Enabled Contact (MEC) created by ILM GALSync MA into the required MEU.
3. Use Prepare-MoveRequest.ps1 script and then use ADMT to migrate the other attributes on the user object.

Important Note: Our recommendation on working with ADMT is to rely on the PrepareMoveRequest script to create the local user object for mailbox move, and then use ADMT to migrate SIDHistory and password and merge this into the MEU created by PrepareMoveRequest.ps1 script.

The point of doing ILM or the script first is to ensure the MEUs are all created with the correct msExch* attributes. This also ensures the following benefits:

1. A correct GAL immediately for co-existence (short or long-term)
2. Permissions for delegates and mailbox access are preserved during the move using the msExchMailboxGUID attribute. Since this is populated on the target object with PrepareMoveRequest.ps1 the permissions will be maintained in the cross-forest move.

At this point it doesn't matter if ADMT is used to migrate/merge the user objects all at once or in "batches" of user objects. ADMT can be controlled better to ensure only merging of SIDhistory and certain other mandatory attributes if it's not already populated.

Running ADMT first, without ensuring exclusions on msExch* attributes, can cause corrupted objects which the script cannot correctly convert with the -UseLocalObject switch.

Important Note: When SP1 ships, we will support running ADMT first and then the PrepareMoveRequest script later.

ILM and PrepareMoveRequest Scenarios broken-down:

There are basically 5 steps involved with moving a mailbox across a forest in Exchange 2010. They are: Preparing Active Directory, Network Prerequisites, Administrator Permissions, Moving Mailboxes and Clean-up. Each of these steps is series of smaller steps that need to be taken in order to move a mailbox from one Exchange forest to and Exchange 2010 forest.

The first step in Cross Forest mailbox moves is preparing Active Directory. In the target forest a mail enabled user account must be created with certain attributes. The method used for creating the target account and setting the mandatory attributes is up to the organization administrator. ADMT and ILM can be used to synchronize/pull over the attributes from the source forest.

Exchange Provisioning using ILM 2007

If you deployed ILM for cross-forest global address list (GAL) synchronization, the recommended approach to creating the mail-enabled user is to use ILM 2007 Service Pack 1 (SP1) Feature Pack 1 (FP1) or Forefront Identity Manager 2010 (FIM) GALSync MA. We've created sample code that you can use to learn how to customize ILM to synchronize the source mailbox user and target mail user.

For more information, including how to download the sample code, refer to this link.

To deploy Exchange 2010 in a cross-forest topology, you must first install Exchange 2010 in the new forest. Then, provision the mail-enabled users representing the source mailboxes so that Exchange 2010 can move the mailbox and migrated users can see all addresses.

Deployment steps:

• Deploy Exchange 2010 in a cross-forest topology with ILM 2007 FP1 SP1.
• Import and install the ILM sample code from Prepare Mailboxes for Cross-Forest Moves Using Sample Code.

Note: The main purpose of the sample code is to encourage customers to customize, or add more functions to the sample code. The sample code is very basic and it only copies very basic attributes. Customers who rely on this sample code may find many attributes missing.

• Configure the Mail-Enabled User provisioning Management Agents for each forest. This allows the mailboxes in the source forest to be created as MEU in the target forest and ensure a common GAL.
• Create an SMTP Send connector in each forest and configure SMTP namespace sharing (http://technet.microsoft.com/en-us/library/bb676395.aspx).
• In each forest, enable the Availability service so that users in each forest can view free/busy data about users in the other forest. For more information, see Managing the Availability Service.

Note: The Availability service is supported only for Outlook 2007 clients and newer. If Outlook 2003 clients still exist in one of the forests, the only solution will be to deploy Exchange 2007 first in the Exchange 2010 organization (because adding it late is not possible if Exchange 2010 is deployed first) and implement the IOREPL tool to replicate Free/Busy system public folders to the Exchange 2007 server. The Free/Busy system public folder replicas can then be replicated using PF replication to your Exchange 2010 server. IOREPL will not replicate a public/system folder directly to an Exchange 2010 server.

For more information review:

Exchange Provisioning using ILM 2007 and FIM 2010
http://technet.microsoft.com/en-us/magazine/ff472471.aspx

Prepare-MoveRequest.ps1

It may be difficult for some customers to synchronize the prerequisite attributes for performing mailbox moves without using ILM. You may have some other solution in place that does not synchronize the required attributes, and does not allow customization. Small companies may not have a solution at all and simply wish to transition users from an existing forest (that is set to be obsolete) to a new, clean Exchange 2010 forest.

To solve this problem, the PrepareMoveRequest script has been written to prepare the AD target object and synchronize the required attributes for cross-forest moves to work. The script creates the target MEU if necessary, or synchronizes an existing MEU when possible.

The PrepareMoveRequest script prepares Exchange 2003, Exchange 2007, and Exchange 2010 mailbox users for migration to an Exchange 2010 forest.

For more information about using the sample script, refer to the following link.

The PrepareMoveRequest script supports 2 scenarios:

1. Creating a brand new user in the local forest where the MBX will be moved to.
2. A local recipient, either a MEU or MEC already exists, created by an external agent such as ILM - If the local forest object is a mail contact, the script will convert the mail contact to a mail user while persisting the contact's existing exchange-related attributes. If the local forest object is a MEU, the script will reuse this mail user and stamp the essential attributes on the local mail user object. The administrator must specify the -UserLocalObject switch in order to tell the script to use this scenario.

Note: The scenario that the script doesn't support is that some external process created a local user object and relies on the script to copy all the attributes and links from the remote MBX to the local user. This is the ADMT scenario described after this scenario.

In order to run New-MoveRequest cmdlet to move a mailbox from an Exchange 2003/2007/2010 source forest to an Exchange2010 target forest, the target forest must contain a valid MEU account with the set of AD attributes described in this section. These attributes are synchronized by the PrepareMoveRequest script.

There are certain mandatory attributes that should be present on the target mail user for New-MoveRequest to run properly. These attributes are always set by the PrepareMoveRequest script, either as they are taken from the source MBX, or as determined by the script. The attributes are listed here http://technet.microsoft.com/en-us/library/ee861103.aspx.

Process Overview: Run PrepareMoveRequest script first and then ADMT

• Prepare MEU

To create the target mail enabled user account in an Exchange 2010 forest from the source mailbox enabled account in the source Exchange forest, the PrepareMoveRequest script must be executed in the target Exchange 2010 forest. The script pulls the mailbox enabled account attributes from the source forest.

The script can be used to provision one target MEU account at a time, but can also take data that is passed by pipeline as input to provision MEUs in bulk.

Since PrepareMoveRequest script relies on Update-Recipient task that exists only in Exchange Management Shell, all the below commands need to be run in Exchange Management Shell. Running in PowerShell will only result in error.

• Run the below commands in the target forest

$Local = Get-Credential

Input the target forest's Administrator Credentials in "Domain\User" and Password format.

Note: The account used should have permissions to call Update-Recipient which is available only to Exchange Enterprise Admin.

$Remote = Get-Credential

Input the Source forest's Administrator Credentials in "Domain\User" and Password format.

Note: Since the PrepareMoveRequest script will also update the source object's proxyAddresses to include the target object's legacyDN as X500 address, the account used to run this command should have Read and Write access for the source forest.

• Run the PrepareMoveRequest script in the target forest

[PS] C:\>.\Prepare-MoveRequest.Ps1 -Identity "DN of a user from SourceForest" -RemoteForestDomainController "FQDN of Source DC" -RemoteForestCredential $Remote -LocalForestDomainController "FQDN of Target Forest DC" -LocalForestCredential $Local -TargetMailUserOU "Distinguished name of OU in TargetForest" -UseLocalObject

Note 1: You can use the -Verbose flag to check which attributes have been set if you want to get a detailed list of the attributes that were touched.

Note 2: You can use the -UseLocalObject parameter here.

• If the local matching object is found, then the local object will be used.

          Note: If the local matching object is found and UseLocalObject is not defined, the script will throw an error.

• If the local object doesn't exist, even if UseLocalObject is specified, the script will still create a new one.

If you are sure that you didn't prepare local object before, you could remove this parameter to ensure accidental overriding.

• In the target forest, we get a new disabled mail-enabled user AD object created with some of the following Exchange attributes:

legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName

• SIDHistory is empty. This is expected because Exchange doesn't migrate SIDs. At this point all of the required attributes to perform a mailbox move have been synced into the target forest.
• Run ADMT in the target forest.

Note: Currently the Active Directory Migration Tool (ADMT) v3.1 is not supported on Windows 2008 R2 Servers. If you plan to use ADMT v3.1, it must be installed on Windows 2008 server.

• Check the results in the target forest: The user should now have SIDHistory matching the objectSid of the source object (all other attributes are left untouched)

Gotchas running ADMT first and then PrepareMoveRequest script:

Currently, several customers are running ADMT first and then running the PrepareMoveRequest script. When a user is created via ADMT, the PrepareMoveRequest script doesn't work since there are no proxyAddresses for the script to match the source forest user with the target forest user.

The recommended approach is to copy at least 1 proxy address using ADMT. However, if you use the -UseLocalObject parameter, the script will only copy the 3 mandatory parameters (msExchMailboxGUID, msExchArchiveGUID, msExchArchiveName). This is not very useful. Customers can simply copy these 3 themselves.

Important Note: In SP1, we are adding the OverwriteLocalObject parameter. This is designed for the ADMT case. ADMT can copy the SIDhistory, password, and proxyAddresses, and the PrepareMoveRequest script can sync the other email attributes. In this case, it will copy attributes from source to target, so it's the opposite of UseLocalObject.

ADMT and Exchange Attributes

ADMT transfers Exchange attributes (e.g. homeMDB, homeMTA, showInAddressBook, msExch*) which make the target user look like a legacy mailbox in the target domain. This leaves the target account in an invalid state (e.g. homeMDB still points to the old forest) which is unexpected for the

PrepareMoveRequest.ps1 script. To prevent this, Exchange attributes are excluded from ADMT.

The PrepareMoveRequest.ps1 script can identify and match existing accounts in the target forest based on their SMTP address (proxyAddresses attribute).

Note: It can also do this based on the MasterAccountSid, but this is only populated for accounts in a resource forest scenario.

More precisely, the script will use the existing target accounts if the following are true:

• The target account has a value in proxyAddresses which matches one of the proxyAddresses of the source account.
• The target account is a mail enabled user i.e. you can retrieve it with the Get-Recipient command. For this to succeed, it needs to have mail attributes like 'mail', 'targetAddress' etc.
• You need to specify the -UseLocalObject parameter in the script

If all these are true, the script will copy further attributes needed (especially msExchMailboxGUID) to the target account so that the move request can process the accounts.

By default, ADMT 3.1 does NOT migrate "mail", "msExchMailboxGuid" and "proxyAddresses" attributes  because of security reasons. This is documented in the below article under "System attribute exclusion list"

Managing Users, Groups, and User Profiles
http://technet.microsoft.com/en-us/library/cc974331(WS.10).aspx

Important Note: When running ADMT second after ILM due to both forests having the same schema (attributes), unexpected Exchange attributes are brought over.  This can cause issues.  HomeMDB for example is brought over and causes the MEU to look like a legacy mailbox, and is unusable.

To resolve the problem of ADMT being run first, and leaving the user in an invalid state for the PrepareMoveRequest.ps1 script, you can create the following VB script/ADMT COM object model to exclude all Exchange attributes from being migrated by ADMT.

Set O = CreateObject("ADMT.Migration").
o.SystemPropertiesToExclude = " HomeMDB,HomeMTA,showInAddressBook,msExchHomeServerName, mail, proxyAddresses, msExch*"

This allows update-recipient to find the target object and match it with the source account and merge the two together.  For more information, refer to the below article:

You will find that several custom attributes are missing when you use ADMT to migrate users between two forests

http://support.microsoft.com/kb/937537

Network Prerequisites

When mailboxes are moved from one Exchange 2010 forest to another Exchange 2010 forest, the process is handled through Exchange 2010 Client Access Servers using the MRSProxy service. The only port required to be open between the forests for MRSProxy to use HTTPS traffic is port 443. This works even if the source mailboxes are on 2003 or 2007 MBX servers as long as an Exchange 2010 CAS server exists in both organizations.

Note: The whole forest doesn't need to be Exchange 2010 in order to use the MRSProxy. If there is at least one Exchange 2010 CAS in the forest (with access to the Mailbox Servers and AD), it can be used as the MRS Proxy for moves from a mostly Exchange 2003 or Exchange 2007 forest. This can be called the "Remote" scenario (or the "MRSProxy" scenario). By default, MRSProxy is disabled. To start MRSProxy on the Client Access server in the remote forest, you must modify the Client Access server's Web.config file. For more information refer to http://technet.microsoft.com/en-us/library/ee732395.aspx. If CAS servers are behind the NLB, you should do this on all servers that can take the load.

If the mailbox is being moved from legacy Exchange forest then the mailbox replication service will need to have the same TCP ports open that is needed for a normal local mailbox move. Listed are the TCP ports that are needed for a local mailbox move. These ports will be needed to be open both ways for mailboxes to be moved.

Note: This is more of the "Remote Legacy" scenario, but it can be used between two Exchange 2010 forests as well as between one Exchange 2010 forest and one Exchange 2003/2007 forest.

Port	Protocol
808 (TCP)	Mailbox Replication Service uses to communicate
53 (TCP)	DNS
135 (TCP)	RPC End Point
389 (TCP)	LDAP
3268	LDAP
1024 > (TCP)	if mailbox store is not statically configured then 1024 higher ports need to be open
88 (TCP)	Kerberos
445 (TCP)	Microsoft-DS Service
443 (TCP)	Mailbox Replication Proxy service uses port 443 to communicate with other Exchange 2010 client access server via HTTPS.

Also it is necessary for servers in both forests to successfully perform name resolution using DNS.

For cross forest mailbox moves via the MRSProxy service, the source and target servers use certificates to encrypt the HTTPS traffic. The CAS Servers in the source and target forests must have installed a valid certificate that has been issued by a trusted certificate authority recognized by the server in the opposite forest.

Administrator Permissions

In order to move mailboxes across different Exchange forests the account used to initiate the move request in the target forest and the account used to access the mailbox and directory in the source forest must have the proper permissions. The permissions that are needed for the account in the source forest depend on the type of move.

Remote

The account must have the privileges made available by membership in the Recipient Administrators group.

Remote Legacy

The migration account must have the following permissions.

• Exchange Server Administrators role
• Exchange Recipient Administrators role

Destination Forest Permissions

In the target Exchange 2010 organization the account used to create and manage the move request must be a member of the Organization Management or Recipient Management role groups, or have the following RBAC roles assigned either directly or through group membership:

• Move Mailboxes role
• Mail Recipients role
• Mail Recipient Creation role

Only the Move Mailbox role is required to have access to the New-MoveRequest command. However, the Mail Recipients and Mail Recipient Creation roles may also be required to creating and managing target accounts in preparation for mailbox moves.

Moving the mailbox

There are two methods to move a mailbox across forests using Exchange 2010. The method used depends on the type of cross forest move. Both Remote and Remote Legacy cross forest moves can be performed from the Exchange Management Shell, but only Remote moves can be performed from the Exchange Management Console.

Exchange Management Console

To create a new move request for a cross forest move using Exchange Management Console (EMC), the console must have a session open to both the target and source forests at the same time using the feature Add Exchange Forest. This makes it possible to maintain a connection to an Exchange 2010 server in the source forest, and an Exchange 2010 server in the target forest. With a connection to servers in both source and target organizations via the EMC, you will be able to identify a mailbox that is to be moved from the source forest, while initiating the move request on an Exchange 2010 server in the target forest.

To initiate a cross forest move with the Exchange Management Console, navigate to the Mailboxes folder in the Recipient Configuration node of the source forest, select the mailbox(es) to be moved, and then select New Remote Move Request. This starts the New Remote Move Request.

Exchange Management Shell

To initiate a cross forest mailbox move in the Exchange Management Shell a New-MoveRequest command must be issued with Remote* parameters. Move requests issued without Remote* parameters are local moves within the same Exchange forest.

The New-MoveRequest cmdlet requires certain attributes to be synchronized between the source MBX account and the target MEU account in order for the mailbox move to succeed. This is described in the previous steps.

In the target domain, perform the move request by running the below cmdlet

New-MoveRequest -Identity "Distinguished name of User in Target Forest" -RemoteLegacy -TargetDatabase "E2K10 Mailbox Database Name" -RemoteGlobalCatalog "FQDN of Source DC" -RemoteCredential $Remote -TargetDeliveryDomain "Target domain name"

After the move completes, the proxyAddresses and targetAddress attributes should have changed in the target forest. If the accounts are disabled in the target forest, enable it, set a password and log into OWA and test.

After Online Mailbox Move (OMM), the source object is changed from MBX to MEU and target object is changed from MEU to MBX

For more information on performing cross forest moves in Exchange 2010, refer to Managing Move Requests

Clean-up

When the MRS completes the moving of mailbox data from the source forest to the destination forest it mailbox enables the target user account. If the user account is disabled it leaves the account disabled. The MRS mailbox disables the source account, and converts it into a MEU account with a target address that refers to the primary SMTP address of the target mailbox account. The New-MoveRequest takes the TargetDeliveryDomain parameter. This is what determines which targetAddress to stamp. MRS checks the list of proxyAddresses for one (not necessarily the primary SMTP) that matches the FQDN specified in the TargetDeliveryDomain. The MRS will stamp this address as the targetAddress on the MEU. We moved away from using the primary SMTP address because there is a need to maintain the primary STMP when moving mailboxes cross-forest since this is part of a user's identity. When the primary SMTP address is the same on both forests, mail flow becomes more difficult.

If the source account is to be retired and removed from the source forest, the administrator must plan for this manual operation outside of the mailbox move operation.

What's coming in Exchange 2010 SP1

As mentioned earlier, SP1, will include the PrepareMoveRequest script as part of the install. Additionally, we are fixing a couple of issues with that script:

1. Requiring separate local and remote credentials to run the script.
2. LegacyExchangeDN not set on the new user object after converting local contact to local user.
3. When specifying TargetMailUserOU, we will only search OUs (instead of other object class).

Common Issues

The most common issues related to PrepareMoveRequest script are listed below. These are not relevant if you have deployed the customized ILM, or if you have already run PrepareMoveRequest.

1. Not able to match source forest user with target forest user. This is mainly due to the fact the script relies on proxyAddresses to match objects, so the target forest user needs to have at least 1 proxy address that matches the source
2. Inadequate AD permission to delete/add recipient objects. The script manipulates AD directly and invokes the Update-Recipient cmdlet at the end, so you need to have the appropriate permission to change AD and call Update-Recipient. Another thing you can check is whether the TargetMailUserOU is set correctly.
3. The current script does not have good support for users created by ADMT. The updated PrepareMoveRequest script in SP1 will support a new parameter "OverwriteLocalObject" for users created by ADMT and it will copy attributes from the source forest user to the target user.
4. "UseLocalObject" - This is the script logic where we assume ILM has already created the target forest MEC or MEU, and you want to keep the target forest attributes. So the script will convert the target forest MEU or MEC to the required MEU for MBX move.

Finally, a few words of thanks:

I had the privilege of working with several SMEs from the Product Group, Consulting, UE and Support who helped me visualize, plan, develop and complete this blog. I would like to call out Ian Liu (Program Manager) who was instrumental in sharing his vision and being accessible at all times while writing this blog. I also want to thank Daniel Talbot for his expertise on this subject and his many contributions to the blog. Other contributors that I'd like to express gratitude are Andrew Ehrensing and Huangjian Guo. Thanks to Ying Zhang, Ramon Infante, Jeff Kizner, Kweku Ako-Adjei , Ben Winzenz, Kristi Simmons, Bill Haenlin, Laura La Fleur, Nino Bilic, Jonathan Runyon and Ayla Kol for their review and feedback. Last but not the least, I'd like to thank William Rall for his innumerable thorough reviews and feedback that helped shape this blog.

- Nagesh Mahadev

Exchange 2010 SP1 introduces two new throttling cmdlets: get-ThrottlingPolicyAssociation and set-ThrottlingPolicyAssociation. In Exchange 2010 RTM, in order to determine which throttling policy was associated with a given user, you would use something like:

Get-Mailbox JohnDoe | fl ThrottlingPolicy

To assign a non-default throttling policy to a user you would call

set-Mailbox JohnDoe -ThrottlingPolicy Foo

One thing that should stand out with these two CMDlets is that policies could only be associated with mailbox accounts. Why would you ever want throttling policies associated with anything else? I'm glad you asked. There are at least two valid scenarios to consider:

Scenario 1 - A machine account: Let's say you write a web site that uses Exchange Impersonation to call into EWS and perform actions on behalf of a user that logged onto your web site. Further assuming that your web site is configured to run as Network Service, the EWS call will come from the *machine* account (such as MyDomain/MyMachine$). When such a call is encountered by EWS, it tries to determine which throttling policy to apply to the machine account. Given that set-Mailbox is not applicable to Active Directory Computer objects, and given that a computer is not *in* any of the organizations defined in the Active Directory, the throttling framework must use the fallback policy for the computer account. Given that the fallback policy is hardcoded within the Exchange binaries, you have no control over reducing or increasing its policy values.

Scenario 2 - A cross forest contact: In cross forest scenarios, you have the option of creating a linked mailbox in the Exchange forest or a linked contact. If an account from user forest A is given Exchange Impersonation rights and needs custom throttling values defined, your only option in Exchange 2010 RTM is to use a linked mailbox so that you can assign a non-default throttling policy using the set-Mailbox cmdlets. When a cross forest account calls into Exchange via EWS, the user is authenticated via the user forest (via the trust), but the Active Directory object that Exchange uses to gather "Exchange" information is contained in the Exchange forest. If that Exchange object is a linked contact, the throttling framework must use the fallback policy to throttle the call, which as mentioned above cannot be modified since it is hardcoded.

To cover these scenarios, we added the get/set-ThrottlingPolicyAssociation cmdlets which operate on "virtual" ThrottlingPolicyAssociation objects. By virtual, I mean that there is no ThrottlingPolicyAssociation class in the Active Directory schema. The association represents the link between some "account" and its throttling policy. And what is an "account"? Well, it could be a mailbox, a computer object or a contact.

So let's see how this works. I created a factious mailbox account for JohnDoe. Let's call get-ThrottlingPolicyAssociation on JohnDoe and see what happens.

[PS] D:\Windows\system32>get-throttlingPolicyAssociation JohnDoe

RunspaceId : b84e9a5e-b4c9-4e58-ad86-26d2fffd9b32
ObjectId : MyDomain/Users/JohnDoe
ThrottlingPolicyId :
Name : JohnDoe
IsValid : True
ExchangeVersion : 0.10 (14.0.100.0)
DistinguishedName : CN=JohnDoe,CN=Users,DC=MyDomain
Identity : MyDomain/Users/JohnDoe
Guid : 4f617494-2542-480d-9db1-2720ddf3c013
ObjectCategory : MyDomain/Configuration/Schema/Person
ObjectClass : {top, person, organizationalPerson, user}
WhenChanged : 7/26/2010 8:13:48 AM
WhenCreated : 7/26/2010 8:13:48 AM
WhenChangedUTC : 7/26/2010 3:13:48 PM
WhenCreatedUTC : 7/26/2010 3:13:48 PM
OrganizationId :
OriginatingServer : MyServer.MyDomain

The association is embodied in the ThrottlingPolicyId and Name properties (in red above). If you look closely at the other properties that were returned, they are all properties on the user object. In fact, all of that data is coming from the mailbox object and not from the throttling policy. Now, let's try a mail contact. This time, I will only ask for interesting properties to save on space.

[PS] D:\Windows\system32>get-throttlingPolicyAssociation MyContact | fl ThrottlingPolicyId, Name, DistinguishedName, Identity, ObjectCategory, ObjectClass

ThrottlingPolicyId :
Name : MyContact
DistinguishedName : CN=MyContact,CN=Users,DC=MyDomain
Identity : MyDomain/Users/MyContact
ObjectCategory : MyDomain/Configuration/Schema/Person
ObjectClass : {top, person, organizationalPerson, contact}

And of course, we can't forget about computers.

[PS] D:\Windows\system32>get-throttlingPolicyAssociation MyComputer | fl ThrottlingPolicyId, Name, DistinguishedName, Identity, ObjectCategory, ObjectClass

ThrottlingPolicyId :
Name : MyComputer
DistinguishedName : CN=MyComputer,OU=Domain Controllers,DC=MyDomain
Identity : MyDomain/Domain Controllers/MyComputer
ObjectCategory : MyDomain/Configuration/Schema/Computer
ObjectClass : {top, person, organizationalPerson, user, computer}

The magic comes from the fact that the throttling policy "stamp" is made available on users, contacts and computers via the mailRecipient auxiliary class in the Active Directory schema. The attribute was actually available in Exchange 2010 RTM on users, contacts and computers, but it was not "PowerShell" accessible until these new cmdlets were added. To change the throttling policy association for a user, contact or computer, simply call set-throttlingPolicyAssociation with the identity of the account to change and the throttling policy identity to associate it with:

set-throttlingPolicyAssociation JohnDoe -ThrottlingPolicy Foo

In fact, we can assign users, contacts and computers in one shot:

[PS] D:\Windows\system32>$identity = "JohnDoe", "MyContact", "MyMachine"

[PS] D:\Windows\system32>foreach ($id in $identity){set-throttlingPolicyAssociation $id -ThrottlingPolicy Foo}

And just to confirm that it did indeed work:

[PS] D:\Windows\system32>foreach ($id in $identity){get-throttlingPolicyAssociation $id | fl Name, ThrottlingPolicyId}

Name : JohnDoe
ThrottlingPolicyId : Foo

Name : MyContact
ThrottlingPolicyId : Foo

Name : MyMachine
ThrottlingPolicyId : Foo

You may be relieved to know that getting and setting the throttling policy for a mailbox still works through get/set-Mailbox. However, for new scripts moving forward, we suggest you use the new, shiny get/set-ThrottlingPolicyAssociation cmdlets.

One important thing to note is that you use the ThrottlingPolicy parameter in set-ThrottlingPolicyAssociation whereas the property that is returned in get-ThrottlingPolicyAssociation is called ThrottlingPolicyId. This difference continues to trip me up when using these cmdlets, so when you encounter this difference, know that you are in good company.

- David Sterling

One of my favorite things about my job is that I get to learn new stuff everyday! It's like being in school all of the time! And yes, I was that person in class that always ruined the curve for everyone else.

If you have been using either Exchange 2003 or Exchange 2007 for any length of time, you may have experienced the dreaded Named Properties Depletion warning in your Application Event log. If you haven't, they look like this:

Named Properties Warning for Mailbox Databases:

Event ID: 9666
Type: Warning
Category: General
Source: msgidNamedPropsQuotaWarning
Description: The number of named properties created for database "<database name>" is close to quota limit. Current number of named properties: <number of named properties>. Quota limit for named properties: <configured quota>. User attempting to create the named property: <user name>. Named property GUID: <GUID of named property>. Named property name/id: <name of named property>.

Note: Event ID 9666 can refer to Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI) creation of named properties. For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

Even worse is getting the error events.

Named Properties Error for Mailbox Databases:

Event ID: 9667
Type: Error
Category: General
Source: msgidNamedPropsQuotaError
Description: Failed to create a new named property for database "<database name>" because the number of named properties reached the quota limit (<configured quota>). User attempting to create the named property: <user name>. Named property GUID: <GUID of named property>. Named property name/id: <name of named property>.

Note: Event ID 9667 can refer to Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI) creation of named properties. For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

By the time the error is recorded, you are probably getting calls from your end users wanting to know why they can't send or receive mail. I am not going to explain the history and impact of Named Properties since Jason Nelson wrote several excellent blogs on this (which I use all the time). Check them out here:

Named Properties, X-Headers, and You
http://msexchangeteam.com/archive/2009/04/06/451003.aspx

Named Properties, Round 2: What lies Ahead
http://msexchangeteam.com/archive/2009/06/12/451596.aspx

Service Pack 2 Preview: Get-NamedProperty
http://msexchangeteam.com/archive/2009/08/06/451948.aspx

Understanding how Outlook, CDO, MAPI, and Providers work together
http://msexchangeteam.com/archive/2005/04/08/403512.aspx

Now to clear up the biggest misconception about setting quota limits for named properties for an Exchange 2003 or Exchange 2007 databases:

Setting the quota limits does not increase the number of named properties that can be created in an Exchange 2003 or Exchange 2007 database.

The number of named properties that can be created in an Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

Setting the quota limits for named properties for an Exchange 2003 or Exchange 2007 database increases the threshold of when you are going to get the warning and error messages in the Application Event log.

Please read the above again; it's kind of important.

For Exchange 2003 and 2007, the maximum number of named properties that can ever be created is 32,767 per database.

There is not a way to ever increase the number of named properties that can be created in Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

It took me several readings of all KB and TechNet articles before I picked up on that. So if you didn't get it, please do not feel bad. I spent a lot of time with one of our Senior Escalation Engineers trying to understand it. Right before I wore out their last nerve, a light bulb went on over my head and I finally understood it. Now I explain it to my colleagues and customers, my cat Spike and strangers at the gas station.

And now for something completely different or a little more in-depth view of NamedProps:

The way this really works is that we have a table in the database called NamedProps. Every Named Property that gets added to the database gets its own row in this table. The limit on the NamedProps table is a limit on the number of rows in the table, which are 32,767.

The quotas, of course, are set much lower than that, so that you have some warning before you run out of rows. It doesn't matter if the user is authenticated or not - they all go into the same NamedProps table. So you could have 32k created all by authenticated users, or 32k all created by unauthenticated users, or 10k created by unauthenticated and 22k by authenticated, or whatever... it doesn't matter who created them, the bottom line is that the maximum is 32k rows in that table.

Once your table passes 8k rows (by default), we stop allowing new named props from unauthenticated clients. It's entirely possible that those 8k rows were all created by authenticated clients, but it doesn't matter. We continue allowing new names from auth clients until we hit 16k, and then we deny them as well. This is assuming the quotas are at the default of 8k/16k.

Below is a table with the named properties quota limits:

For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

You can increase the thresholds so you don't get the warnings until, say 22,000. We don't recommend setting the warning quota any higher than 16,000 so you will have adequate time to take action.

And we definitely don't recommend setting the error quota to 32,767 because at that point everyone in your Exchange organization is miffed with you and you find yourself uploading your resume to a popular job site on the Internet.

You may ask yourself "where is my beautiful..."; hold on, wrong question.

Is there a way to suppress the creation of future for named properties for an Exchange 2003 or Exchange 2007 database? And what about Exchange 2010?

I am glad that you asked!

For Exchange 2007 SP1 RU1 - RU7, there is a transport agent named HeadFilterAgent that is available for download at:

http://headerfilteragent.codeplex.com/

Exchange 2007 RU 8 for Service Pack 1 and Service Pack 2 (and later) have new code that prevents future promotion of named properties. And this code is already in Exchange 2010 so no action is needed on your part.

For Exchange 2003, we have a hot fix for Service Pack 2 that enables the control for the creation of x-headers for named properties using a Registry Editor entry:

972077 "Outlook cannot display this view. Unknown Error" error message is generated in Outlook client and Event ID 9667 is logged on an Exchange Server 2003 server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972077

After you apply this fix, you may follow these steps to set a registry entry to control the promotion of X-headers for named properties:

1. Click Start , click Run , type regedit , and then click OK .

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS

\ParametersSystem\InternetContent

3. On the Edit menu, point to New , and then click DWORD Value .

4. Type GenerateNamedProperties , and then press ENTER .

5. Quit Registry Editor.

A 0 value of the GenerateNamedProperties attribute will not generate new named properties.

The default behavior (of the promotion of X-headers for named properties) is true when this registry entry is not found or set to 1.

Let's recap:

Setting the quota limits does not increase the number of named properties that can be created in an Exchange 2003 or Exchange 2007 database.

There is not a way to ever increase the number of named properties that can be created in Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

You can suppress the promotion of named properties in Exchange 2007 SP1 RU1 - RU7 using the transport agent named HeadFilterAgent . Or by applying Exchange 2007 SP1 RU8 or Exchange 2007 SP2. For Exchange 2003 SP2, a hot fix is available that utilizes a registry setting to suppress the promotion.

- Eileen O'Rourke