When migrating between Exchange environments, it’s important to understand the level of collaboration between users and mailboxes. This post sheds some light on the different methods of collaboration and how QMM handles the migration.
Send on Behalf of Rights: PublicDelegates attribute
This value is set through either Exchange mailbox properties, Outlook, or via a Directory Services interface such as ADSI Edit. The publicDelegates attribute is the forward link to the DN(s) of any active directory objects granted Send on Behalf of rights to that user’s mailbox.
This attribute and the back link, publicDelegatesBL, is sync’d by default in a QMM migration, thus preserving the Send on Behalf of rights. These rights work for both switched and unswitched mailboxes as they rely on Active Directory to resolve the backlink to another AD object. The sent item resides in the delegated user’s mailbox, making the mail sync a non-issue.
The below PowerShell code will enumerate all objects with publicDelegates present. As mentioned earlier, these values are migrated and translated to the target DN by default in QMM, so very little work needs to be done to preserve Send on Behalf of rights. The only consideration is to ensure that the correct objects are in scope. If a publicDelegate is not sync’d to the target domain, the link resolver will not be able to translate the value and will throw an error.
# Search Directory for Send on Behalf of Rights, Bind to Object and Export Results
$directorySearcher = New-Object System.DirectoryServices.DirectorySearcher(“(&(publicDelegates=*))”)
$directorySearcher.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry(“LDAP://<SourceDomain>”)
“distinguishedName”,”publicDelegates”,”sAMAccountName” | %{$directorySearcher.PropertiesToLoad.Add($_)}
$directorySearcherResults = $directorySearcher.FindAll()
foreach($directorySearcherResult in $directorySearcherResults)
{
$delegateBindDNs = $directorySearcherResult.properties.publicdelegates
foreach($delegateBindDN in $delegateBindDNs)
{
$delegateBind = [ADSI]”LDAP://$delegateBindDN”
[string]$directorySearcherResult.properties.samaccountname + “;” + $delegateBind.Properties.sAMAccountName | Out-File ($Env:TEMP + “\publicDelegates_Results.txt”) -Append
}
}
Send-As Rights: ntSecurityDescriptor
The Send-As rights are stored on the ntSecurityDescriptor attribute of an Active Directory object. This ACE object type is assigned the well-known Guid of “ab721a54-1e2f-11d0-9819-00aa0040529b” which can be queried using a number of interfaces. The below PowerShell example uses the ObjectSecurity property to query for the Send-As Guid.
# Bind to Object and enumerate the Send-As rights
$userBind = [ADSI]”LDAP://<DN>”
$sendAsAccess = $userBind.ObjectSecurity.Access
foreach($entry in $sendAsAccess)
{
if(($entry.ObjectType -eq “ab721a54-1e2f-11d0-9819-00aa0040529b”) -and ($entry.IdentityReference -ne “NT AUTHORITY\SELF”))
{
$userBind.Properties.sAMAccountName + “;” + $entry.IdentityReference | Out-File ($Env:TEMP + “\Send_As_Results.txt”) -Append
}
}
By default the ntSecurityDescriptor is not migrated using QMM. To migrate this attribute, you will need to set the Security Descriptor option in QMM AD to either Merge or Replace this attribute. Replace can create situations in the target where target domain admins won’t have access to target objects, so Merge is usually the right choice. Once this ACE is migrated, users will continue to have send as rights on a mailbox via sidHistory until Active Directory Processing Wizard (ADPW) is run to translate that ACE to the target SID.
Full Access rights: msExchangeSecurityDescriptor
Full Access rights are stored on the Exchange mailbox ACL as “CreateChild” rights. In Active Directory this value is called the msExchangeSecurityDescriptor, and like the ntSecurityDescriptor, it can be accessed using PowerShell. This attribute is referred to as the MailboxSecurityDescriptor in Exchange.
By default QMM AD will sync this value in an Exchange migration that involves mailbox enabling the target object. The access control SID will remain as the source domain value until ADPW is run. When viewing the Full Access Permissions through the target Exchange, you will likely see the Security Principal translated from sidHistory. Until ADPW is run to process Exchange permissions on target objects, the msExchangeSecurityDescriptor will continue to only have source access control entries.
These rights are preserved for migrated users trying to access an un-migrated user’s mailbox through sidHistory. The only limitation in this scenario is the sync schedule. New email into the shared mailbox will not be updated until the source and target agents have processed the mail data. This sync delay can be reduced by using special purpose agents to only handle mailboxes that require full access rights by other users. If these users are also using send-as rights, any sent mail items will not be sync’d from Target to Source.
The below PowerShell code will export the rights for all mailbox enabled domain accounts.
# Search Directory for Mailbox Rights, Bind to Object and Export Results
$directorySearcher = New-Object System.DirectoryServices.DirectorySearcher
$directorySearcher.Filter = “(&(homeMDB=*)(objectCategory=person)(objectClass=user))”
“msExchMailboxSecurityDescriptor” | %{$directorySearcher.PropertiesToLoad.Add($_)}
$directorySearcherResults = $directorySearcher.FindAll()
foreach($directorySearcherResult in $directorySearcherResults)
{
[byte[]]$userBindMsExh = $directorySearcherResult.Properties.msexchmailboxsecuritydescriptor[0]
$convertTypeACL = New-Object System.DirectoryServices.ActiveDirectorySecurity
$convertTypeACL.SetSecurityDescriptorBinaryForm($userBindMsExh)
$domainACLs = $convertTypeACL.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier]) | ?{$_.IdentityReference -like “S-1-5-21-*”}
$domainACLs | %{[string]$sid = $_.IdentityReference.Value; [string]([ADSI]”LDAP://<SourceDomain>/<SID=$sid>”).sAMAccountName + ” = ” + $_.ActiveDirectoryRights} | `
Out-File ($Env:TEMP + “\MBX_Rights_Results.txt”) -Append
}
Folder Permissions: Exchange MAPI
Folder permissions are stored within the mailbox. These access rights are set within Outlook by a mailbox owner and can be very difficult to manage. To check the folder permissions on a mailbox, you can use MFCMapi to check the folder ACLs. You can also audit the Folder Permissions of mailboxes using the Microsoft.Office.Interop.Outlook namespace through the COM object model, or the Get-MailboxFolderPermissions cmdlet from the Exchange Management Shell. The below PowerShell example will export all domain rights on an Exchange mailbox.
# Search Exchange Mailbox for Domain Rights on Folders
$exchangeMailboxes = Get-Mailbox | %{$_.LegacyExchangeDN}
foreach($exchangeMailbox in $exchangeMailboxes)
{
$folders = Get-MailboxFolderStatistics $exchangeMailbox | %{$_.FolderPath} | %{$_.Replace(“/”,”:\”)}
$folders += “”
foreach($folder in $folders)
{
$folderPermissions = Get-MailboxFolderPermission -Identity ($exchangeMailbox + $folder) | %{$_.Identity.ADRecipient.SamAccountName}
if($folderPermissions)
{
$folderPermissions = $folderPermissions -join “;” | %{$_.Replace(“;;”,”;”)}
if($folder -eq “”){$folder = “Top of Information Store”}
if($folderPermissions -ne “;”)
{
[string]$exchangeMailbox + “;” + $folder.Replace(“:\”,””) + [string]$folderPermissions | Out-File ($Env:TEMP + “\MBX_Folder_Permissions.txt”) -Append
}
}
}
}
These permissions are handled by QMM EX agents during the mailbox synchronization process. Each folder in the mailbox is analyzed for permissions, and those permissions are translated into the corresponding target object and added to the ACL Table, thus preserving access for migrated users.
Conclusion
As we can see, there are a number of ways to collaborate in Exchange, and it’s important that all of the collaboration methods are considered when migrating to a new Exchange environment. QMM provides the best all-around solution to ensuring the migration process from an end-user perspective is seamless.
