How to Migrate Distribution Groups Across a Forest

  • Article

Building on my previous couple of blogs on Cross-Forest Migration, in this blog I will describe how Groups can be successfully migrated across a forest. I will also list out some gotchas & how they can be addressed.

Migrating groups is something I've seen customers assume are not important however when the groups are actually moved, customers experience the pain point some of which could have been mitigated.

 

1. Detect & fix any corruption in the groups attributes ( if any ).

Common corruption we see is invalid characters in critical attributes like alias & display name. (space, period, special characters, etc.)

There are several ways to detect this corruption. The most simple & crude way would be to do a Get-Group to list all the mailboxes. Any group with invalid attributes would show up in yellow. Besides this you can also use the Office 365 readiness tool to report on invalid attributes ( highly recommended ).

The only reliable fix to detected corruption would be to manually correct the attributes either from ADUC or from ADSI Edit or a similar tool.

Note the difference between Detect & fix above.

I’ve seen customer attempt to fix this corruption via a script to disastrous effect. ( what logic do you use ? )

Tip: If any attributes were changed & you are using Exchange 2003, you should update the RUS & also replicate across the domain controllers.

2. Execute ADMT to copy groups along with the SID.

when executing ADMT, Fix the group membership in the new forest. This could be in one pass or multiple passes depending on your requirements.

A point of significance here is that ADMT does NOT copy all Exchange attributes from the source to target forest.

3. Convert Groups to Universal.

Exchange 2010 requires a local Global Catalog server in the Active Directory site where Exchange resides to query for group expansion. A Global catalog can expand domain local, global, and universal groups. However, domain local groups (and sometimes global groups) can only be expanded within the domain. Hence the GC will be unable to expand a domain local group in a subdomain.

Thus Exchange Server 2007 & 2010 force you to create all new distribution groups as universal distribution groups even if you have a single domain in the forest.

To convert groups to universal using PowerShell run this command:

Get-Group | where { ($_.RecipientTypeDetails -eq "NonUniversalGroup" -or $_.RecipientType -eq "MailNonUniversalGroup") -and ($_.GroupType -notlike "*DomainLocal*")} |Set-Group –Universal

Iterate by running this command till all groups are converted to universal.

Tip: There are other methods to accomplish this, e.g. with the dsmod command, however the method listed above is what I chose & it works like a charm.

 

4. Mail enable the groups with source Primary, Secondary (if any) SMTP & legacyExchangeDN.

Given that prepare-moverequest.ps1 cannot be used to prepare groups we need to use another tool for copying the SMTP addresses ( note the plural ) from the source to target forest (both Primary & secondary addresses) along with the LegacyExchangeDN stamped as a x.500 address, reasons for which have been explained in earlier posts.

The tool in question is one which was released for migrating an Exchange 2010 sp1 hosted tenant (/hosting mode ) to another forest which is running Exchange 2010 sp2 ( Non-Hosting mode )

The entire archive of scripts & documentation can can be downloaded from https://blogs.technet.com/b/exchange/archive/2012/02/03/released-migrating-from-exchange-server-2010-in-hosting-mode-to-exchange-server-2010-sp2-whitepaper.aspx

Once un-compressed, we need to run two scripts. One to Create an .xml file with the group details & the second to import the same .xml into the target Forest which will restore the group attributes.

 

  • CreateADMTGroupList.ps1 to Create an .xml file of the group details.

 

  • Copy this xml file to the target forest & import it using the next command.

 

  • RestoreGroupAttributes.ps1 to restore the group attributes to the groups which would have already been copied to the target forest using ADMT.

5. Export list of groups having “exception to e-mail address policy” in source forest & Set the same “policy exception” for the groups copied into the target forest.

 Since hosting environments have the "Automatically update e-mail addresses based on e-mail address policy" unchecked, One un-needed thing the above script does it set an the "Automatically update e-mail addresses based on e-mail address policy" to be unchecked. ( thus the Recipient Policy will not be applied. )

2

Command to Export ( source forest )

 Get-mailbox | where {$_.policiesexcluded -eq "{26491CFC-9E50-4857-861B-0CB8DF22B5D7}"}

Command to Import ( target forest )

set-mailbox -emailaddresspolicyenabled $false

 

6. Export List the groups hidden in the source forest & hide the same in the target forest.

for whatever reason they may have been hidden in the source forest, the same would have to be set in the target forest.

Command to Export ( source forest )

Get-mailbox | where {$_.HiddenFromAddressListsEnabled -eq "true"}

Command to Import ( target forest )

Set-mailbox -HiddenFromAddressListsEnabled $true

  

7. Identify which groups have another group as manager & fix managed-by issue

In Exchange 2010, Unlike earlier versions, distribution groups & mailboxes cannot be managed by groups - only individual users. So it's possible that prior to migration, some groups were used to manage the distribution group. Now, members of these groups cannot modify the group.

To resolve this, a script Set-DistributionGroupOwners.ps1 can be used. This script replaces a distribution group or security group, which is specified in the “ManagedBy” attribute of a distribution group, with members of the group.

 The script ( Set-DistributionGroupOwners.ps1 ) can be downloaded from here : https://gallery.technet.microsoft.com/scriptcenter/756b02bd-fb8c-4071-b7b3-3e9022831678

additional details can be found here : https://blogs.technet.com/b/exchange/archive/2011/05/04/how-to-manage-groups-with-groups-in-exchange-2010.aspx

 

8. Enabling users to manage distribution groups but not create or remove them.

 

The script ( Manage-GroupManagementRole.ps1 ) can be downloaded from here :

additional details can be found here : https://blogs.technet.com/b/exchange/archive/2009/11/18/how-to-manage-groups-that-i-already-own-in-exchange-2010.aspx

 

9. Upgrade distribution group version.

Distribution groups ( AD objects ) have a version which determine which features are enabled. for example, if the version is E2003, features which are available in later version like E2010 remain greyed out. (e.g. DL moderation ).

In order to get all the features of Exchange 2010, we need to upgrade the version with the below commands.

Command to Upgrade the groups:

Get-DistributionGroup | Set-DistributionGroup -ForceUpgrade

Command to Report the version:

Get-DistributionGroup | ft Name,Exchangeversion

 

10. Upgrading the E-mail Address Policy

If the email address policy is not upgraded, we will not be able to open the object in EMC

The below command will report which of the e-mail address policies ( aka Recipient Policies ) are legacy.

Get-EmailAddressPolicy | where { $_.RecipientFilterType -eq "Legacy" } | Format-List Name,RecipientFilter*,ExchangeVersion

The below command will upgrade them.

Get-EmailAddressPolicy | where {$_.RecipientFilterType –eq “Legacy”} | Set-EmailAddressPolicy –IncludedRecipients AllRecipients

Note 1 : If you have complex email addressing policies please test before executing the above command.

Note 2 : Mailbox Manager policies are no longer available in 2010 & thus have to be removed.

 

11. QBDG

Query Based Distribution Groups are best re-created from scratch as the actual query parameters could have changed significantly.