Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

How to replace 3 call managers in 3 different sites with only 1 centralized call manager

If a company is composed by three different site, in each site is installed a CUCM in order to manage an IP-Phone network, the sites are in different location in the same city and are connected eachone with eachothers.

Is it possible to replace the 3 call managers with only one centralized call manager?

If yes, which  can be points of attention and criticity?

Is it only needed to remer the numbering plan of the three sites and reconfigure the same numbers in the centralized call manager?

Everyone's tags (6)
1 ACCEPTED SOLUTION

Accepted Solutions

Re: How to replace 3 call managers in 3 different sites with onl

A while ago I had a project where I consolidated five CM clusters into a single cluster.  At a very high level these are the tasks performed to absorb each cluster:

source == cluster going bye bye

target == cluster that is taking over

1. Clean up stale records on source cluster.

- remove user IDs that are not being used any more

- remove phones that have not been registered in a long time ("long time" is subjective)

2. Build out core dial plan components in target cluster

- partitions

- css

- gw

- route groups

- route lists

- route patterns

- translations

(NOTE:  at the time I used axl/soap to build a good portion of this out, so it was painless.  With 7x you could use bulk import which will be very efficient)

3. Export phone records

- use bat to export phone records - ALL DETAILS

(In my case, I was switching versions as well and the ALL DETAILS record format was different.  Also, I was normalizing the dial plan to a 10-digit dial plan.  So, I had to write a script that would take the phone records in the old version and convert them to the new version for import.  I recommend that if you have different versions.  Create identical records in each cluster, export them, and compare them.  This will let you know what (if anything) is different.)

4. Export users

- The nature of this step depends on the version you are using and whether you are integrated with an LDAP system.  Also, the importance of this step depends on how your end users interact with the system.  Key considerations/drivers:  extensiion mobility, PAB, Fast Dials, device associations to users, and other apps that require logon (AC for example)

- I won't comment further on the variations at this time because I don't know what versions you are dealing with

5. Import phone records

6. Import users

7. Modify DHCP scopes to specify new option 150 to source cluster phones

8. Execute a reset from source cluster

Of course, there is more to it than what is listed above.  The degree of complexity depends on what you have deployed today.  You will likely need to relook at your dial plan design to accomodate the three clusters.  Even if in a small way.  Make sure you review all three clusters and update the consolidated design to incorporate the most complex aspects from each cluster.  Think of consolidation as an opportunity to clean up a bunch of stuff.  Also, make sure you build detailed implementation plans.  It is very easy to screw things up if you aren't on top of it.

Finally, if you can, have a method to track registrations and find phones that may be stuck in limbo.  Particularly 7935 and 7936 devices.  For some reason these phones get confused when doing changes like this.   At least they used to.

HTH.


Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

2 REPLIES

Re: How to replace 3 call managers in 3 different sites with onl

A while ago I had a project where I consolidated five CM clusters into a single cluster.  At a very high level these are the tasks performed to absorb each cluster:

source == cluster going bye bye

target == cluster that is taking over

1. Clean up stale records on source cluster.

- remove user IDs that are not being used any more

- remove phones that have not been registered in a long time ("long time" is subjective)

2. Build out core dial plan components in target cluster

- partitions

- css

- gw

- route groups

- route lists

- route patterns

- translations

(NOTE:  at the time I used axl/soap to build a good portion of this out, so it was painless.  With 7x you could use bulk import which will be very efficient)

3. Export phone records

- use bat to export phone records - ALL DETAILS

(In my case, I was switching versions as well and the ALL DETAILS record format was different.  Also, I was normalizing the dial plan to a 10-digit dial plan.  So, I had to write a script that would take the phone records in the old version and convert them to the new version for import.  I recommend that if you have different versions.  Create identical records in each cluster, export them, and compare them.  This will let you know what (if anything) is different.)

4. Export users

- The nature of this step depends on the version you are using and whether you are integrated with an LDAP system.  Also, the importance of this step depends on how your end users interact with the system.  Key considerations/drivers:  extensiion mobility, PAB, Fast Dials, device associations to users, and other apps that require logon (AC for example)

- I won't comment further on the variations at this time because I don't know what versions you are dealing with

5. Import phone records

6. Import users

7. Modify DHCP scopes to specify new option 150 to source cluster phones

8. Execute a reset from source cluster

Of course, there is more to it than what is listed above.  The degree of complexity depends on what you have deployed today.  You will likely need to relook at your dial plan design to accomodate the three clusters.  Even if in a small way.  Make sure you review all three clusters and update the consolidated design to incorporate the most complex aspects from each cluster.  Think of consolidation as an opportunity to clean up a bunch of stuff.  Also, make sure you build detailed implementation plans.  It is very easy to screw things up if you aren't on top of it.

Finally, if you can, have a method to track registrations and find phones that may be stuck in limbo.  Particularly 7935 and 7936 devices.  For some reason these phones get confused when doing changes like this.   At least they used to.

HTH.


Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Hall of Fame Super Gold

Re: How to replace 3 call managers in 3 different sites with onl

Wow, such a detailed and professional explaination only rated a "4" ?

I have rated "5" as that is what is fair.

646
Views
14
Helpful
2
Replies