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

Answered Question
Jun 23rd, 2010

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?

I have this problem too.
0 votes
Correct Answer by William Bell about 6 years 5 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
Correct Answer
William Bell Wed, 06/23/2010 - 05:49

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.

Paolo Bevilacqua Wed, 06/23/2010 - 10:55

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

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

Actions

This Discussion

Related Content