Multi Server Connection Troubleshooting

If you are experiencing connection issues between servers in a multi-server migration environment, you should check the following:

  • Is the CloudM Migrate Service running on the affected Virtual Machine?
  • Was the CloudM Migrate primary server installed first?
    • The primary server should be installed first so that you have the correct database information to install the secondaries.
  • Is the primary Virtual Machine of a higher spec than the secondaries, as is required?  Is that spec high enough?  If there are strange random SQL errors, this could be a CPU/memory resource issue.
  • Check the service logs at: "C:\ProgramData\Cloud Technology Solutions \CloudMigrator.Service.Trace.txt" (and numbered logs)
  • Check the event log (via CloudM Migrate Service Manager).  Are any errors seen on either the primary or the secondaries?
    • The CloudM Migrate Service Manager is installed alongside CloudMigrator on all primary and secondaries.  It provides a filtered view of the Windows Event viewer for just the CloudMigrator service.
  • Are the primary Virtual Machine and all the secondary Virtual Machines running the exact same build of CloudM Migrate (including x86 vs 64 bit)?  Secondaries will exit with an error if they are not the same version as the primary.
  • 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.

  • Are no secondaries connecting or just one, or some in particular?  What is the difference, were some created in a different way to others?

  • If the Virtual Machines were cloned, did you sysprep them first?  If you have multiple secondaries and only one can connect, this can indicate that the secondaries share the same internal MSMQ ID.
  • Are the VMs all within the same subnet?

  • Restarting the CM and MSMQ services sometimes helps connection problems.
  • Is a firewall rule blocking communications? CloudM Migrate will normally create the rules it needs at install time, but group policy might roll this back, or users could make their own changes. Windows 'Public network' firewall may need to be disabled on the primary server.
  • Is the MSDTC (Distributed Transaction Coordinator) service running? This is required for NServiceBus, which handles all of the transactions for messaging into MSMQ.
  • Have you tried to update the CloudM Migrate Service on the primary and secondary(s) to use a dedicated account to run? This may need to be a full system admin.
Was this article helpful?
0 out of 0 found this helpful