08-17-2010 01:15 AM - edited 03-16-2019 12:17 AM
Hello,
I'm testing to switch version back to a lower version. I only have one ucm server. The problem is that the configuration that i made on the new version are not seen in the old version. For example i configured a phone with lines. When ik switch back to the older version the phone is not seen in the configuration of the ucm. I don't understand why. BTW when i switch back to the newer version the phone is seen agian with the lines.
Can anybody explain this to me and how to solve this?
Greetz,
Tinus.
Solved! Go to Solution.
08-17-2010 01:20 AM
Hi
That is working as designed.
Basically when you upgrade, the system installs the new OS/APps to the inactive partition, and then migrates your data accross. When you choose to reboot to the new version, only user-facing configurables (such as current call forward settings etc) are migrated accross.
When you switch back, you also go back to the original version of the DB; the new version's database is not migrated back.
There are probably lots of reasons for this - If new config changes are pushed back to the old DB, then rolling back a failed upgrade would not be 'clean' and would require further manual regression work. Also newer config elements may not be supported by the old version (e.g. new phone types or features), so lots of extra work for Cisco to map the data back and potential loss of config...
The idea is to quickly get you back to where you where before the upgrade as a quick rollback, not to allow you to randomly switch versions at leisure weeks later if something doesn't seem right...
Regards
Aaron
Please rate helpful posts...
08-17-2010 01:20 AM
Hi
That is working as designed.
Basically when you upgrade, the system installs the new OS/APps to the inactive partition, and then migrates your data accross. When you choose to reboot to the new version, only user-facing configurables (such as current call forward settings etc) are migrated accross.
When you switch back, you also go back to the original version of the DB; the new version's database is not migrated back.
There are probably lots of reasons for this - If new config changes are pushed back to the old DB, then rolling back a failed upgrade would not be 'clean' and would require further manual regression work. Also newer config elements may not be supported by the old version (e.g. new phone types or features), so lots of extra work for Cisco to map the data back and potential loss of config...
The idea is to quickly get you back to where you where before the upgrade as a quick rollback, not to allow you to randomly switch versions at leisure weeks later if something doesn't seem right...
Regards
Aaron
Please rate helpful posts...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: