General FAQs
What ports does the agent use to connect?
The Power365 Migration for Active Directory Agent uses three outbound ports
- TCP 443/80
- UDP 3030
I’ve installed the agent and the device isn’t ready, what do I do?
On startup the Power365 Migration for Active Directory agent will phone home sometime in the first four hours. This communication offset time is an agent specific random and evenly distributed offset so the initial communications of a large number of devices set up at once will be spaced out and not overload the servers. If your device has the agent installed but you haven’t waited up to four hours yet, wait up to four hours and then re-check the Ready Devices list to see if your device shows up before proceeding to other network troubleshooting operations.
How do I adjust the agent polling interval?
In Power365 Migration for Active Directory, unlike in Active Directory Pro, the agent polling interval is not end user adjustable. The polling interval is every two minutes over UDP and every four hours over TCP. Should this amount of network traffic be an issue contact Support to investigate reducing the polling interval. Note that reducing the polling interval will cause queued migration actions to take longer to be picked up by the agents.
How many migration actions can I queue at once?
In Power365 Migration for Active Directory you can queue as many migration actions at once as you would like. There is a hard limit of 600 agents per each two minutes who will be notified by the job availability cache that they have a job waiting for them. Therefore the minimum amount of time which could be required for those queued migration actions to be picked up will be the number of queued migration actions divided by 600 and multiplied by two minutes.
Agent last contact time isn’t updating every two minutes is something wrong?
In Power365 Migration for Active Directory the Agent last contact time is updated based on the TCP connection with the back end. This will occur if a job is retrieved or every 4 hours as a fall back. It is not expected that the agent last contact time will update every two minutes even if the UDP requests to the job availability cache are functioning correctly.
The machine name was changed during the migration project, will it keep working?
Changing the machine name during a migration project may have unexpected implications. We recommend that you avoid doing so if possible. If not, you will need to delete the device from Power365 and reinstall the agent. Use the Status Resets action to reset the registration status of the device, then set the Power365 Directory Sync Workflow to reconcile on next run and run it. This will delete the old device from the database. Finally, reinstall the Power365 Migration for Active Directory Agent on that device and run the Workflow again to read it in.
How do I remove Devices from Power365 Migration for Active Directory?
To delete registered Devices from Power365 Migration for Active Directory, first use the Status Resets action to clear their registration status, then run the related Power365 Directory Sync Workflow with the setting ‘Reconcile on next run’ enabled. Any unregistered device records in scope of the Workflow will be removed from the database during a reconcile.
Additional Info
Architecture
The first step towards success on a project using Power365 Migration for Active Directory is to understand the product architecture and how this architecture will operate in your environment.
Power365 Migration for Active Directory consists of the following components:
A directory synchronization engine
A REST based web service
A management interface
A lightweight agent for workstations and member servers
The directory synchronization engine, the web service, and the management interface will all access the same SQL database. In most scenarios, these components will be installed on the same system. In larger or more complex network environments, the components can be distributed across multiple systems.
The directory synchronization engine is provided by Binary Tree’s Power365 Directory Sync. Power365 Directory Sync is included as part of Power365 Migration for Active Directory.
User workstations, member servers and computers are collectively referred to as Devices in Power365 Migration for Active Directory. Computers communicate with the Power365 Migration for Active Directory web service using the Power365 Migration for Active Directory Agent. The Power365 Migration for Active Directory Agent is a lightweight application that installs as a service on Windows computers.
To ensure that no firewall exceptions are required, the web service does not “call” the Devices to be migrated. Instead, the Power365 Migration for Active Directory Agents contact the web service at defined polling intervals, using standard HTTPS or HTTP requests to collect jobs. Jobs include key tasks such as system discovery, updating the operating system, file system, and user profile permissions, and migrating the computer to the new domain.
Standard Configuration
In the Standard Configuration for Power365 Migration for Active Directory the Agent is deployed to each Device to be migrated. Those Agents communicate outbound to the Power365 Migration for Active Directory webserver in Azure over ports 80/443 every 4 hours, when a job is available, or when initially registering. They also communicate outbound to the Power365 Migration for Active Directory Agent job availability cache in Azure over UDP on port 3030 every 2 minutes.
Web Proxy Configuration
In the Web Proxy Configuration for Power365 Migration for Active Directory the Agent is deployed to each Device to be migrated and use of a web proxy is enabled. Those Agents communicate outbound through the defined proxy port to the Power365 Migration for Active Directory webserver in Azure over port 443 every 4 hours, when a job is available, or when initially registering. They also communicate outbound through the defined proxy port to the Power365 Migration for Active Directory Agent job availability cache in Azure on port 80 every 2 minutes.
Troubleshooting
Problem: Observed Access Denied error when trying to ReACL a Windows NAS Shared Drive.
Solution: To fix this:
- Add the user credential in the NAS Profile screen in the Active Directory Pro Console. This user should be installed on a workstation with Local Admin Rights
- After the Agent is installed on the workstation, change the Active Directory Pro Agent Service account from Local System to the user credential specified in step 1. This user should also be logged in on the workstation as well
- Turn off UAC on the workstation
- ReACL the Windows NAS Shared Drive
Problem: A workstation that has been successfully cutover no longer responds to any additional jobs, such as Cleanup.
Solution: If a workstation that has been successfully cutover now fails to respond to any additional jobs, such as Cleanup, check the Application event log. If you see a "The remote name could not be resolved" error, this most likely means that the SRV record for the Active Directory Pro Server can no longer be resolved due to a DNS lookup failure.
If you cannot "Ping" the Migrator Pro for Active Directory server from any other machines in the target domain, then you will need to remedy this on a more global scale, such as creating a conditional forwarder on the target machines' current DNS server pointing to the appropriate location.
If you are able to "Ping" the Migrator Pro for Active Directory server, then check the Network Profile that was used during the Cutover to verify that the DNS settings were correct in that profile.