Hi All, I have two CUCM 6.1.3 ( I Pub & 1 Sub). All phones registers with sub and all phones use pub for tftp. I am trying to force some phones to register with pub but have no success even new CM group created has pub as first choice & sub as second choice. For your information during Failover in the past phones used to register with publisher and currently there are some ATA devices registered with pub for some reason. Any Ideas ???
You are always welcome my friend
The fact that these phones do not see CUCM1- Pub as "standby" is really the key
here it seems. I would take a WAG here that something in the network is preventing
these phones from reaching the publisher. If you are able I would try to "sniff" the
registration process on one of the affected phones.
Hope all is well my friend!
Just a note here, did you change the reference to the CCM Group in the Device Pool that phones in question are using? After changing the reference you will reset all the phones to push them over to the Pub
You should keep in mind that in the SRND for CUCM the recommendation is that IP Phones are not registered on the Publisher. The Publisher should be kept for dB processing etc. It is a "best practice" to have at least 3 servers in your cluster (1 Pub and 2 Subs). When you define your Calmanager Groups you might setup Group 1 as;
And Group 2 as;
In Group 1 the Pimary Callmanager is Sub-1 and in Group 2 the Primary Callmanager is the Pub. This is in reference to the phones registered with each Callmanager Group (with the highest one listed being the Primary or "First choice")
**This is not related to the Publisher (Primary Node) and its functionality in any way The wording can be a tad confusing at times.
This relationship is built via the Callmanager Group and Device Pool that the phones belong to.
You can specify where a phone registers by assigning it to a specific Device Pool this in turn will look at a Callmanager Group that lists a Primary, Secondary and Tertiary Callmanager server.
Here is some related info;
Cisco Unified CallManager groups and device pools represent logical groupings of devices that you can arrange in any way that you want. For ease of administration, make sure that all the devices in a group or pool share a common and easily identified characteristic, such as their physical location on the network.
You can also use Cisco Unified CallManager groups to establish redundancy (backup call processors) for the primary Cisco Unified CallManager in the group. A Cisco Unified CallManager group comprises an ordered list of up to three Cisco Unified CallManager servers. During normal operation, the first (primary) Cisco Unified CallManager in the group controls all device pools and devices that are assigned to that group. If the primary Cisco Unified CallManager in a group fails, control of the device pools and devices that are registered with the primary Cisco Unified CallManager transfers to the next Cisco Unified CallManager in the group list.
Cisco Unified CallManager Groups
A Cisco Unified CallManager group comprises a prioritized list of up to three Cisco Unified CallManagers. The first Cisco Unified CallManager in the list serves as the primary Cisco Unified CallManager for that group, and the other members of the group serve as secondary (backup) Cisco Unified CallManagers.
Cisco Unified CallManager groups associate with devices through device pools. Each device belongs to a device pool, and each device pool specifies the Cisco Unified CallManager group for all of its devices.
Cisco Unified CallManager Groups:
Call processing load balancing You can configure device pools and Cisco Unified CallManager groups to distribute the control of devices across multiple Cisco Unified CallManagers. These should be Subscriber servers
Device pools provide a convenient way to define a set of common characteristics that can be assigned to devices.
Hope this helps!