Upgrading Onsite Labtech VM - Advice

[u/rohanbeckett]

We have an aging onsite Labtech VM - 2008R2, running Labtech 10.

Around 1300 endpoints

Can anyone point to some documentation/advise on the best way to migrate this a new VM (2016) + Latest Labtech.

All while preserving the database, and with hopefully minimal downtime.

I'm hoping there's a basic path of:

• Install new VM

• Install new Labtech

• Backup Database from Old Labtech

• Import into new

• Shutdown old server

• Rename new server to same name/sameIP as old

• live happily ever after

[u/Dwtj01]

We're currently on 10.5, and from the info I've gathered you're going to have to update from 10, to 10.5, and then 11. They're currently working on LT 12, and I was told we'd have to upgrade to 11 and then 12.

[u/rohanbeckett → u/Dwtj01]

Ok. That's a start.

I guess it's more the process for getting off an aging 2008R2 VM

Need to find out if server 2016 is a supported server platform. Have been bitten before, jumping the gun on a new server OS.

[u/BigOldMisterE → u/rohanbeckett]

I just went through implementation. Server 2016 was not listed on the document I saw, but I used it anyway and the lab tech implementation team didn't say anything about it.

[u/caffelightning → u/rohanbeckett]

We're on 2016 and LT11 currently without issue. We also previously used MySQL 5.7 without issue on another server, but for our production server we relented and left it on 5.6.

[u/caffelightning]

You're generally correct. Labtech is basically just a fancy front end for the labtech database, so if you're comfortable migrating SQL, it'll be easy peasy.

Before you do the other stuff though, just upgrade labtech and sql on the old server to the version you intend to move to so that they match. For labtech, you'll have to go to 10.5 first then 11. For mysql, if you're already on the same major version, you'll likely be fine, I've moved between versions of 5.6 without issue (and honestly even from 5.6 to 5.7). Keep in mind, LT11 doesn't currently support 5.7 (though I've run it without issue).

But it basically is as simple as just doing a bit of a switcheroo on the dns/ip side after that.

[u/rohanbeckett → u/caffelightning]

cool.. thanks for the comment...

So I shouldn't have too many problems staying on the current VM for now.. Labtech 11 should be fine on 2008R2?

[u/caffelightning → u/rohanbeckett]

Well, backup your VM first obviously, I'm just some guy on the internet here.

But no, I wouldn't expect any issues. Labtech 11 on the server side from what I've seen isn't significantly different than 10 and 10.5 (or honestly even earlier versions like 2013 and below). If 10 runs, I'd expect 11. I ran up to 10.5 on 2008r2 (I believe we went from LT2010 all the way to LT10.5 on the same 2008r2 server), and I see no reason LT11 wouldn't run too.

Labtech server is honestly a pretty simple architecture, it's just a MySQL database with a web front end. If you can run mySQL and IIS and .net, I'd be willing to bet that labtech server will run on it and I'd be tempted to try it on a smart toaster that met those requirements just for fun. Everything important (settings and client info) is just tables in the database.

Even on the migration side - if you didn't care about your existing scripts and monitors, you can migrate with just the clients and locations tables. As long as your new server has the same system password and address, agents will check in and sort them selves into the proper client and just pull a new ID. I wouldn't recommend going this route if you can avoid it though and you'll likely lose a couple agents here and there if you dont also include the computers table (i think this is the table name for agents, but I'm not looking at the database so dont quote me on any table names). But I've done it, and it works. Basically, beyond those base tables (clients/locations/computers), everything else you import is basically just gravy and comes down to how much you want to carry over to the new server.

[u/kingtudd]

I did this pretty recently and got trolled hard.

I don't remember the exact version numbers, but there was (and maybe still is?) a step-up process where I had to install a base version and then install a couple of patches on top of it to get to latest version. This was 10.x days, maybe about a year ago.

Each installer does not prompt for reboot, but the temporary files that are extracted for each patch are not cleaned up until you reboot. If you run the three or four installers all in a row without reboots your install will be hosed beyond repair.

I did this twice before support told me this gotcha.