Tchater maintenant avec le support
Tchattez avec un ingénieur du support

On Demand Migration Current - Active Directory User Guide

Users and Mailboxes

What is a user?  

A user within Domain Move is any Microsoft 365 or Active Directory objects with an associated Mailbox. This includes users, rooms, equipment, shared and group mailboxes.


When are users displayed?  

After you have discovered your users.


How do I view users and mailboxes?  

You may navigate to your users and mailboxes from the Project Dashboard.

From the Dashboard, just click Total Users to open the user management view.


Can I filter the user view?  

Yes, you can filter the list by many criteria including migration wave and synchronization status. The list will narrow as you add criteria.

When you have narrowed your search, you can select one or more users, and then perform any actions against them or choose View Selected User to narrow your view even more. You may narrow the list by entering a search term. Each column can be sorted via the directional arrows.


How do I view user and mailbox details?  

Double-clicking on a user will bring up detailed information about the status of all processes in progress for that user.

Groups and Teams

How do I view groups and teams?  

You may navigate to your groups and teams from the Project Dashboard.

From the Dashboard, just click Total Groups to open the group management view.


What is an Office 365 Group?  

Microsoft Office 365 Groups are a shared workspace for email, conversations, files, and events where group members can collectively get stuff done.

Available through the Microsoft 365 suite of cloud services, Office 365 Groups allows users to create and manage ad hoc "groups" for collaboration. The group provides members access to a shared inbox (conversations), calendar and file repository.

For more information, check out these Microsoft articles on the topics.


What is Microsoft Teams?  

Microsoft Teams is a Group Chat feature of Microsoft 365 that brings everything together in a shared workspace where you can chat, meet, share files, and work with business apps.

Click here to learn more about Microsoft Teams.

Directory Sync

Directory Sync Requirements

Directory Sync is built with Microsoft Azure. Our Software-as-a-Service (SaaS) platform is designed to handle a variety of directory synchronization scenarios to meet your coexistence and collaboration needs.

Directory Sync can manage simple AD to AD, Cloud to Cloud, and more complex scenarios including combinations of local and cloud mixed environments.


What is required to get Directory Sync set up?  

You will need 2 items to get started with setting up Directory Sync.

  1. The authorized account(s) that allow changes to your local and/or cloud directories
  2. At least one (1) local on-premises server to host the local agent (if applicable)

The following information provides details around the specific component requirements.



Directory Sync is a 100% SaaS platform but to commit changes to on-premises directories (if applicable) such as Active Directory, a local agent must be installed and configured.

You will need at least one Directory Sync Agent installed per forest (environment). You may have up to five agents per forest. Adding more agents can offer limited fault-tolerance and can improve synchronization throughput, especially for near real-time password synchronization.

Important Tip: If you are only connecting to Azure AD, local agents are not required.



This local agent must meet the following minimum requirements:

  • At least one (1) Windows Server 2012 R2, 2016 or 2019
  • Additional Windows servers may be deployed. Limit to 5.
  • CPU: 4 Cores
  • Memory: 4GB Free
  • Disk: 40GB Free Disk Space excluding Operating System.

Important Tip: Do not install any local agents on AD domain controllers in a production environment.



This local agent must meet the following minimum requirements:

  • Windows Server 2012 R2, 2016 or 2019
  • .NET 4.5.2 (will automatically be installed unless already present)
  • TLS 1.2 or higher


Domain and Forest Functional Levels  

  • 2012 R2 or 2016



  • Connecting to the Directory Sync web interface uses TCP port 443 (HTTPS).
  • Agent connections are initiated by the agent and require port 443 access to Directory Sync SaaS application.
  • Connecting to DCs uses TCP on ports 139, 389 (UDP), 445, and 3268.
  • Copying SID History uses TCP on ports 135, 137-139, 389 (UDP), 445, 1027, 3268, and 49152-65535.



Local Active Directory Account

  • The agent installer will prompt for a domain account with permission to read and write on-premises Active Directory.
  • An agent intended to sync all domains in a forest, must have access rights to all domains and objects used in workflows.

Azure AD Application Account

  • When creating a new Cloud Environment, an account with the Global Administrator Role is required to grant permissions and establish a connection.

Azure AD PowerShell Accounts

  • An OAuth token will be used by the application to create two (2) PowerShell accounts which are used to read and update objects in the cloud.
  • The accounts being used do not require any Microsoft 365 licenses.


Password Synchronization  

The following conditions must be met for Password Sync:

  • ADMIN$ must be accessible on the domain controller from the Directory Sync agent server.
  • The Password Sync functionality requires that either a domain admin role or built-in admin role be granted to the service account.
  • Any third-party anti-virus program that prevents access the LSASS process may need to be updated with a whitelist entry for the Password Sync executable.


SID History  

  • A trust relationship must exist between that source and target domain. Typically, this is done by establishing a Forest level trust, but can also be done as a domain trust.

  • The target account must have administrator permissions in the source domain. To enable this, the target account of the Directory Sync agent should be added to the source PDC's built-in administrator group.

  • Auditing of the source and target domain must be enabled. This can be enabled as a global policy for all domain controllers or as a local policy on the specific source and target DCs involved. To enable auditing as a local policy, go to gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy and enable the “Audit account management” and “Audit directory service access” settings.

    Local Group Policy Editor

  • ‘Account Management’ and ‘DS Access’ Advance Audit policies of the source and target domain should be configured if Advance Auditing are configured in the environments. These settings can be enabled as a global policy for all domain controllers or as a local policy on the specific source and target DCs involved.

    • To enable advance audit policy for Account Management, go to gpedit.msc > Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Account Management enable Success and Failure audit for the below policies.
    • Audit Application Group Management
    • Audit Computer Account Management
    • Audit Distribution Group Management
    • Audit Other Account Management Events
    • Audit Security Group Management
    • Audit User Account Management

    • To enable advance audit policy for DS Access, go to gpedit.msc > Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > DS Access and enable Success audit for the below policies.
    • Audit Directory Service Access
    • Audit Directory Service Changes
    • Audit Directory Service Replication
    • Audit Detailed Directory Service Replication

  • An empty Domain Local security group must be created in each source domain and named {SourceNetBIOSDomain}$$$.

  • The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport registry key must be set to 1 on the source domain primary domain controller. You must restart the source domain primary domain controller after the registry configuration.

  • MigratesIDHistory permissions are required on the target domain. This is typically enabled for Domain Admins and Enterprise Admins, but can be enabled for a specific group or user by following the below steps:

    1. Right-click on your target domain in Active Directory Users and Computers.
    2. Select the Security tab and add or update the desired group or user and enable the “Migrate SID History” permission.

      Security tab of Properties

Important Tip: For further guidance from Microsoft about Using DsAddSidHistory, click here.


Workflow Alerts  

• To create a workflow alert, simply have a valid SMTP address ready.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation