Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


Migrating from SMGR 6.x to 8.x

Migrating from SMGR 6.x to 8.x

Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

The best way is to migrate up and then change the IP. Data migration tool will fail if IP addresses do not match.

RE: Migrating from SMGR 6.x to 8.x

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.

RE: Migrating from SMGR 6.x to 8.x

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close