Chat now with support
Chat with Support

Power365 Current - Help Center

Help Center Home Power365 Platform Tenant-to-Tenant Directory Sync Migration for Active Directory Support

Requirements

Platform Requirements

Supported Environment Deployments  

The following describes the supported migration and integration deployment models.

  • Hybrid to Hybrid –Support for the Integrated Directory experience where all your directory orchestration operations are now managed from a single web interface, there isn’t any SQL server to install and troubleshooting does not require access to local machines to review event logs.
  • Cloud to Cloud – Support for cloud-only Microsoft 365 tenant migration and integration project scenarios. This includes Domain Sharing and Moves.
  • Hybrid to Cloud – Support for migration and integration between a source Hybrid Microsoft 365 tenant and a target Cloud only tenant. This includes Domain Sharing and Moves.
  • Cloud to Hybrid – Support for migration and integration between a source Cloud only Microsoft 365 tenant and a target Hybrid tenant. This includes Domain Sharing and Moves.

Note: For Hybrid to Cloud projects, an on-premises remote mailbox in the source will be created in the target as an on-premises remote mailbox. A cloud mailbox in the source will be created in the target as cloud mailbox. If you want to go from on-premises to cloud or cloud to on-premises, you must pre-create the target user in the target and match to it.

 

Exchange Hybrid Deployments  

Power365 currently provides limited support for Exchange hybrid deployments. Environments with an Exchange Server 2013 (or later) hybrid deployment are supported, but with the following limits on functionality:

  • On-premises mailboxes will be included in free/busy sharing and GAL synchronization.
  • On-premises mailboxes cannot be included in migration activities.
  • On-premises mailboxes will not be rewritten as part of the Email Rewrite Service in Premium Integration.
  • Support for the Email Rewrite Service is limited to mail flow configurations that use Microsoft 365 for message ingress and egress. Centralized mail flow configurations that use the on-premises Exchange environment for inbound and outbound message delivery may require custom configuration with Support.

 

Browser  

Power365 is a cloud-based service. We recommend using Chrome or Firefox for the best cloud-based platform experience.

 

Internet Requirement for Online Help and Video Tutorials  

An internet connection is required to access the online help system and video tutorials.

  • Within the Power365 interface, the online help system can be accessed by clicking “Help Center” in the pull-down menu or “ONLINE HELP GUIDE” in the page footer and the video tutorials can be accessed by clicking the icons found throughout the application.
  • Windows Server operating systems will need to have the Desktop Experience feature (or a video codec) installed to view the video tutorials.

 

Application Service Account Requirements  

To set up a Power365 project type or connect environments for Directory Sync workflows the following must be provided by the owner of each of the associated Microsoft 365 tenants.

  1. Application Account: One (1) dedicated and licensed application service account to grant permissions and automatically orchestrate various activities within the project. This account must have the Exchange Online plan assigned to facilitate automatic email communications to end-users and project administrators during cutover activities, otherwise all communications will appear to be sent from the Binary Tree PowerShell account.
  2. Roles: The Global Administrator role is required for connecting environments for projects and workflows to grant permissions and to create a Binary Tree PowerShell account within each configured tenant.
  3. Licenses: At least one (1) E1 or above license must be available to be assigned to the Binary Tree PowerShell account for Migration/Integration Projects. Binary Tree Directory Sync accounts do not require licenses.

Please Note: For a tenant that has MFA policy enabled, the service accounts must be added to the MFA exclusion list or Power365 application IP addresses must be whitelisted via conditional policy.

 

For more information about Account Permissions, click here.

 

What are the minimum administrator roles required to manage a project?  

At a minimum, after project set up the following Microsoft 365 Roles are required to automatically manage various aspects of your project.

  1. Exchange Administrator Role (All project types)
  2. SharePoint Administrator Role (Advanced and Premium Integration Projects only)
  3. License Administrator Role (Premium Integration Projects only)

Important Tip: For the best application experience, it is always recommended to use the Global Administrator role. However, it is only required during the initial Project setup, reconnections to the tenant or during a Domain Cutover event, where more authority is required. All account and role management are strictly the responsibility of the tenant administrators.

Please Note: Basic Migration Projects using the Basic Authentication option do not require the Global Administrator role.

 

What accounts are required to set up Directory Sync?  

To set up Power365 Directory Sync workflows, one must connect the tenants or Local AD environments. For more information about Directory Permissions, click here.

 

Target Account Password + Sync  

You will need to manage and distribute target account credentials to each end-user prior to mailbox migration cutover. If not distributed prior to cutover, the end-user will not be able to access their new mailbox. However, you may use Power365 Directory Sync to synchronize your user's current password prior to cutover so they know the password is the same. Providing a more seamless migration experience.

 

Modern Authentication Requirements  

All Power365 project types (excluding Basic Projects using the Basic Authentication option) take advantage of Modern Authentication to help manage your projects. Modern Authentication is the default behavior for all Microsoft 365 tenants. Unless it was disabled, no action is required. However, we recommend the following configuration parameter is validated prior to deployment.

Get-OrganizationConfig | Format-Table Name,OAuth* -Auto

If Modern Authentication is disabled it must be enabled prior to any migration activities can proceed. To enable Modern Authentication for Exchange Online, run this command under the correct authority.

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

Here is some additional information about how to Enable modern authentication in Exchange Online.

 

PowerShell  

The following accounts are required:

  • Account: One Cloud-only account will automatically be created during project setup.
  • Microsoft 365 Administrator Roles: Automatically assigned the Exchange and SharePoint Administrator roles.
  • Microsoft 365 License Requirements: Automatically assigned one available license (E1 minimum) for destination tenants.
  • Additional Exchange Admin Roles: Automatically assigned the ApplicationImpersonation Role to the PowerShell Service Account when Outlook Setup Pro or Desktop Setup Pro is enabled in the project.
  • The accounts must be excluded from MFA requirements.

Important Note: This account will automatically be assigned the Global Administrator role at the start of a Domain Cutover event, where more authority is used to complete the process.

Note: Basic Migration Projects using the Basic Authentication option do not create the Binary Tree PowerShell account; your provided service account will be used for any PowerShell related activities.

 

The SPO PowerShell module used for OneDrive migration requires Legacy Authentication to be enabled. Legacy Authentication can be enabled in the tenant using the following command:

  • Set-SPOTenant -LegacyAuthProtocolsEnabled:$true

 

 

Additional Information  

Basic Migration Requirements

Advanced Migration with Discovery Requirements

Premium Migration + Integration Requirements

Premium Migration + Integration Pro Requirements

Directory Sync Requirements

Active Directory Requirements

Security

How to Process GDPR Requests

What is a GDPR Request?  

The General Data Protection Regulations (GDPR) is the new European Union (EU) data protection regulations which go into effect May 25th, 2018. Under the GDPR individuals have certain rights to their personal data. They can make requests to exercise those rights to the data controller, and the controller must respond within 1 month. It is expected that the controller will verify the identity of the requestor.

 

There are four primary types of GDPR requests:

 

  1. Export – Request for a copy of all personal data about an individual held by this controller and any related processors. Must be in a commonly accepted portable data format.
  2. Update – Request to rectify inaccurate personal data.
  3. Delete – Request to remove all personal data about an individual from our systems. Can be initiated by an individual or by a revocation of consent process. Includes burden of proof. (Ideally follow a Delete with an Export to show no remaining data)
  4. Hold – Request to halt processing of personal data but not delete that data.

 

How to handle GDPR Requests for Migrator Pro for Active Directory 

When Migrator Pro for Active Directory is installed, the data associated with the application is hosted locally within the client’s environment. The client has full control over this data. By default, the user and configuration data is stored in the SQL database called, “DirectorySyncPro_<date>”. It is assumed the operator has the proper administrative SQL Permissions to execute the following methods outlined.

 

SQL Tables containing User data:

  • [DirectorySyncPro_<Date>].[dbo].[BT_Person]

    Unique Key Look-up Columns:

         [SAMAccountName]

         [TargetSAMAccountName]

         [TargetUserPrincipalName]

         [OriginalSAMAccountName]

         [OriginalUserPrincipalName]

         [UserPrincipalName]

    If user data is used for matching (e.g. SAMAccountName, UserPrincipalName, etc.) then those values will also appear in one of the following columns:

         [MatchValue1]

         [MatchValue2]

         [MatchValue3]

         [MatchValue4]

  • [DirectorySyncPro_<Date>].[dbo].[BT_Groups]

    Unique Key Look-up Columns:

         [MatchValue1]

         [MatchValue2]

         [MatchValue3]

         [MatchValue4]

Be aware that data can be mapped to different Internal Fields (table columns) depending on customer specific configuration, so just about any SQL column could theoretically contain user data if so configured. For example, if SAMAccountName has been mapped to Custom001 or to any other Internal Field selectable in the mappings then that field could contain personal data. Therefore this process should be undertaken by someone knowledgeable about the schema and attribute mappings in use. It may also be helpful to work with Support when completing these requests if your administrator is not comfortable with the database.

 

Where does the Migrator Pro for Active Directory get its user data?  

All user data within Migrator Pro for Active Directory is derived from the source Active Directory Forest configured in the product. Therefore, the authoritative source of any user related data stored in Migrator Pro for Active Directory is Active Directory. Any remediation required from a GDPR request should first be remediated in Active Directory or the source feeding Active Directory. Once that user data is updated in the source directory, running a new discovery within the product will update those values as well.

 

The following sections will provide guidance on fulfilling the 4 primary GDPR request types.

 

1. Exports – Request for a copy of all personal data about an individual held by this controller and any related processors. Must be in a commonly accepted portable data format.

 

 

For the purposes of this document, using PowerShell with the SQLPS Module is the recommended method to refine the results of the output. The administrator may export any SQL Query result to a CSV file. Below is an example script to do so. Replace the variables to conform to your environment.

 

     Import-Module sqlps

     $SQLquery='SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]'

     $result=invoke-sqlcmd -query $SQLquery -serverinstance <servername> -database <dbname>

     $result |export-csv c:\temp\ExportQueryResults.csv -notypeinformation

 

2. Updates – Request to rectify inaccurate personal data.

 

As previously stated, all user data within Migrator Pro for Active Directory is derived from the source Active Directory Forest configured in the product. Therefore, the authoritative source of user data is Active Directory. Any remediation required from a GDPR request should first be remediated in Active Directory or the source feeding Active Directory and it will be pulled into the product during the next discovery process.

 

If editing the user data within SQL is still required, using any SQL editor such as SQL Server Management Studio, run an update command against one or more columns for one or more records. Below are examples to accomplish this. Note however, that any new discovery will update the values based on the source Active Directory.

 

     Update multiple columns for a single record:

     UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

     WHERE userPrincipalName='<Unique ID>'

 

     UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

     WHERE userPrincipalName='<Unique ID>'

 

     Update multiple columns for multiple records:

     UPDATE [DirectorySyncPro_<Date>].[dbo].[CMTEUP_Person]

     SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

     WHERE DistinguishedName='<Unique ID>' OR DistinguishedName='<Unique ID>'

      

     UPDATE [DirectorySyncPro_<Date>].[dbo].[CMTEUP_PersonADData]

     SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

     WHERE userPrincipalName='<Unique ID>' OR userPrincipalName='<Unique ID>'

 

     Update multiple columns for multiple records using a list:

     UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

     WHERE DistinguishedName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

     UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

     WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

3. Deletes – Request to remove all personal data about an individual from our systems. Can be initiated by an individual or by a revocation of consent process. Includes burden of proof. (Ideally follow a delete with an Export to show no remaining data.)

 

Using any SQL editor such as SQL Server Management Studio, run a Delete command against one or more records. Below are examples to accomplish this. However, as previously stated, if the user is not deleted in the source Active Directory then during any subsequent new discovery the user will be re-populated into SQL. The only way to truly remove the data is to delete the source user or delete the entire SQL database when it is no longer required.

 

     Delete a single record then verify:

     DELETE FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE SAMAccountName='<Unique ID1>'

 

     SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE SAMAccountName='<Unique ID1>'

 

     DELETE FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE userPrincipalName='<Unique ID1>'

 

     SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE userPrincipalName='<Unique ID1>'

 

     Delete multiple records then verify:

     DELETE FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE SAMAccountName='<Unique ID1>' OR SAMAccountName='<Unique ID2>'

 

     SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE SAMAccountName='<Unique ID1>' OR SAMAccountName='<Unique ID2>'

 

     DELETE FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE userPrincipalName='<Unique ID1>' OR userPrincipalName='<Unique ID2>'

 

     SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE userPrincipalName='<Unique ID1>' OR userPrincipalName='<Unique ID2>'

 

     Delete multiple records then verify:

     DELETE FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE SAMAccountName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

     SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE SAMAccountName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

     DELETE FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

     SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]

     WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

4. Holds – Request to halt processing of personal data but not delete that data.

This can also be accomplished using the product interface. Halting a user from processing within Migrator Pro for Active Directory can be achieved using the Exclusion List feature.

 

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating