Does anybody have a guide or document that explains the steps and risks involved when upgrading MSP3 to a newer version? Is there more than one way to upgrade MSP? My customer is reluctant to update their live MSP server with a new version until all risks are explained and want to understand the different strategies with their respective risks. They are on 3.2.1 and have several distributed relay servers. They will move to 3.3.1 for now and then at some time in the future will move to 3.4 The obvious choice is to simply upgrade the existing server and tick the keep existing database option. Will this preserve all of the device history (device list in status tab on web console)? Do they potentially lose anything doing it this way? They dont do any data collection, Is there another approach to upgrading their MSP? Could they create a second server already built to 3.3.1? and then switch it over? Do they lose the SQL database if they do this? I assume that a new database needs to be created that is suitable for 3.3.1 and they cant point this new server to the original database. They have control edition but havent used it for data collection. If a new server is installed and if a new database is created what do they actually lose? All settings? packages? etc. so if I backed the packages up from the \archive folder and did the xml export of all objects and imported them back in does this restore everything? I know that the device list will be wiped but this should build up again once the devices start checking back in. It would be good to hear your experiences and the process that you followed, and any gotchas, problems, etc.
MSP Upgrades// Expert user has replied. |
1 Replies
Sean; There are two primary methods that can be used to upgrade: Upgrade with database migration and Upgrade and transfer objects via Export/Import. The mechanics of using these two methods and a lot of information about their relative merits are covered in quite a lot of depth in the document "Administering MSP 3.3.1". This information has been expanded every release and while it may have some specifics related to new types of objects, the basic process and mechanics apply to any release. The most functional approach is to Upgrade with database migration and that is the ONLY way to preserve ALL objects and history. If you backup the DB first, it should also be low risk since you could always go back if necessary. It should rarely be justified to use the other approach. One possible reason NOT to migrate the DB might be when the DB was suspect or known to be corrupted. Another reason might be if an enterprise was being subdivided (for example if a company was splitting into two independent entities and needed to separate objects and devices into two separate DBs for use by two separate MSP Servers). Allan