Meshcentral: Q: Migrating to a new server

[edlins]

Hello! My organization has a lot (several hundred) agents connected to an existing server. A new beta server has been provisioned to take over. It has a new IP and hostname. Can you recommend a good method for transitioning the agents to the new server?

I assume the database would have to be exported from the existing server and imported into the new server. Then is it enough to simply edit the meshagent.msh files on all of the clients and only change the MeshServer hostname? It's not totally clear to me whether or how the other fields might need to be updated.

Thanks in advance, and apologies if this has already been covered and I missed it.

[MailYouLater]

OK, so this has been sort-of-covered a couple of times before, but the information is kind of spread out in pieces across other issues. Unless I'm forgetting something, it basically comes down to is this:

• If you want to properly migrate your server, including all the device groups, and historical data that the current server has, you'll need to copy over the meshcentral-data folder to the correct place for the new server to use it.
• If you're changing the hostname (or if you're using the IP address directly, and it's changing) you'll need to edit your config.json, and also the value of MeshServer in each agent's .msh file.
• If the new server will have a different MAC address, then MeshCentral will generate a new certificate for the agent to verify against, so you'll need to change the ServerID in each agent's .msh file.
  The easy way to get the new ServerID is to manually install the agent on a computer after setting up the new server, and getting it from the new .msh file that computer's agent is using.
• I would recommend setting up the new server before taking the old one down, so that you can connect remotely to each computer using the old server, make the necessary changes to the .msh file, and restart the Mesh Agent service to move them over to the new server.

@Ylianst / @krayon007 : Did I miss anything?

[PathfinderNetworks]

I've found it's just easier to set up the new server, configure it as you want, and install the new mesh agent on each device. Like MailYouLater said, if you leave the old one running you can use the 'old' server to connect to each device and install the new mesh agent that way. Me, I transfer the new Mesh agent to each device using the file transfer tool. Then I use the terminal to run that new meshagent on the device with the -fullinstall option. No need to uninstall the old mesh agent or anything. As soon as the new mesh agent is installed that device will transfer to your new Mesh server. That's how I migrated from my old MeshCentral1 server to my MeshCentral2 server. Now, all that said, this method does not retain any of the data from your old server and you'd have to manually re-create all the groups on the new server, etc. I did this with a little over 200 devices and it was pretty painless.

[edlins]

Thanks!! I'll leave this open for a few days to see if anyone else has anything to add before I close it. I'll need to check the business reqs to see if the history needs to be retained.

[edlins]

I just learned that a critical business requirement is to not make any changes on the agent machines at all. However, @MailYouLater stated:

If the new server will have a different MAC address, then MeshCentral will generate a new certificate for the agent to verify against, so you'll need to change the ServerID in each agent's .msh file.

It sounds like the server migration is not possible without making changes to the agent machines because the ServerID on the agent is tied to the server's MAC address. Furthermore, the servers are on AWS EC2 instances where we cannot modify the new server to use the old MAC.
So, the question now is, is it possible to migrate all of the agent machines to a new server without making any changes on the agent machines?

Even if we modify DNS to point the old FQDN to the new server, the agents will not auth because the ServerID no longer matches..?

[MailYouLater]

@Ylianst has stated before that MeshCentral will detect that the MAC address has changed, and will generate a new cert, which by extension changes the ServerID, so that's why I said that, but I copied the meshcentral-data folder from one server to another (both running in LAN mode on two separate LANs, my thought process being that if someone brought their laptop to the other facility, it would connect to the other MC server) but that was before I'd seen the info about it changing the ServerID so I (later) assumed that it wouldn't work as I'd originally planned. Well, I just checked and the devices connected to both servers have the same ServerID in their .msh files, so maybe it will work as I'd intended, and maybe you can migrate to your new server, IDK.

[ryanblenis]

This, as well as several other scenarios, does make a case for a potential enhancement to the Mesh Agent, that it would install in a folder underneath the "Mesh Agent" folder into a folder with a corresponding ID of the server (same for the installed services) that would allow multiple mesh agents to be installed per-PC connecting to different servers.

[edlins]

Simplest for us would be making a simple DNS change to point the old name at the new server. But I imagine this would be rife with security concerns around DNS attacks. It seems a lot of thought has been put into specifically making this kind of change impossible. I'll close the issue for now but continue to think on it. Thanks for your feedback, and LMK if anything else occurs to anyone.

[MailYouLater]

If I were you, I would copy the meshcentral-data folder to the new server, edit the config.json to use the new server's FQDN, download the meshagent from the new server, connect a computer to it, and see what ServerID is in its .msh file. If it's the same, then you can change the FQDN back in the config.json, and change your DNS server to point the old FQDN to the new server, and all the agents will magically migrate over when they see the DNS change. If it's different, then see if the 'do not make any changes on the agent machines at all' stance can be loosened to a 'do not make any changes to the agent machines, except in the C:\Program Files\Mesh Agent\meshagent.msh file' stance, as this would allow you to migrate devices and their data to the new server by simply editing the meshagent.msh file on each device and restarting the Mesh Agent service.

[afabozzi]

I just did this and it was much easier than I thought it would be. I also did not have to mess with the clients which is nice.

Task: Move MeshCentral physical server with windows to virtual server with Debian

I spoofed the mac address in the virtual machine settings and disconnected the physical server (removing from production so no longer need to connect the LAN)
I then set my IP address the same as what my physical machine IP was (you can probably change this but be sure to update your firewall port forward rules)

Went here https://www.turnkeylinux.org/nodejs and downloaded the ISO

After install I then followed the instructions on the MeshCentral site for installation:
mkdir meshcentral
cd meshcentral
npm install meshcentral

after that I coped the following folders over from the old physical server:
meshcentral-data
meshcentral-files

I did not need nginx and it is using 443 so I disabled it like so (you can change the listening port instead if you need it):
systemctl disable nginx

I then edited the file /etc/rc.local and added the following command to start on boot:
node /root/meshcentral/node_modules/meshcentral/meshcentral --cert CERTNAME

reboot then try your MeshCentral address. after 1-2 minutes all of my agents connected and all seems to be working. 2 factor still works as well.

Hope this helps and if there are any other tips that are recommended let me know. thanks.

[edlins]

Thanks for the comments! I am still tracking this issue so please continue to add anything that occurs to you. As soon as I can I'll try some of these out and LYK. Seems like if there is a good solution or two it would be a great addition to the docs or a wiki.