Building and Migrating to Exchange 2010 SP2 Cloud Services, version 2.0

(1)

Building and Migrating to Exchange 2010

SP2 Cloud Services

Version 2.0

Published: January 2012

Abstract

The focus of this white paper is to guide system integrators and service providers through the migration from the Microsoft Solution for Hosted and Messaging Collaboration (HMC) to Microsoft® Exchange 2010 SP2. Tools and best practices are provided to facilitate this migration.

(2)

Copyright and Trademarks

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,

photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

For more information, see Use of Microsoft Copyrighted Content at

http://www.microsoft.com/about/legal/permissions/.

Microsoft, Active Directory, ActiveSync, Lync, Outlook, SharePoint, Windows PowerShell, Windows Server, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.

(3)

It is assumed that Service Providers will have unique requirements for the automation of tenant migrations from Exchange 2007 to Exchange 2010 SP2 (including scheduling, rollback, resource balancing, verification, logging, and reporting). While the sample scripts included with this guidance can act as a resource to aid in the development of automation, it is expected that Service Providers will develop and test their own end-to-end migration automation in a lab environment (or engage a Systems Integrator with such skills) before they can migrate tenants in production.

(7)

2 Hosted Exchange 2010 SP2 Multi-Tenant Model

Overview

This white paper provides the supported migration scenario from the Microsoft Solution for Hosted Messaging and Collaboration (HMC) 4.5 to Microsoft Exchange Server 2010 SP2. The steps in this guide also apply to migrating from non-HMC environments.

This Exchange 2010 SP2 hosting guidance provides high-level parameters and expectations of the model to be supported. However, it does not specify a detailed multi-tenancy model to use on the platform. It is the responsibility of the service provider and/or their ISV partner to determine the multi-tenant model to utilize.

A multi-tenancy design and automation solution that is recommended and certified by Microsoft is important to have to ensure a predictable provisioning experience for Active Directory, Exchange 2010 SP2, SharePoint 2010, and Microsoft Lync™ Hosting Pack (if desired), regardless of which Control Panel a hosting partner may be using.

(8)

3 Migration Planning

This section covers the following topics:

• Migration Scenario • Migration Requirements • Migration Approach • Migration Tools 3.1 Migration Scenario

3.1.1 In-Place (Same Forest) Migration

Microsoft supports an in-place upgrade from HMC to Exchange Server 2010 SP2 Enterprise. This means that the same Active Directory forest is used—there is no need for a new forest.

IMPORTANT: It is recommended that the Forest Functional Level of the hosting forest must be set to

Windows Server 2008 (or higher) before you install Exchange Server 2010 SP2 Enterprise and enable multi-tenant hosting

User accounts can remain in their existing Organizational Units (OUs) in Active Directory. Therefore, the focus of this guidance is how to move from the tenant segregation model used in HMC (based on complex, nested ACLs on Address List objects and containers in Active Directory) to the segregation model supported by Exchange 2010 SP2 (primarily Address Book Policies and filtered address lists).

3.1.2 Key Goals

During discussions with a number of large Service Providers, the following key goals were identified: • User passwords will be preserved as part of the migration process.

• Microsoft Outlook® 2007 and Microsoft Outlook 2010 users continue to use their existing mail profile, without having to download a new copy of their mailbox to their local OST. • Users will be able to reply to old emails without getting bounced messages.

• POP3 and IMAP users continue to use their existing server configuration without having to point their clients to a new email server.

3.1.3 Components to Be Migrated

The following components must be migrated:

• Mailboxes: All mailboxes (including Calendar, Contacts, subfolders, Deleted Items, etc.) will be moved from Exchange 2007 mailbox servers to Exchange 2010 SP2 mailbox servers. This may also include any resource mailboxes you may have.

• Offline Address Books: Tenant Offline Address Books (OABs) will be re-homed to Exchange 2010 SP2 mailbox servers and distributed by Exchange 2010 SP2 Code Access Security (CAS) servers.

(9)

• Address Lists: Tenant Address List security will be re-configured to use Address Book Policies. • Public Folders: Public Folders can be replicated from Exchange 2007 to Exchange 2010

without the loss of permissions, and without impact to tenant segregation.

• Changes to Client Connection Endpoints and Namespaces: The external namespace used by clients will be migrated to Exchange 2010. A new namespace for legacy access will be associated with your legacy (2007) Exchange client access infrastructure.

3.2 Migration Methodology

3.2.1 Coexistence Migration

The migration approach described in this document is a “coexistence” migration, which will allow the gradual migrations of one tenant at a time.

3.2.2 Migrating User Accounts and Passwords

Because this is an in-place (same forest) migration, user accounts remain in-place. There is no password reset requirement for end users, and there is no need to migrate user accounts and passwords.

3.2.3 Migrating Resellers and the Multi-Tier OU Hierarchy

The HMC solution included a formal, 3-tier hierarchical hosting model, with Resellers as the middle tier (see the following diagram). Other (non-HMC) solutions implemented other approaches. While this document (and accompanying migration scripts) assumes that the 3-tier HMC model is in place, the sample migration scripts can be modified to support other models.

(10)

Exchange 2010 SP2 Enterprise has no concept of a Reseller model. Control Panel vendors or Service Providers are responsible for implementing their chosen OU hierarchy and any other RBAC policies or impersonation models to allow for delegated administration.

Because this migration guidance describes an in-place upgrade, it is assumed that tenant OUs will remain where they currently are. This should allow the widest variety of implementations to take advantage of this guidance, as no OU hierarchy is prescribed here.

3.2.4 Migrating Mailboxes

The New-MoveRequest cmdlet will be scripted to automate migration of mailboxes from the source Exchange 2007 mailbox servers to the target Exchange Server 2010 SP2 mailbox servers. The tenant’s unique name will be stamped on the CustomAttribute1 attribute, to ensure that the user gets picked up by the tenant’s address book filter.

3.2.5 Migrating Mail-Enabled Contacts and Groups

Because this is an in-place (same forest) migration, Mail-enabled Contacts and Distribution Groups remain in-place; there is no need to move them. However, the tenant’s unique name will be stamped on the CustomAttribute1 attribute to ensure that the mail-enabled contacts and groups are picked up by the tenant’s address book filter.

3.2.6 Migrating Offline Address Books (OABs)

Tenant Offline Address Books (OABs) will be re-homed to Exchange 2010 SP2 mailbox servers and configured so Exchange 2010 SP2 CAS servers will distribute them. Each tenant OAB will have a permission set on it so users from that tenant can only download it.

3.2.7 Migrating Address Lists

• Tenant address lists will be modified to use filters to determine their membership, instead of directly stamping showInAddressList on mail-enabled objects (the way HMC did).

• Address Book Policies (ABPs) will be created for each tenant, assigning the appropriate GAL, ALs, and OAB to tenant users.

3.2.8 Migrating Public Folders

Because this is an in-place (same forest) migration, the public folder hierarchy can be replicated from Exchange 2007 to Exchange 2010 without the loss of permissions. Because there is no hosting-specific guidance needed to migrate public folders, follow the Exchange 2010 SP2 documentation on TechNet to migrate public folders.

3.2.9 Changes to Client Connection Endpoints and Namespaces

Because this is an in-place migration, the existing namespaces will continue to be used. Therefore, there will be no client-side changes required. However, an additional legacy name will be needed on the SSL certificate used on CAS servers or the device publishing those servers in order to allow coexistence between Exchange 2010 and Exchange 2007 CAS servers.

(11)

The underlying goal here is to move your primary namespace (for example, mail.contoso.com and autodiscover.contoso.com), over to Exchange 2010, and introduce a new namespace for legacy access (legacy.contoso.com) and associate it with your legacy (2007) Exchange client access infrastructure. Users will continue to use mail.contoso.com as their access point into the organization for messaging services. While Exchange 2007 end users may see the legacy.contoso.com namespace in their browser address bar, Microsoft ActiveSync® settings, and Test Auto-Configuration output within Outlook, they only need to use the mail.contoso.com namespace as their primary entry point into the organization; in addition, the help desk should continue directing customers to utilize the

mail.contoso.com namespace for all external connectivity mechanisms.

3.3 Migration Tools

A set of migration tools is required to enable the migration process. This section describes the tools used in the migration process.

Key migration tools include:

• The New-MoveRequest cmdlet from Exchange 2010 SP2 will be used to move mailboxes. • Scripts will be used to automate the migration of mailboxes and the securing of Offline

Address Books (OABs), Global Address Lists (GALs), and mail-enabled Users, Contacts, and Groups. A set of sample scripts has been included with this guidance. These scripts should be adequate to perform a simple “proof of concept” migration in a lab environment

3.3.1 Bulk Migrations of Mailboxes

The New-MoveRequest cmdlet is used to perform mailbox migrations. A sample script is provided that acts as a wrapper for this cmdlet, collecting a list of all customer organization users whose mailboxes are ready to move, then passing this list to New-MoveRequest.

3.3.2 Migration Export/Import Scripts

A number of sample migration Export/Import scripts are provided to help automate the migration and configuration of:

• Tenant Offline Address Books

o Modify the tenant OAB so it is generated on an Exchange 2010 SP2 mailbox server. o Modify the tenant OAB so it will be distributed by Exchange 2010 SP2 Client Access

servers.

o Set an ACE on the tenant OAB so only the users from that tenant can download the OAB.

• Tenant Address Lists

o Modify Tenant address lists so they use filters to determine their membership, instead of stamping showInAddressList on user, contact, and mail-enabled group objects.

(12)

o Address Book Policies (ABPs) will be created for each tenant, assigning the appropriate GAL, ALs, and OAB to tenant users.

• Tenant Users, Contacts, and Groups

o Mail-enabled Users, Contacts, and Groups will have a CustomAttribute stamped on them to ensure that they get picked up by the filters set on the tenant’s address lists. o Users will be assigned the tenants Address Book Policy to ensure that they can view

only address lists from their own tenant.

o Users will get their msExchQueryBaseDN attribute cleared as this tenant segregation strategy is no longer supported in Exchange 2010 SP2 (it has been supplanted by Address Book Policies).

(13)

4 Deploy Exchange 2010 SP2

Before you begin your deployment, it is strongly recommended that you study the “Exchange 2007 – Planning Roadmap for Upgrade and Coexistence” article on TechNet in order to correctly understand the scope of effort involved in deployment and coexistence.

Here is a high-level overview of the steps you will follow to deploy the base Exchange 2010 server roles into your existing Exchange 2007 environment:

1. Upgrade all existing Exchange 2007 servers to at least Exchange 2007 Service Pack 2 (SP2). 2. Deploy Exchange 2010 servers in this order:

a. Client Access b. Hub Transport c. Mailbox d. Unified Messaging

4.1 Deploy SP2 or Later on All Exchange 2007 Servers

1. SP2 (or later) for Exchange Server 2007 must be deployed on all Exchange 2007 servers in the forest. This includes any computers that run the Exchange Management Console, such as the MPS servers (which will require the 32-bit version of the service pack).

4.2 Deploy Exchange 2010 SP2 Server Roles

For detailed instructions on deploying Exchange 2010 SP2 server roles, please refer to the Exchange 2010 documentation on TechNet: http://technet.microsoft.com/en-us/library/bb125143.aspx

IMPORTANT: Do not create or migrate any mailboxes or address lists on the Exchange 2010 servers

after deploying the base server roles. You first must configure coexistence and modify Exchange permissions as detailed in this document.

(14)

5 Configure Coexistence for Exchange 2007 and Exchange

2010 SP2

Before beginning configuration of coexistence between Exchange 2007 and Exchange 2010, it is strongly recommended that you study the TechNet article “Understanding Upgrade from Exchange 2007 to Exchange 2010” in order to correctly understand the scope of effort involved in configuring coexistence.

5.1 Configure Client Access Coexistence

An Exchange 2010 CAS server cannot deliver Outlook Web Access (OWA) or Exchange Web Services (EWS) service for a mailbox that is located on Exchange 2007. Instead, it must redirect the user to an Exchange 2007 CAS server (in the case of OWA) or provide a 2007 URL to Outlook (for EWS). For this reason, you need to create a unique FQDN for your Exchange 2007 CAS servers, such as

legacy.contoso.com. In this scenario, all users will initially go to the Exchange 2010 CAS servers (which get assigned the existing mail.contoso.com namespace); In the case where the user’s mailbox is on 2007, the Exchange 2010 CAS servers will redirect OWA users to the Exchange 2007 CAS servers (which get assigned the legacy.contoso.com namespace).

ActiveSync and Outlook Anywhere users can access their mailbox via an Exchange 2010 CAS, though a 2007 EWS virtual directory must be available for Outlook Anywhere users with a mailbox on an Exchange 2007 server until such point as the mailbox is moved to Exchange 2010. You are strongly urged to review the guidance at http://technet.microsoft.com/en-us/library/dd351133.aspx for additional information.

1. To configure Client Access coexistence, begin by following the steps in the TechNet article,

Upgrade from Exchange 2007 Client Access.

a. Skip the step that instructs you to move the Offline Address Book server and enable Web Distribution on the Exchange 2010 Client Access server. That process will be addressed later in this document.

2. Purchase and install an SSL certificate that includes the primary external namespace (for example, mail.contoso.com and autodiscover.contoso.com) as well as the legacy namespace (legacy.contoso.com).

3. To allow Exchange 2010 to redirect OWA and EWS requests back to Exchange 2007 for users with mailboxes on 2007, configure the OWA and EWS external URL on the Exchange 2007 CAS servers to use the legacy host name (for example, legacy.contoso.com).

a. The following cmdlets are examples that configure the legacy hostname.

Set-OWAVirtualDirectory <2007servername>\owa* -ExternalURL https://legacy.contoso.com/owa Set-OABVirtualDirectory <2007servername>\OAB* -ExternalURL https://legacy.contoso.com/OAB Set-WebServicesVirtualDirectory <2007servername>\EWS* -ExternalURL

https://legacy.contoso.com/ews/exchange.asmx

Set-UMVirtualDirectory <2007servername>\UnifiedMessaging* -ExternalURL https://legacy.contoso.com/UnifiedMessaging/Service.asmx

(15)

4. Modify the cmdlets to match the hostname and correct paths on the CAS servers, then execute them against each of the Exchange 2007 CAS servers.

5. Because the Exchange 2010 CAS servers can proxy ActiveSync connections to Exchange 2007 mailbox servers, there is no need to configure a legacy hostname on the 2007 ActiveSync virtual directory. Ensure that the external URL has been configured for the ActiveSync virtual directory on the Exchange 2010 CAS servers, then when you are ready to cut service over to Exchange 2010, clear the external URL for the ActiveSync virtual directory on the Exchange 2007 CAS servers using the following cmdlet.

Set-ActiveSyncVirtualDirectory <2007servername>\Microsoft-Server-ActiveSync* -ExternalURL ""

6. Verify the connection to Exchange 2007 OWA by using the legacy host name. 7. Change external DNS so mail.contoso.com now resolves to your Exchange 2010 CAS 8. Verify that if you log in to Exchange 2010 OWA with the credentials of a user whose mailbox

is on 2007, you get redirected back to the Exchange 2007 CAS server (via the legacy hostname).

9. Verify Exchange ActiveSync access.

10. Follow the steps on TechNet to configure Autodiscover with redirection. 11. If you offer POP3 and/or IMAP4 to your customers:

a. Enable POP3 in Exchange 2010

b. Enable IMAP4 in Exchange 2010

c. Configure TLS and SSL for POP3 and IMAP4 in Exchange 2010

d. Configure the POP3 and IMAP4 on the Exchange 2007 CAS servers to use the legacy host name (for example, legacy.contoso.com) and use an SSL certificate that includes the legacy hostname.

Note: There is no need to reconfigure Outlook Anywhere. An Exchange 2010 CAS server can

provide Outlook Anywhere service to users with an Exchange 2007 mailbox without needing to redirect service to an Exchange2007 CAS server. In fact, you can disable Outlook Anywhere on the Exchange 2007 CAS servers after you have verified that Client Access coexistence is working properly.

5.2 Configure Coexistence for Transport/Mail Routing

http://technet.microsoft.com/en-us/library/dd346708.aspx

1. Follow the guidance on TechNet to configure coexistence between Exchange 2007 and Exchange 2010 SP2 for Transport and Mail Routing.

5.3 Configure Coexistence for Public Folders

http://technet.microsoft.com/en-us/library/bb397221.aspx#Mixed

(16)

Follow the guidance on TechNet to configure coexistence between Exchange 2007 and Exchange 2010 SP2 for Public Folders.

5.4 Configure Coexistence for Unified Messaging

http://technet.microsoft.com/en-us/library/dd335126.aspx

Follow the guidance on TechNet to configure coexistence between Exchange 2007 and Exchange 2010 SP2 for Unified Messaging.

(17)

6 Migrate to Exchange 2010 SP2

6.1 Prepare for Migration

6.1.1 Gap Analysis

Before migration can begin, any gaps that exist between HMC 4.5 (or similar) hosting platform and Exchange 2010 SP2 Enterprise must be understood and addressed. For example, Exchange 2010 SP2 does not include:

• Service Orchestration (known as Plans in HMC 4.5) • Fine-Grained Resource Management

• A Multi-Tenant Compatible Control Panel for Customer Self-Service

Review the Multi-Tenancy and Hosting Guidance for Exchange Server 2010 SP2 information on TechNet and perform a full gap analysis study for your hosting environment before proceeding.

6.1.2 Network Requirements

The development and testing of these migration procedures was performed in an environment in which there were no firewalls or port filtering devices separating any of the Exchange servers and/or Active Directory Domain Controllers in the hosting forest. If this is not true for this production deployment, please review the TechNet documentation for Windows® network port requirements, and modify firewall configuration to allow the Windows servers to communicate and replicate Active Directory information and Exchange data across the network.

6.1.3 Modify Exchange Permissions

In Exchange Server 2010, all actions are governed by RBAC. If RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted Subsystem and not the user's context. This is true even of Exchange Management Shell cmdlets issued by an Exchange Organization Administrator.

The Exchange Trusted Subsystem is a highly privileged universal security group (USG) that has read/write access to every Exchange-related object in the Exchange organization. It is also a member of the Administrators local security group and the Exchange Windows Permissions USG, which enables Exchange to create and manage Active Directory objects.

However, because HMC (and most other multi-tenant Exchange 2007 hosting solutions) disable inheritance on several Address List objects and containers in Active Directory, once Exchange Server 2010 SP2 has been deployed into the hosting forest, certain cmdlets (such as New-AddressList) will fail when executed on an Exchange 2010 server. This happens because the Exchange Trusted Subsystem does not have access to the necessary container(s) in Active Directory.

(18)

6.1.3.1 Grant ‘Full Control’ permission to the Exchange Trusted Subsystem group for the ‘All Address Lists’ container

HMC disables permissions inheritance on the ‘All Address Lists’ container in the Active Directory configuration naming context. In this step, manually grant the Exchange Trusted Subsystem ‘Full Access’ to this container and all child objects.

1. Open ADSI Edit, and connect to the Configuration naming context.

2. Expand ServicesàMicrosoft Exchangeà[OrgName]àAddress Lists Container.

3. Right-click CN=All Address Lists, and then click Properties. 4. Click the Security tab, and then click Advanced.

5. Click Add…, type Exchange Trusted Subsystem, and click Check Names to ensure the name resolves. After the name resolves, click OK.

6. In the Permission Entry for All Address Lists window, select the Allow check box for Full

Control. Verify that Apply to: is set to This object and all descendant objects, and then click OK.

7. To go back to the main ADSI Edit screen, click OK twice. Do not close ADSI Edit; it is used in the next procedure.

6.1.3.2 Grant ‘Full Control’ permission to the Exchange Trusted Subsystem group for the ‘Default Global Address List’ object

HMC disables permissions inheritance on the Default Global Address List object in the Active Directory configuration naming context. In this step, manually grant the Exchange Trusted Subsystem ‘Full Access’ to this object and all child objects.

1. In ADSI Edit, expand ServicesàMicrosoft Exchangeà[OrgName]àAddress Lists ContaineràAll Global Address Lists.

2. Under Global Address Lists, right-click CN=Default Global Address List, and then click

Properties.

3. Click the Security tab, and then click Advanced.

8. To go back to the main ADSI Edit screen, click OK twice. Do not close ADSI Edit; it will be used in the next procedure.

6.1.3.3 Verify that the Exchange Trusted Subsystem group is successfully inheriting permissions on the Offline Address Lists container

This is a verification step, as if HMC is running, the Offline Address Lists container should already be inheriting the new permissions that were added in the previous steps.

(19)

1. In ADSI Edit, expand ServicesàMicrosoft Exchangeà[OrgName]àAddress Lists Container

2. Right-click CN=Offline Address Lists, and then click Properties. 3. Click the Security tab, and then click Advanced.

4. Click the Name column to force it to sort ACL entries by name.

5. Verify that an ACL for Exchange Trusted Subsystem with Full Control permission can be found, inherited from a parent container.

Note: If for any reason this permission does not inherit in this environment (for example, if

the HMC methodology is not being used), this ACL must be added in order for OABs to work correctly.

6. After verifying the permission, close the permissions windows and close ADSI Edit.

6.1.3.4 Grant ‘Full Control’ permission to the Exchange Trusted Subsystem group for the Hosting OU

By default, the Exchange Trusted Subsystem group does not inherit enough permissions to fully manage tenants who are located in the Hosting OU hierarchy. In this step, manually grant the Exchange Trusted Subsystem ‘Full Access’ to the hosting OU and all child objects. This permission will inherit down into all tenant OUs.

1. Open Active Directory Users and Computers. 2. Click the View list, and select Advanced Features. 3. Right-click the Hosting OU, and then click Properties. 4. Click the Security tab, and then click Advanced.

7. To go back to the main ADUC screen, click OK twice.

6.1.3.5 Add Exchange Trusted Subsystem group to the local Administrators group on all Exchange 2007 servers

Before running the migration scripts included with this guidance, add the Exchange Trusted Subsystem group to the local Administrators group on all Exchange 2007 servers. Otherwise, the scripts will fail.

• Log on to each of the Exchange 2007 servers, and add the ‘Exchange Trusted Subsystem’ group to the local Administrators group.

(20)

6.1.3.6 Secure OAB Virtual Directories

Prior to the release of an update to Exchange that will enable this functionality natively, the following steps need to be completed to secure access to the OAB virtual directory folders on the Client Access server.

Each of the following examples assumes the domain being used by the hoster is called contoso.com – you need to change the following examples to refer to your own deployment.

Remove the MS-Exch-Download-OAB extended right from the root OAB container

The following two commands should be run once per Exchange 2010 SP2 installation to remove the MS-Exch-Download-OAB extended right from the root OAB container. This prevents all subsequently created OABs from inheriting this extended right.

1. To first verify the permission exists, first run the following command:

$BaseOABContainer=’CN=Offline Address Lists,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com’

2. Then run the following command to examine the existing permissions:

Get-ADPermission $BaseOABContainer -User "NT Authority\Authenticated Users" | where {$_.extendedrights -match 'ms-exch-download-oab'} | fl

3. The results returned should look similar to this;

User : NT AUTHORITY\Authenticated Users Identity : \ Deny : False AccessRights : {ExtendedRight} IsInherited : False Properties : ChildObjectTypes : InheritedObjectType : InheritanceType : All

4. Then run the following command to remove the extended right:

Get-ADPermission $BaseOABContainer -User "NT Authority\Authenticated Users" | where {$_.extendedrights -match 'ms-exch-download-oab'} | Remove-ADPermission

5. To validate this command has executed correctly, the following command should now return zero results:

Get-ADPermission $BaseOABContainer -User "NT Authority\Authenticated Users" | where {$_.extendedrights -match 'ms-exch-download-oab'} | fl

Securing a Tenant OAB

When a new OAB is created after having made the previous change, the Authenticated Users security group will no longer have access to any new or updated OAB folders. Simply adding an ACE granting a specific tenant’s security group allowing them to Read the OAB folder will not work for long, as that ACE will be removed the next time the File Distribution Service (FDS) on CAS runs. The solution is to

(21)

add the MS-Exch-Download-OAB extended right to the OAB directly, which FDS then converts to a READ ACE when it creates or updates the OAB files stored on disk and accessed by Outlook clients. Assuming the tenant organization security group is named ‘Contoso-SG’ and the OAB is named ‘Contoso-OAB,’ the following commands add the extended right to the OAB object itself, which ensures FDS will apply the correct NTFS permissions to the OAB folder when it processes it.

$TENANTOAB=’CN=CONTOSO-OAB,CN=OFFLINE ADDRESS LISTS,CN=ADDRESS LISTS CONTAINER,CN=FIRST ORGANIZATION,CN=MICROSOFT

EXCHANGE,CN=SERVICES,CN=CONFIGURATION,DC=CONTOSO,DC=COM’

ADD-ADPERMISSION $TENANTOAB-USER "CONTOSO-SG"-EXTENDEDRIGHTS 'MS-EXCH-DOWNLOAD -OAB'

Note that sample automation scripts (documented later in this paper) are included to secure tenant OABs in this fashion after they have been migrated to Exchange 2010.

(22)

6.2 Migrate a Tenant to Exchange 2010 SP2

Overview of Sample Migration Scripts

The following sample scripts adequate for performing a “proof of concept” migration in a lab environment from HMC 4.5 to Exchange 2010 SP2 Enterprise are included with this guidance:

• PrepareTenantAddressLists.ps1 makes customer’s address lists compatible with Exchange 2010 SP2 Address Book Policies by setting recipient filters on the address lists and by creating an Address Book Policy for the tenant.

• PrepareTenantMailEnabledObjects.ps1 ensures that the tenant’s mail-enabled Users, Contacts and Groups will show up in the tenant’s address lists on Exchange 2010 by setting the tenant’s mail-enabled objects’ CustomAttribute1 to equal the unique tenant name • MigrateTenantOAB.ps1 moves the tenant’s OAB to Exchange 2010 SP2, and configures it to

be distributed by Exchange 2010 CAS servers.

• MoveTenantMailboxes.ps1 moves tenant mailboxes to Exchange 2010 SP2. • ApplyABPToTenantMailboxes.ps1 applies the tenant Address Book Policy to all of the

tenant’s mailbox-enabled users.

• SecureTenantMailEnabledObjects.ps1 removes the custom security settings applied by HMC (or similar solutions) to tenant mail-enabled Users, Contacts, and Groups.

IMPORTANT: The instructions to add the Exchange Trusted Subsystem to the local Administrators

group on all Exchange 2007 Servers in this environment must have been followed before running the sample migration scripts or they will fail.

6.2.1 Create a Test Tenant on Exchange 2007

In this step, a test tenant will be created in the Exchange 2007 environment. This test tenant will be migrated the first time the sample migration scripts are used.

1. Configure a test tenant on the Exchange 2007 hosting platform that includes mailbox-enabled users with full MAPI plans, mail-enabled contacts, and mail-enabled groups.

2. If POP and/or IMAP are supported, create additional users in the test tenant that are only enabled for those protocols.

3. Verify the ability to log in to the test mailboxes via supported protocols (Outlook Anywhere, OWA, POP, IMAP, etc.)

6.2.2 Prepare Tenant Address Lists for Migration

To make customers' Address Lists (GAL, AL, and OAB) compatible with Exchange 2010 SP2 Address Book Polices, the following must take place:

• Grant "Exchange Trusted Subsystem" full permissions to the tenant GAL and all descendants • Grant "Exchange Trusted Subsystem" full permissions to the tenant AL and all descendants • Grant "Exchange Trusted Subsystem" full permissions to the tenant OAB and all descendants

(23)

• Modify Tenant GAL to define –RecipientFilter for it, filtering on a CustomAttribute that matches the tenant’s name

• Modify Tenant AL to define –RecipientFilter for it, filtering on a CustomAttribute that matches the tenant’s name

• Create an 'All Rooms' Address Book for the tenant, with recipient filter • Create an Address Book Policy for the tenant

A sample migration script called PrepareTenantAddressLists.ps1 has been included which automates this task. Before running the script, it is important to understand some of the decisions it will make:

• The script modifies the tenant’s GAL and AL by adding Recipient Filters to them. The recipient filter is:

((CustomAttribute1 –eq <tenant name>) –and (Alias –ne $null)

6.2.2.1 To prepare tenant Address Lists for migration using the sample script

1. Log on to an Exchange 2010 SP2 CAS server.

2. Edit the PrepareTenantAddressLists.ps1 script, updating the following variables at the top of the script to match this environment:

$DomainID $DomainSuffix $HostingID $ResellerID $PreferredDC $RootExchangeID

The values assigned to these variables will be used to construct the paths to the tenant’s OU, Global Address List, Offline Address List, etc. For example, if a tenant whose OU distinguished name is:

OU=AlpineSkiHouse,OU=ConsolidatedMessenger,OU=Hosting,DC=Fabrikam,DC=com And the root Exchange organization (not the tenant, but the actual Exchange platform) is: CN=First Organization,CN=Services,CN=Configuration,DC=Fabrikam,DC=com

3. Update the variables as shown in the following:

$TenantID = $args[0] $DomainID = “fabrikam” $DomainSuffix = “com” $HostingID = “Hosting” $ResellerID = “ConsolidatedMessenger” $PreferredDC = “AD01.fabrikam.com” $RootExchangeID = “First Organization”

(24)

4. Open an elevated Exchange Management Shell.

5. Modify the Windows PowerShell execution policy to allow scripts to run:

Set-ExecutionPolicy RemoteSigned

6. Run the script, supplying the name of the test tenant as an argument. For example:

.\PrepareTenantAddressLists.ps1 AlpineSkiHouse

7. Review the output of the script to ensure that the process ran successfully.

6.2.3 Prepare Tenant’s Mail-Enabled Objects for Exchange 2010

To ensure that the tenant’s mail-enabled Users, Contacts and Groups will show up in the tenant’s Global Address List (GAL) on Exchange 2010, the following must take place:

• A CustomAttribute attribute on each of the tenant’s mail-enabled Users, Contacts and Groups must be set with the tenant’s unique name. After it is completed, the filter that has been configured for the tenant’s Global Address List will pick up the object, ensuring that it appears in the tenant’s GAL.

A sample migration script called PrepareTenantMailEnabledObjects.ps1 has been included which automates this task. Before running this script, it is important to understand what it does:

• The script searches the tenant OU for all User, Contact, and Group objects that are mail-enabled

• The script steps through each mail-enabled User, Contact, and Group found in the search and does the following:

o Sets the mail-enabled object’s CustomAttribute1 to equal the unique tenant name

6.2.3.1 To prepare mail-enabled Users, Contacts, and Groups using the sample script

2. Edit the PrepareTenantMailEnabledObjects.ps1 script, updating the following variables at the top of the script to match the environment:

4. Run the script, supplying the tenant name as an argument. For example:

.\PrepareTenantMailEnabledObjects.ps1 AlpineSkiHouse

(25)

6.2.1 Migrate the Tenant Offline Address Book to Exchange 2010

To successfully migrate a tenant Offline Address Book (OAB) to Exchange 2010 SP2, the following must take place:

• Set the OAB’s Server property so it is owned by an Exchange 2010 mailbox server. This effectively moves the OAB from Exchange 2007 to Exchange 2010.

• After the OAB has been moved, modify it so it is based off the tenant’s GAL, not its AL. • Configure the OAB’s VirtualDirectories property so it will be distributed by Exchange 2010

CAS servers

• Grant the ms-Exch-Download-OAB permission to the AllUsers@Tenant security group • Update the OAB

A sample migration script called MigrateTenantOAB.ps1 has been included which automates this task. Before running this script, it is important to understand some of the decisions it will make:

• The script randomly selects one Exchange 2010 Mailbox server to own the OAB. If this does not meet the needs of this migration (for example, dedicated OAB servers are being used), then the script will need to be modified to meet the requirements of this migration. • The script then retrieves a list of all Exchange 2010 Client Access Server OAB virtual

directories in the environment

• The script moves the OAB to the randomly selected Mailbox server and configures it to be distributed from all available Exchange 2010 Client Access Server OAB virtual directories. • The script then adds the ms-Exch-Download-OAB permission to a security group called

AllUsers@<tenant name>. This security group is created automatically by HMC (it is located

in the _private OU beneath the tenant OU). If a custom (non-HMC) provisioning solution is used to create tenants in Exchange 2007, the script will need to be modified to use a security group that contains all users from the tenant

• The script updates the OAB.

6.2.1.1 To migrate a tenant OAB using the sample script

2. Edit the MigrateTenantOAB.ps1 script, updating the following variables at the top of the script to match the environment:

$DomainID $DomainSuffix $HostingID $ResellerID $PreferredDC

(26)

$RootExchangeID $TenantAllUsersGroup

4. Run the script, supplying the name of the test tenant as an argument. For example:

.\MigrateTenantOAB.ps1 AlpineSkiHouse

5. Review the output of the script to ensure that the process ran successfully.

Note: In the output of the script, an informational message stating that the appropriate

access control entry is already on the object may appear. This is not a cause for concern.

6.2.2 Migrate Tenant Mailboxes to Exchange 2010

Note: Because an Address Book Policy cannot be applied to a mailbox that is still on Exchange 2007,

the next step is to move the tenant mailboxes to Exchange 2010. This will cause an interruption of service to end users, and they will be required to close Outlook and restart it after the move has finished.

To move tenant mailboxes to Exchange 2010, the following must take place:

• The New-MoveRequest Exchange cmdlet must be called for each tenant mailbox. Either a TargetDatabase must be specified, or the new Automatic Mailbox Distribution feature of Exchange 2010 can be leveraged.

A sample migration script called MoveTenantMailboxes.ps1 has been included which automates this task. Before running this script, it is important to understand some of the decisions it will make:

• This basic script simply retrieves all mailboxes in the tenant OU, and calls New-MoveRequest to move them. It does not provide for batching or scheduling of mailbox moves, handling move failures, nor does it have any intelligence concerning mailbox size or destination. • The script takes advantage of the new Automatic Mailbox Distribution feature in Exchange

2010. (For more information, see

http://technet.microsoft.com/en-us/library/ff477621.aspx ). However, this may not be appropriate for some Service Providers. For example, hosters that offer different Service Level Agreements on different Mailbox Databases may place higher-priced mailboxes into Database Access Groups (DAGs) that are stretched across multiple geo-redundant data centers, while lower-priced mailboxes go into DAGS that exist in only one data center, and are thus less fault-tolerant. For these situations, Service Providers will need to develop a custom automation for moving mailboxes into the appropriate mailstores.

6.2.2.1 To move tenant mailboxes to Exchange 2010 using the sample script

2. Edit the PrepareTenantContactsAndGroups.ps1 script, updating the following variables at the top of the script to match the environment:

$DomainID $DomainSuffix

(27)

$HostingID $ResellerID $PreferredDC $RootExchangeID

.\MoveTenantMailboxes.ps1 AlpineSkiHouse

5. Review the output of the script to ensure that the process ran successfully. After the script completes, run the Get-MoveRequest | FT cmdlet to view the status on the move requests. Do not proceed until all mailbox moves have completed successfully.

6.2.3 Apply Exchange 2010 SP2 Address Book Policy to Tenant Mailboxes

After the tenant mailboxes have been successfully moved to the Exchange 2010 mailbox servers, the Exchange 2010 SP2 Address Book Policy can be applied to each tenant mailbox, and then the custom HMC security settings on each mailbox can be removed.

A sample migration script called ApplyABPToTenantMailboxes.ps1 has been included which automates this task. Before running the script, it is important to understand some of the decisions it will make:

• The script retrieves all mailboxes in the tenants OU and saves them in a list.

• The script goes through each mailbox in the list and assigns the tenant’s Address Book Policy to each.

6.2.3.1 To apply Exchange 2010 SP2 Address Book Policies to tenant mailboxes using the sample script

2. Edit the ApplyABPToTenantMailboxes.ps1 script, updating the following variables at the top of the script to match the environment:

(28)

5. Review the output of the script to ensure that the process ran successfully. The script creates a logfile called Logfile-<tenant name>-ApplyABPToTenantMailboxes.txt. Review this logfile for failures and successes, or use it as a resource for developing a custom reporting automation.

6.2.4 Remove HMC Security Settings from Tenant’s Mail-Enabled Objects

To remove the custom security settings applied by HMC (or similar solutions) to tenant mail-enabled Users, Contacts, and Groups, the following must take place:

• The msExchQueryBaseDN attribute must be cleared from each mailbox-enabled user • The showInAddressBook attribute should be reset to the default value for all of the tenant’s

mail-enabled objects

• The Update-Recipient cmdlet must be run against each of the tenant’s mail-enabled Users, Contacts, and Groups.

A sample migration script called SecureTenantMailEnabledObjects.ps1 has been included which automates this task. Before running the script, it is important to understand some of the decisions it will make:

• The script removes custom HMC security settings on the tenant’s mail-enabled objects by: o Clearing the msExchQueryBaseDN from mailbox-enabled users.

o Setting showInAddressBook to the default value for all mail-enabled objects. o Running Update-Recipient against each mail-enabled object.

6.2.4.1 To remove HMC security settings from tenant’s mail-enabled objects using the sample script

2. Edit the SecureTenantMailEnabledObjects.ps1 script, updating the following variables at the top of the script to match the environment:

(29)

5. Review the output of the script to ensure that the process ran successfully. The script creates a logfile called Logfile-<tenant name>-SecureTenantMailboxes.txt. Review this logfile for failures and successes or use it as a resource for developing a custom reporting automation.

6.2.5 Migrate Public Folders

1. Follow the steps in the Understanding Public Folders article on TechNet to create a public folder database on Exchange 2010.

2. Follow the Exchange 2010 SP2 documentation on TechNet to move public folder content from Exchange 2007 to Exchange 2010. Change the Default Public Folder Database for all Mailbox Databases in your environment.

(30)

7 Post-Migration Cleanup

After the migration of all accounts has been completed, the custom permissions set by HMC on Exchange Address List objects and containers should be removed.

IMPORTANT: Do not carry out this procedure until ALL tenants have been migrated from Exchange

2007 to Exchange 2010 SP2 with Address Book Policies. Otherwise, all address lists will be visible to tenants not using Address List Policies.

7.1 Remove Custom ACLs from Address List Objects and Containers Resetting ACLs back to the schema defaults can be accomplished with careful use of the DSACLS command. Use the /S switch to reset permissions on an individual object, and the /T switch to reset all permissions on a tree of objects.

Using this command in the Exchange lab environment must be carefully tested to ensure that it does not result in cross-tenant visibility or other privacy issues. Also, be sure to test any custom

applications that interact with Exchange to be sure that they will not be impacted by this change.

7.1.1 To Remove Custom ACLs from Address List Objects and Containers

1. In the lab environment, log on to an Exchange 2010 SP2 CAS server with a user account that is an Enterprise Admin, Schema Admin, and Exchange Organization Administrator.

2. Open an elevated command prompt.

3. Run the following commands. Be sure to replace the value for Exchange organization and domain with those that are correct for this environment:

$container = "CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,CN=domain,CN=com "

DSACLS $container /S /T

4. Verify the following for items such as the “All Address Lists” container and all tenant Global Address Lists:

a. Permissions Inheritance has been re-enabled.

b. Authenticated Users once again have the ‘Open Address List’ permission.

5. Test thoroughly to verify that no cross-tenant visibility or other privacy issues are occurring as a result of this change.

6. Test any custom application that interacts with Exchange to verify that they are not impacted by this change.

(31)

7.2 Disable the HMC OABUpdate Task

• On the HMC Provisioning Engine server (for example, MPS01 in the HMC reference architecture), disable the HMCOabUpdate scheduled task.

Building and Migrating to Exchange 2010 SP2 Cloud Services, version 2.0