If you are experiencing connection issues between servers in your CloudM Migrate multi-server deployment, this guide outlines a series of checks and troubleshooting steps you should follow.
1. Service and Installation Fundamentals
-
Is the CloudM Migrate Service Running?
- Verify that the CloudM Migrate Service is actively running on all affected Virtual Machines (VMs), including both the primary and secondaries.
-
Was the Primary Server Installed First?
- The primary CloudM Migrate server must be installed first. This ensures that the correct database information is established for subsequent installations of secondary servers.
-
Are System Requirements met?
- Check the CloudM Migrate System Requirements and upgrade any machines or VMs as required.
- Verify that the primary Virtual Machine is of a higher spec than the secondaries, as required by CloudM Migrate.
- Confirm that the spec for all VMs are high enough to handle the migration workload.
2. Diagnostic Logs and Events
-
Check CloudM Migrate Service Logs:
- Inspect the service logs located at:
"C:\ProgramData\Cloud Technology Solutions\CloudMigrator.Service.Trace.txt"
(and numbered log files). These logs contain useful information about the system's state. -
Action: Look specifically for any errors
[Error]
or warnings[Warn]
.
- Inspect the service logs located at:
-
Check the Windows Event Log via CloudM Migrate Service Manager:
- The CloudM Migrate Service Manager is installed alongside CloudM Migrate on all primary and secondary servers. It provides a filtered view of the Windows Event Viewer, showing only events related to the CloudM Migrate service.
- Action: Check for any errors on either the primary or the secondary servers within the Service Manager.
-
Check the Windows Event Log application
- The CloudM Migrate Service Manager only shows a filtered view of Windows events relating to the CloudM Migrate Service, it's may be required to also check Application and System logs here.
3. Consistency Checks
-
Ensure Exact Build Match:
- Verify that the primary VM and all secondary VMs are running the exact same build of CloudM Migrate, (including matching x86 versus 64-bit versions). Secondary servers will highlight an error in the CloudM Migrate Service Manager if their version does not match that of the primary.
-
Server Naming Convention:
- Make sure all of your servers have a name shorter than 16 characters. Communication between servers in a multi-server environment will fail with server names longer than 15 characters.
-
Identify Specific Secondary Issues:
- Determine if no secondaries are connecting, or if only one, or some particular secondaries, are experiencing issues. Identify any differences in how these specific servers were created or configured compared to working ones.
-
VM Cloning and Sysprep:
- GCP - Cloning a secondary VM
- If your Virtual Machines were cloned, did you run Sysprep on them first? If you have multiple secondaries and only one can connect, this can indicate that the secondaries share the same internal MSMQ ID, which is a common issue with improperly cloned VMs.
- Action: Check the articles for setting up VMs in GCP and Azure, which include instructions on how to perform Sysprep correctly.
4. Network and Communication
-
Verify Subnet Configuration:
- Confirm that all VMs (primary and secondaries) are located within the same subnet.
- Action: Refer to the detailed instructions on Multi-Server Installation for proper network configuration.
-
Check Inter-VM Visibility:
- Can the VMs see each other on the network?
- Action: Ensure DNS is correctly enabled and configured. If DNS is not present for some reason, verify that correct host file entries are in place on each VM.
-
Firewall Rules:
- Investigate if a firewall rule is blocking communications between servers. CloudM Migrate will normally create the necessary firewall rules during installation, but Group Policy might roll these back, or users could have made their own changes.
- Action: The Windows 'Public network' firewall profile may need to be disabled on the primary server or configured to allow necessary traffic.
-
Service Restart:
- Sometimes, simply restarting the CloudM Migrate and MSMQ (Microsoft Message Queuing) services can help resolve connection problems.
5. Service Component Checks
-
Dedicated Service Account:
- Running the CloudM Migrate Service Using a Dedicated Account
- Action: Have you tried to update the CloudM Migrate Service on the primary and secondary(s) to use a dedicated Windows account to run? This account may need to be a full system administrator to ensure it has all necessary permissions.