• During configuration, you will be asked to choose your source and target domains for each tenant. This process is called domain pairing.
You will need to select a pair of attributes that will match exact values from the source user object to the target user object to discover and match the appropriate user accounts.
The available matching attributes are as follows, choose at least 1 with a maximum of 3:
Note: The userPrincipalName and mail attributes are matched based on the local part of the address and the paired Domains (e.g. Tom.Dean@contoso.onmicrosoft.com would use Tom.Dean@binarytree.onmicrosoft.com as a match against the target account.)
To manage eligibility for Mailbox Migrations and other Integration services, Power365 provides the ability to discover users and groups from Active Directory (AD) Group membership. Instead of searching the entire Forest or Domain, Power365 will only act on objects based on group membership. For Premium Integration projects, the group must be created on-premises and synchronized to your Microsoft 365 tenant. Once a user is added to the group and discovery runs again, the user will be added to the list of eligible accounts for migration or related services. All AD groups created should be Mail-Enabled, Universal (scope) Security (type) groups. The following information provides details for each AD Group requirement.
- Discovery Group: We recommend creating a group just for this purpose. Create a local mail-enabled Universal Security AD group named, for example, “BTDiscovery”. Then populate the group with all eligible mailbox-enabled Users. Group membership should be limited to mailbox-enabled objects eligible for migration. Other members will be skipped during discovery.
- Migration Waves Groups: Optionally, you may sort mailbox-enabled Users into separate local AD Groups so they can be easily assigned to a migration wave and scheduled for migration. If organizing your migration users in this manner, then create each local AD Global Security group with a descriptive name for the migration event.
Free/Busy Group: Sharing Calendar Availability (Free/Busy) relies on Active Directory Group membership to identify eligible users. We suggest that you create a group just for this purpose. For example, create a local AD group in the source AD named, “BTFreeBusy”. Then populate the AD Group with any user eligible for calendar availability sharing. If no group is provided, all users will be configured for Sharing Calendar Availability.
Email Rewrite Group (Premium Integration only): After implementation, Power365 with Premium Integration will automatically create two cloud-based groups called “BT-IntegrationPro-DayONE” and “BT-IntegrationPro-DayTWO” in the source tenant. Power365 will also create the same groups automatically in the Target tenant to represent all users eligible for rewrite services. Power365 will manage the groups. These groups allow you to choose which users have their email address rewritten.
For any source user added to the “BT-IntegrationPro-DayONE” group, their email addresses will automatically be rewritten to match their target SMTP Domain, as if they have already been migrated to the target.
For any migrated target user added to the “BT-IntegrationPro-DayTWO” group, their email addresses will automatically be rewritten to match their source SMTP Domain, so it will appear as if they have NOT yet been migrated.
These groups will not be prepopulated with membership during creation. This is a manual process, so when someone requires rewrite services, you must add them to the desired group. Or, remove them to stop the service for the user – all in real time.
The following information provides details on the additional component requirements related to the deployment of a Premium Integration project. All previous requirements outlined for the platform and migrations are still applicable. To review those requirements, see the Additional Information section below.
If your organization has multiple Active Directory Forests are connected to your Microsoft 365 tenants, this is supported scenario for migration and integration. There are no additional requirements to support this deployment type.
Power365 has the option to automatically configure your Microsoft 365 tenant organization relationships between tenants configured in your project.
During project set up you will be asked if you want to share calendars, if you do, we recommend the following:
Free/Busy Group: Sharing calendar availability (Free/Busy) relies on AD Group membership to identify eligible users. We suggest that you create a group just for this purpose. For example, create a local AD group in the source AD named, “BTFreeBusy”. Then populate the AD Group with any user eligible for calendar availability sharing.
Please Note: If no group is provided, all users will be configured for calendar availability sharing between tenants.
Important Tip: If an existing Exchange Online organizational relationship is configured between the tenants, we recommend skipping this option.
Power365 has the option to automatically assign Microsoft 365 subscriptions and plans to the target user(s) during the provisioning step taken during the first content sync.
To automatically provision user licenses the following must be in-place prior to running the provisioning step or first content sync.
- The target tenant must have the available licenses to be assigned to the users.
- The target customer application account used to set up the project must be assigned at a minimum the License Administrator Role for automated license assignment. The Global Administrator role is recommended.
For more information about minimum roles, click here.
Power365 supports all Microsoft 365 SKUs that contain Exchange Online plans within them. Without an Exchange Online plan, mailboxes cannot be provisioned to begin content sync.
- E3, E4 or E5 licenses are supported for automatic assignment. This means if your source and target use E3, 4 or 5 then Power365 can mimic the source when assigning licenses to the target user.
- If you utilize other SKUs, you may simply choose which SKU to apply.
- Different SKUs may be assigned to different users or grouping of users using Migration Profiles.
Power365 Premium Integration projects provide automatic orchestration of directory objects to provide capabilities to create and update directory objects during critical points within the migration or coexistence life cycle. To facilitate these activities the following is required for set up.
For hybrid or mixed environments, where your local Active Directory (AD) is being synchronized to Microsoft Entra ID the following is required.
- At least one (1) Windows server to host the local Agent.
- During set up, install at least one (1) local Agent in each AD Forest. Up to 5 agents are supported. One (1) agent per server.
- Account credentials for one (1) AD account with permissions to create and update objects within the designated Organizational Units (OU).
- Account credentials for one (1) Global Administrator within your Microsoft 365 tenant.
- Designated OUs in each environment to create new objects.
For additional details about local Agents, visit Directory Sync Requirements.
For cloud only environments, where there is no local Active Directory the following is required.
- Account credentials for one (1) Global Administrator within your Microsoft 365 tenant.
For more information about account permissions, click here.
For complete details about local Agents, visit Directory Sync Requirements.
When deploying a Premium Integration project that involves at least one (1) hybrid environment you must choose or create designated Organizational Units within your local AD Forest to allow new User or Contact objects be created.
The Active Directory forest attached to the Microsoft 365 Tenant must have the Microsoft Exchange 2010 SP3 (or later) schema extensions applied.
When deploying a Premium Integration project that includes Office 365 and Teams migrations, the following Directory Sync workflow must be manually configured to facilitate the synchronization of group membership to ensure all migrated users are properly assigned the correct roles to the target Group or Team.
The following information provides details on the additional component requirements related to deployment of Premium Integration Pro projects. Premium Integration Pro projects offer two (2) additional services on-top of the Premium Integration projects, which includes Email Rewrite Services for tenant-to-tenant Domain Sharing and automated Domain Cutover services which orchestrate the consolidation of Exchange Online Accepted Domains from one tenant to another.
All previous requirements outlined for the platform, integration and migrations are still applicable. To review those requirements, see the Additional Information section below.
To deploy Email Rewrite Services (ERS) between tenants the following will need to be ready prior to the configuration of the service.
During initial project set up you may choose to configure ERS now, if you are ready or later after the initial discovery is complete.
ERS Deployment Checklist:
The following checklist provides a quick reference to the items or decisions required to begin configuration of ERS.
- Procure one (1) SSL single domain certificate for each tenant environment using one (1) of the accepted domains.
- The password associated with the SSL certificate will be required when uploading each certificate.
- Choose which domains will particulate in ERS.
- Deploy DKIM DNS TXT records for each tenant environment during project set up.
Once ERS is configured and deployed, the next step is to prepare eligible users.
ERS User Preparation Checklist:
To successfully configure the Email Rewrite Service, a valid SSL certificate must be procured for each source and target tenant. Each certificate must contain a single accepted domain, one (1) for each tenant. The selected certificate cannot contain subject alternative names (SAN). The common name (Subject Name) must match one (1) of the Exchange Online accepted domains configured within the tenant.
This certificate is utilized to secure the Exchange Online connectors over TLS that will be used to transfer message between the Email Rewrite service and each tenant. The new certificates will be uploaded to the project using a PFX formatted certificate. PFX files contain the public key file (SSL Certificate file) and the associated private key file (password).
The requirements for the certificate are as follows: (Names are for example purposes only.)
- Common Name: contoso.com
- Cryptographic service provider: Microsoft RSA SChannel Cryptographic Provider
- Bit length: 2048 or higher
- Must be valid for Server Authentication and Client Authentication.
- Must be signed by a trusted public root CA.
- Must contain a private key (password).
- Must not expire before the end of the project.
- Must have a Friendly Name defined.
Important Tip: The domain listed on the certificate cannot be moved as part of a Domain Cutover process. If you plan to move all accepted domains, you should plan to acquire a certificate for a newly created accepted domain to use as a placeholder. This domain will not be moved or used; it will be used only as the subject for the TLS certificate.
Power365’s Email Rewrite Service ensures email authenticity after rewrites by signing messages using a Domain Keys Identified Mail (DKIM) certificate. To properly sign emails, a DKIM certificate will automatically be generated and assigned to each participating domain(s) in the source and target tenants.
Each participating Accepted SMTP Domain from the source and target tenants will require a DKIM TXT record be created in your public DNS. During project configuration, Power365 will generate all the required parameters to easily and quickly publish your TXT records for each domain.
Each participating Accepted SMTP Domain from the source and target tenants will require to enable DKIM at the tenant level, additional information can be found at this Microsoft Link How to use DKIM for email in your custom domain - Office 365 | Microsoft Learn
To complete set up of ERS the DKIM/Email Signatures DNS txt record must be published in the source and target public DNS. Once the records are published, Power365 will automatically verify the records. Once verified you will be able to complete the project’s ERS configurations.
The following is an example of the TXT record parameters required to publish the record. Your key will be unique to your project.
- Name: selector1._domainkey
- Type: TXT
- TTL: 10
- Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmvFUb+TkozfdnA0dA3AHOwAUYdfNVlBkR72+gqp2GxwK8yYPRI/E1/zp5DDZ/i8epWTR/F9u4jDJxjLqYF9d8m7qhJFjXxzWH2TbMQC4VgUfRtq5WAJmPUrCBdxxvMoOAKQ+aYagtXpv9HlH7PAKXsUFbqGGZ0GQFSvM0GKC7hQIZZQAB
Please Note: Power365 supports existing Exchange Online DKIM certificates and does not interfere with the ERS DKIM certificates. A unique selector will be provided if Exchange Online DKIM certificates are found.
When planning the deployment of Email Rewrite Service (ERS) we recommend the following regarding Sender Policy Framework (SPF) records:
- Update your existing SPF record to include the Binary Tree Power365 list of acceptable domains. This will prevent any hard failures when routing mail through the ERS relays.
Include the following domains with your SPF record from all source and target domains participating in ERS:
Important Tip: Do not plan on utilizing the default “tenant.onmicrosoft.com” domain when deploying Power365 Email Rewrite Services (ERS). This is due to concerns regarding the external recipient domain's having SPF hard fail enabled. Click here for more details.
If your organization utilizes Domain-based Message Authentication, Reporting and Conformance (DMARC) to prevent email spoofing, then Power365 Email Rewrite Services (ERS) is DMARC ready.
There are no additional requirements to support DMARC with ERS, however it is highly recommended that the following related topics be reviewed prior to execution.
There are no additional requirements to set up Domain Cutover services, however it is recommended that the following related topics be reviewed prior to execution.
Important Tip: The domain listed on the SSL certificate cannot be moved as part of a Domain Cutover process. If you plan to move all accepted domains, you should plan to acquire a certificate for a newly created accepted domain to use as a placeholder. This domain will not be moved or used; it will be used only as the subject for the TLS certificate.
As of May 29, 2020, Directory Sync Lite is no longer the standard deployment option for Premium Integration and Integration Pro projects.
All new projects created after May 29th, 2020 will utilize Power365 Directory Sync services to automate and orchestrate all preparation of directory objects for migration and coexistence services.
All existing Premium Integration automation functionality will continue to be supported. In fact, additional capabilities have been gained with the replacement of Directory Sync Lite. Read on for more information.
By utilizing Power365 Directory Sync instead of Directory Sync Lite you will gain the following additional features or capabilities:
- Now supports Tenant-to-Tenant hybrid, cloud only and mixed environment scenarios for migration and coexistence with domain sharing and cutovers.
- Real-Time Password Sync for Active Directory.
- Expanded Group Sync capabilities where all group types are supported including local and cloud groups along with Office 365 Groups and Teams.
- Expanded Address Book Sync capabilities to manage additional properties and more complex mixed environment scenarios including support for Microsoft Microsoft Entra ID Business-to-Business (B2B) guest accounts.
- Expanded properties and options for user’s personal contact information.
- Expanded Domain Move (Cutover) capabilities for mixed scenarios including but not limited to cloud-to-cloud and hybrid-to-cloud.
- Continuous Object Attribute Sync before and after migrations.
- Object attribute transformation of standards, defaults and property controls.
- Trustless SID History Migration options for Active Directory.
- Customizable Prepare, Provision and Cutover orchestration workflows.
- Add your own PowerShell scripts to your Prepare, Provision and Cutover orchestration workflows.
There are a few items to note regarding the deployment of an Integration Project without Directory Sync Lite.
- Installation and configuration of the local agents are quicker, simpler and lighter. Reducing the overall deployment time and burden.
- A SQL server is no longer required for installation.
- Object change logs are now available within the main application interface and you are no longer required to review logs locally on a separate server.
- Local Agents can scale up to 5 nodes for redundancy and load-balancing.
- Cloud only deployments are now supported. Local Agents are only required for hybrid deployments of Microsoft 365 where objects are managed locally within Active Directory.
- The Project setup will require you to choose your target OUs for hybrid deployments so that Power365 knows where to create new User and Contact objects.
- Address Book Sync (i.e. GAL Sync) is now fully part of Power365 Directory Sync and no longer managed from Power365 Tenant-to-tenant. Which provides broader capabilities and options to manage more complex Address Book Sync scenarios.
- Distribution Group Sync is now fully part of Power365 Directory Sync and no longer managed from Power365 Tenant-to-tenant. Which provides broader capabilities and group type options including Office 365 Groups and Teams to manage more complex Group Sync scenarios.
- The option to keep a user’s Personal Contact Information such as Phone, Title and Department in sync during the migration project has been moved to Power365 Directory Sync where it is no longer limited by the migration lifecycle. With Power365 Directory Sync you may choose to sync these and many more attributes for as long as required, before and after a migration project.
Use the following links to review the original Directory Sync Lite documentation.