Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Migrating from SMGR 6.x to 8.x

Status
Not open for further replies.
Nov 22, 2013
596
0
16
US
Migrating from System Manager 6.x to 8.x

I am in the process of upgrading a SMGR from 6 to 8, but the new system will have NEW IP addresses.
I am not sure about the best way to migrate from the old system to the new.

I fairly certain that you need to have the same IP/FQDN and shorthname all the same when migrating as I have read this in documentation. I am thinking of doing the following but wondering if anyone has had this situation before.

- do a backup of current SMGR 6.3 system.
- Create a lab network with the same IP info as current 6.3 system
- Deploy SMGR 8 with same IP and hostname of 6.3 system into the new lab SMGR 8.
- Change IP info accordingly for new IP for SMGR 8.
- Backup data, then restore to customer production environment


I think this will work but not sure of all the gotchas in changing SMGR IP info.

 
I would backup 6.3, then restore to a new production 8.x with the old IP. Then change the IP in the virtual machine using the avaya changeIPFQDN script built in to SMGR.
Keep in mind if you have Session Managers or anything that sync's with SMGR you may need to re-initialize your trust etc with the SMGR after or you won't be able to control it.

 
Thanks for that. I knew there was a IP change command but forgot about it.
I am also going to be upgrading 2 session managers from 6 to 8 as well with different IP's.
For that I plan to upgrade the standby 6.x first then power it off and turn on the new 8 SM, enroll it patch it and let it sync to SMGR after SMGR is up and functional with the database. Then change all the devices to point to the new Session manager 8 one at a time.



 
couple of things: There's a data migration utility for Session Manager too. It moves user data that's not SMGR config specific - contacts, call logs, etc.

I'd also try to make sure that your lab network is a good mirror of production to avoid complications. Stuff like "can't ping a default gateway" or "no NTP/DNS" can make that isolated setup a pain to troubleshoot.
 
I am going to use the data migraiton utility for SMGR, but for SM's I have found it easier to let them replicate to the SMGR once SMGR has all the data base restored. My only issue I think is going to be TLS certs are going to need to be replaced since some of the SMs use TLS. Looking into that now.



I can mirror my lab easily with vlans, NTP, DNS and gateways. I use PfSense and can easily create all of it on the fly for my esxi host. Works very well.



 
I've never had a problem doing just the SMGR db migration and not the SMs, just thought it worth mentioning that it might be worth doing.

I believe the PPM architecture stores a bunch of data in SMs Cassandra database and while some of the end user interactions do feed back up to SMGR - like adding a contact - I don't believe everything does - like choosing ringer type/volume.

SM will always get a new identity cert when you spin up a new one - that's not changing. If you were using demo certs on 6.3, you'd need to initTM -d to make SM 8 use the demo ones. And if you added any other trusted CA certs - like the CA cert to do TLS to a Cisco Call Manager, you'd probably need to 'import' those as trusted CAs again.
 
The best way is to migrate up and then change the IP. Data migration tool will fail if IP addresses do not match.
 
Thanks for the info all.

After reading various things, and taking to a few others whom have done this. I have found what I think is the best way to do this going forward.

- upgrade R8 to latest patch.
- export NRP and user data from SMGR 6.x
- Modify the user export and import into R8 as well as import the NRP into R8.
- When I bring my Session managers R8 online, they should sync to SMGR r8 as part of the initial deployment script and enroll and grab the certs if needed.
- edit each end point accordingly so they see the new Session managers and register.

Since I only have a few SIP end points and a few session managers / BSMs I think this will work best for this situation. If i had lots of SIP endpoint I would do the data migration suggestions.



 
If you don't do data migration you will need to redeploy anything TLS again from scratch as the certificates will not ride over. You will also need to reinitialize trust to your ASMs. This means once SMGR is upgraded the ASMs will need attention separately and will not be manageable until you perform the service affecting action of re-enrolling them.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top