All,
We are starting to have hardware problems with our core server. Nothing serious but we have a new server in the box and it's time to migrate.
Is there a "best practices" document out there? I did a variety of searches and came up empty.
- we could install the new server and then set it up as a second core- synchronize and then change it to the primary core- if this is a good idea and if our license supports two core servers...
- we could move the drives over- we have the OS on one drive and LANDesk on a second drive... we could move the LANDesk drive over
- Ghost or ?? Robocopy??
Please advise... thanks!
-B
Here a document that can help you.
http://community.landesk.com/support/docs/DOC-1081
I would recommend bringing up a core with the same name. Export your queries, SLM data etc over to the new box. Before doing this turn on store scans and turn off delta scanning so you have full scans you can just copy over to the new core. Make sure the new core has a totally different certificate name and back up your certs on your current box.
LANDesk installs components to your system drive so moving over only your Data drive would cause issues. By default IIS is installed on the system drive so that is most likely where you have it and where the LANDesk Web Components are isntalled. The LANDesk certificates also get installed to the system drive.
The main thing you need to make sure you do is backup the database, SQL or Oracle, and copy the certificates from the old Core Server. Copying the certificates from teh old Core Server to the new Core Server will allow you to communicate with your clients without having to reinstall the agents.
You would also want to make sure that you backup any custom scripts that you may have written and your ldvpe1.img file that you may be using for OSD.
As a general rule, I usually recommend simply copying the C:\Program Files\LANDesk folder and aslo the Drive:\Program Files\LANDesk folder (if LANDesk is installed on a different drive than C:) to another server. This will make sure that you should have everything you need and that will allow you to 'go back' to the old install if you need to copy any files off of it.
--Jake
Every now and then it's a good idea to start with a clean database. In our most recent hardware upgrade, we setup the new server and the created a custom vulnerability on the old server to install the updated client that points to the new server. We happened to be upgrading from LANDesk 8.6.1 to 8.7 at the time so that also insured we wouldn't have any old clients reporting to the new server.
One problem with a new clean DB is there is not a clean way to migrate your task/policies over to the new DB (ours is in the 4 digits). I wish LANDesk would create a copy wizard that could be run in either GUI or command line. It would have all aspects of the core in a "pickable" (is that a word) - tasks, policies, Distro Packages, settings, etc.... and you select the target and source. I also wish that all settings would be held in the DB - not scattered all over the place. Again just some thoughts.
Agreed. And patch management settings should be included in that. Both Custom Vulnerability defs and which patches are set for compliance and/or autofix. That was one of our biggest manual headaches with the clean DB migration plan.
All,
Thanks very much for the input... it looks a mess so maybe we'll do the second core server, migrate everything and then turn off the old...
I haven't looked at the document yet but I sure appreciate everyone's time... and now that we know how messy this is we'll look to not doing this again for as many years as possible.
Or maybe we'll turn it into a virtual server? Hmmmm....
-B
If you've got VMWare, it's a good way to go. You take a performance hit, but you also get snapshot backup and recovery.
Here's what we've decided to do...
1. New server out of the box and on the rack
2. Install second license of LDMS on new server
3. Create a new agent (one with LDAV and one without LDAV)
4. Create login script that updates client to new client on new server
What do you think? In theory, clients should drop off of the old server and appear on the new server automatically- also we'll have a clean database and all new data from the clients as they check in!
If ya'll are interested, I'll let you know how it goes.
-B
You can do that or even make a self contained exe of your new agent and then deploy it out from your old core.
Well, our network admin didn't want to make it a virtual server so we...
- setup a new server
- used the second license
- used full version of SQL Server (this time around)
- upgraded to SP4
- created a new SP4 / LDAV client
We're now pushing the new client out to PC's based on AD groups (OU's) and it seems to be working well. As each machine restarts and a user logs in, it gets the new client... and pops up on the new core server. Cleaning the old systems off of the old core is a manual process but I don't any other way...
-B
|
|||||