Does anyone know if it is possible to migrate/import a database from LANDesk 9.6 SP2 to 2017.3? I've got my new core up and running on its own database, but it has taken me so long to do that, there are a myriad of things out of sync. There are only two choices that I can see: either I go through by hand and make all the changes from one core to the other, or I can have the DBA restore a snapshot of the current database and reinstall LANDesk which will do the upgrade for me. I am really hoping I can avoid the pain of either option.
You can run an upgrade (side-by-side) essentially pointing your intended 2017.3 Core at the 9.6 database. This will take some time (as we'll need to go through upgrading 9.6 -> 2016 and then 2016 -> 2017).
I would advise against using a separate Core to up-lift your 9.6 Core, as there's a whole bunch of encryption stuff around sensitive items (usernames/passwords etc) that are essentially "Locked in" on a particular Core.
Since you didn't specify any amount of time here, not sure how long this all took. Are we talking about the version of the DB you upgraded being months out of synch? In which case (as well) "does it really matter" - since you can just update the inventory & vulscan data as clients update & send new sync data in...?
What was taking you so long / causing you pain in the upgrade of your (vanilla?) 2017 Core ?
I am behind due to the time it takes to go from concept to production in my environment, as well as having a problem with the test agents reporting in that took some time to solve. It sounds like the lesser of two evils is just updating the new core by hand with all the necessary items. Thanks.
In principle - yes.
It depends on what your "list of necessary items" entails -- but usually, yeah,, 99% of that stuff is "just" getting clients to poke the Core with new inventory / vulscan data .
Let us know if you get stuck.
For me, the necessary items are synchronizing all of the packages and custom definitions, as well as the patches, but I'll tackle it like eating an elephant and just match things one at a time.
Interesting mental picture.
If you're not scared of SQL (and/or actually HAVE SQL access to the DB), I can probably give you a few pointers to make your life easier.
Essentially you'd make sure the 2 SQL instances can talk to each other (Linked Server) and then do a fairly simple query of the following pseudo-code:
Show me ALL CUSTOM DEFINITIONS (or whatnot) that exist in Core-A but not Core-B
... tends to cut down on the amount of BS you may have to endure.
You can do similar things for packages -- just to generate a simple burn-down list as a relatively cheap win.
I am not scared of SQL, but this is not something I can accomplish. Since my database grew over the 10GB mark that the free edition of SQL can handle, the database was moved off my local system to a SQL server managed by the DBA team, making it inaccessible to me.
Ah - that bites.
Well - the option's there if you end up being able to coerce them (I tend to find bribing most techs is quite easy with coffee / doughtnuts / cake sort of things. Most IT people "just want to get fed" in my personal experience) .
What about going from 9.5 to 2017.3?
Thanks in advance. I have a lab env but just not here
If you're going from 9.5, then start clean.
Software Distribution alone has gone through a complete paradigm shift with 9.6, and you'll end up with a VERY messy Core if you go through all such major updates.
If you don't update more than once every 5-10 years, you generally should expect for things to change *QUITE* a lot.
You'll want a clean Core anyway, as 9.5 only supported Win 2008 at best, and you will probably want to look at Windows Server 2016.
I think I see a route through