-
Titel
Mail redirection changes for Office 365 migrations -
Beschreibung
Modifications made after 8.9 release are in red. Additions are since these updates: 8.9: 20130627EX, 20130702; 8.10: 20130826, 20130829EX. Removals are since 8.10 updates 20130918EX and 20130920.
The process uses LDAP to update AD attributes and PowerShell Remoting for Exchange Online changes.
Only AD users with mailboxes are supported. The product determines the mailbox using homeMDB user attribute in AD. (Mail-enabled users (user with external address), groups, contacts are excluded from the process.)
-
Lösung
Switch (mail redirection setup from AD to EO)
Modified AD user attributes
Modified EO Mailbox properties
targetAddress =
<EO obj ID or existing>@<EO domain>[1]ForwardingSmtpAddress is cleared
EmailAddresses added:
LEDN from AD with “x500:” prefix,
mail from AD with “smtp:” prefix and
<EO obj ID or existing>@<EO domain> with “smtp:” prefix
WindowsEmailAddress = mail from AD
PrimarySmtpAddress = mail from AD[2]Unswitch (mail redir setup from EO to AD), also mbx licensing in QMMEx
Modified AD user attributes
Modified EO Mailbox properties
targetAddress is cleared (with exceptions)[3]
proxyAddresses added:
LEDN from EO with “x500:” prefix,
UserPrincipalName from EO with “smtp:” prefixand smtp:<ObjectPairID>@<on-premise domain>4WindowsEmailAddress = mail from AD
DeliverToMailboxAndForward = false
ForwardingSmtpAddress = <ObjectPairID>@<on-premise domain>[4]
EmailAddresses added:
LEDN from AD with “x500:” prefixMigration and Sync
For merging the mail redirection setup is performed only if mail attribute was updated.
For new user creation the mail redirection setup is performed always.When merging with EO Mailbox then almost unswitch is used. When target is EO MailUser (when new user is being created), another redirection setup mechanism is used:
Modified AD user attributes
Modified EO MailUser properties
proxyAddresses added:
LEDN from EO with “x500:” prefix and
UserPrincipalName from EO with «smtp:» prefixExternalEmailAddress = mail from AD
EmailAddresses added:
mail from AD with “smtp:” prefix[5] and
LEDN from AD with “x500:” prefix
WindowsEmailAddress = mail from AD5
PrimarySmtpAddress = mail from AD[6]
[1] EO obj ID — aelita-Amm-TargetGUID from ADAM in the form of 32 hex-digits. EO domain — from connection.
[2] Only WindowsEmailAddress is set explicitly. PrimarySmtpAddress is set because of side-effect.
[3] In migration/sync targetAddress stay unchanged if it was set.
[4] on-premise domain — from mail attribute in AD or alt redir domain (if specified). ObjectPairID — objectGUID from ADAM in the form of 32 hex-digits or an existing address, if alt redir domain is not equal to primary SMTP.
[5] Minor side-effect from setting ExternalEmailAddress.
[6] Side-effect from setting ExternalEmailAddress, that cannot be avoided.
-
Weitere Informationen
In a hybrid scenario where the DSA is synchronizing between the same source mailbox-enabled accounts and the target AD on premise, the mailbox is not switched. As a result the DSA (working with a different project database to MAgE) may clear the source "targetAddress" attribute where the target object is still a mail-enabled user with a populated targetAddress. Adding an LDAP filter on the DSA to only synchronize objects with an empty targetAddress attribute will avoid the conflict. When the mailbox is switched to Office 365, MAgE sets a redirector on the source mailbox-enabled user (populates the targetAddress), This then automatically removes it from the scope of the DSA, preventing it from removing targetAddress.