This list of best practices and tips has been assembled to further the understanding and assist with implementation questions that may arise during setup and testing.
Mappings have no impact on the matching attributes.
Mappings do not modify the Read Step; all object metadata is read.
If creating an object, such as Unified Groups in the destination the default mappings such as “GroupType” or “ObjectType” are not required because they will be auto generated by Exchange Online during creation.
If only synchronizing Group Membership, then all User attributes can be removed from the default mappings related to your group workflow and template.
Matching by “UserPrincipleName” will only match on the local part value, not the domain part.
Matching by “WindowsEmailAddress” will match on the entire string, not just the local part.
For membership/ownership to sync, within the template option, "If Users are matched" must be set to “Update”, not Skip. Skip will prevent membership from synchronizing.
During testing/piloting you may create a filter under Stage Data step to isolate a subset of test Groups to create and sync membership. This will provide a method to validate a few examples before proceeding onto creating all groups.
The Test Mode option in the workflow prevents the write data step from occurring in a workflow.
If the RecipientTypeDetails attribute mapping is missing, you will receive this error during the Stage Step. “No mapping found for RecipientTypeDetails.”
If this Name attribute mapping is missing, you will receive this error during the Write Step. “Missing required attribute: Name”.
The default mappings for Proxy Addresses (i.e. EmailAddresses) may prevent the creation of Unified Groups. The following error is received during the Write Step, “There should be at least one MOERA in Email Addresses.”.
When we create a group, we grant our account Owner access. This can be removed once Sync services are no longer required.
The “ONLY EVALUATE OBJECTS WHICH HAVE CHANGED SINCE THE LAST READ” option only affects the Stage Step. Enable this option after the initial data has been read. Do not set that setting on read and write only workflows.
By default, the “ReplaceDomain” function is used by the “WindowEmailAddress” attribute to set your default email address to the Target Domain selected within the Stage Data step. This can be changed if required.
The Delete Objects Step in a workflow is required to delete target objects if that is in scope for your project. Here are details on this step:
Reconcile finds source object XYZ is no longer in scope and removes it from CDS, adds it to a list of "Reconciled objects" for that source.
Delete step looks in "Reconciled objects" for anything from the configured source. It finds object XYZ.
Delete step then looks for a match to object XYZ from the configured target. If found, the target object is deleted.
In summary, the Reconcile step captures anything removed from the source, the delete step looks for any matching objects on the target and deletes them.
A cloud environment filter is highly recommended, so we only must process in-scope objects to be read-in for the cloud environment. This will reduce the time needed to read in the objects by Directory Sync.
Both cloud and local environments will be added and associated automatically if we create the Tenant to Tenant project first.
Due to O365 limitation, there can be no more than one cloud only objects having the same ExternalAddress, therefore, we must create the GAL object as MEU in the target cloud tenant. Contact object will be created after mailbox provisioning.
The below custom mapping will copy the source object’s WindowsEmailAddress value to target as PrimarySMTPAddress, and it will also copy the source object’s LegacyExchangeDN to the target as an x500 address.
Select mapping for ‘EmailAddresses’ and double click, enter the below expression under value field:
GetProxyAddresses(null, null, prefix(Result("WindowsEmailAddress"), "SMTP:"), prefix(LegacyExchangeDN, "x500:"))
The below custom mapping will copy the source object’s WindowsEmailAddress value to the target’s customattribute1 for matching purposes after the object is created. Customattribute1 can be replaced by another attribute if it is already taken in the tenant.
Select mapping for ‘CustomAttribute1 and double click, enter the below expression under value field:
“s.WindowsEmailAddress”
Target user objects will be created in the source as contact object because the limitation described in number 19 does not apply here. The source user object will not have the ExternalAddress set, hence there will be no duplication.
For Local to Local, the limitation described in number 19 no longer applies; therefore, we can create the GAL object as contact with ExternalAddress configured.
The below custom mapping will set the target contact’s CN as a random GUID; this is needed to avoid possible name collision as CN is not a unique attribute in Active Directory.
Select mapping for ‘DistinguishName and double click, enter the below expression under value field:
GetDn(NewGuid())
The below custom mapping will set the target contact’s targetAddress field with the source object’s mail attribute (which is also the PrimarySMTPAddress).
Select mapping for ‘targetAddress’ and double click, enter the below expression under value field:
prefix(S.mail, "SMTP:")
msExchRecipientTypeDetails and msExchRecipientDisplayType will need to be set per Microsoft requirement for Mail Contact. In this case, they should be set to “64” and “6”.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center
