Supported Operating Systems |
|
PowerShell Requirements |
|
.NET Framework Requirements |
|
Operating System Requirements |
|
Supported Operating Systems |
|
Additional Requirements |
|
Domain Controller Access
For most scenarios, Migrator Pro for Active Directory requires access to at least one read/write domain controller in each source and target Active Directory domain. For fault tolerance, at least two domain controllers in each source and target domain is recommended.
If SID History will be synchronized, any domain controller listed in the Target DCs tab within a Directory Sync Pro for Active Directory profile will require access to the domain controller holding the PDC Emulator Active Directory FSMO role in the source. Keep in mind that even if the domain controller holding the PDC Emulator Active Directory FSMO role is not listed in the Source DCs tab, any SID History migration attempts will require a DC in the target to communicate with the PDC Emulator domain controller. For this reason, it is a best practice to ensure that all domain controllers specified on the Target DCs screen within a Directory Sync Pro for Active Directory profile have the appropriate networks access to communicate with the source domain controller holding the PDC Emulator Active Directory FSMO role before a SID History migration is attempted.
In limited scenarios, it is possible that Migrator Pro for Active Directory will not be responsible for creating or updating any accounts in the source or the target domains. In this scenario, Migrator Pro for Active Directory can be configured to communicate with Read Only Domain Controllers (RODCs).
Network/Firewall Requirements
Migrator Pro for Active Directory requires the following network ports to enable full functionality:
Source |
Target |
Port/Protocol |
Workstations and Member Servers |
Migrator Pro for Active Directory Server |
443 (TCP) or 80 (TCP) |
Migrator Pro for Active Directory Server |
Source and Target Domain Controllers |
135, 137, 389, 445, 1024-5000 (TCP) 389 (UDP) |
Migrator Pro for Active Directory Server |
Source and Target Domain Controllers |
135, 137, 389, 445, 49152-65535 (TCP) 389 (UDP) |
Target domain controllers listed in the Target DCs tab |
Domain controller in the source environment holding the PDC Emulator Active Directory FSMO role |
135, 137, 139, 389, 445, 3268 and 49152-65535 (TCP) 389 (UDP) |
The following ports need to be opened between workstations/servers and writable domain controllers for a successful domain join operation:
Type of Traffic |
Protocol and Port |
DNS |
TCP/UDP 53 |
Kerberos |
TCP/UDP 88 |
EPM |
TCP 135 |
NetLogon, NetBIOS Name Resolution |
UDP 137 |
DFSN, NetLogon, NetBIOS Datagram Service |
UDP 138 |
DFSN, NetBIOS Session Service, NetLogon |
TCP 139 |
C-LDAP |
TCP/UDP 389 |
DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc |
TCP/UDP 445 |
LDAP SSL |
TCP 636 |
Random RPC |
TCP 1024-5000 |
GC |
TCP 3268 |
GC |
TCP 3269 |
DFS-R |
TCP 5722 |
Random RPC |
TCP 49152-65535 |
Migrator Pro for Active Directory does not require HTTPS (HTTP with SSL), and can operate using HTTP. However, it is strongly recommended to implement Migrator Pro for Active Directory using HTTPS to secure communications between the devices to be migrated and the Migrator Pro for Active Directory Server. In order to activate HTTPS on the IIS component in Windows, the Migrator Pro for Active Directory system will require that a SSL certificate is present.
An SSL Certificate is not provided as part of the installation. For the most secure installation, purchasing an SSL Certificate from a Windows supported 3rd party provider is recommended.
In scenarios where this is not possible, self-signed SSL Certificate can be generated in Windows following these directions: https://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspx
If using a self-signed certificate, it should be noted that Migrator Pro for Active Directory’s agent component would utilize the operating system’s certificate trust list. Due to the security nature of Active Directory migrations, there is no method of implementing an override and forcing the agent to use an untrusted certificate. If a self-signed certificate is used, that certificate will need to be added to the trusted root certificate list for all computer objects to be migrated. This can be accomplished via group policy: https://technet.microsoft.com/en-us/library/cc738131(v=ws.10).aspx
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center