CCM EM error 6

Unanswered Question
Jun 3rd, 2008

Hi there we have 2 (Publisher & Subscriber)CM 4.1.(3) sr4b with EM configured.

Both Pub & Sub are in different buildings. Distance is about 5 km.

The link between both buildings is 200 Mbps. Both Cm's are in different lan's with different IP's.

On normal conditions, EM service points to Publisher Ip address.

In case of Pub failure, or link failuer or disaster, users at pub lan have to move to subscriber builfing and be able to login using EM end same extension profile etc..

For that we have tested changing on subscriber EM services to sub's IP address and disconnecting publisher's lan plug (RJ45)

We get ERROR 6 login unsuccesful.

If we re-connect publisher RJ45 and EM still points to subscriber's ip address, login is succesful.

We have check with ethereal and all packets for IpPhone are coming from sub's in both cases.

Can anybody help?

Thx in advance

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Tim Smith Tue, 06/03/2008 - 07:14


In CallManager versions 3.x, 4.x, 5.x the loss of the publisher is CallManager's extension mobility's kryptonite!

The extension mobility service actually needs to read and update the SQL DB on the pub to work. Therefore - no pub, no extension mobility.

Take a look at CallManager 6.1, I havent tested yet, but extension mobility and a few other changes are supposed to be distributed. So extension mobility should not be dependant on 1 server.

If you remain on CCM 4.x you would need to look at a cold standby pub in the 2nd site. But this would still require manual intervention and DB restore, which would take time!



iraira Fri, 06/06/2008 - 00:32


now we would like to know your opinion about which is the best solution.

Subscriber is currently a a 2nd building which acts as a backup building in case of contingency, and publisher is at main buidling HQ. In case of contingency , people will move from HQ to backup office so customer would like to move publisher to backup building and subscriber to HQ main office. To do so, we need to now which are the services that are affected in the following situations:

1.Publisher Active & subscriber off

2. Subscriber active & publisher off

Thx a lot

Tim Smith Fri, 06/06/2008 - 00:56


Personally my thoughts are...

If you move the pub to the backup office.. what if you have a link problem between the sites? Then the HQ users are affected?

Shouldnt people be moving to the backup office, be a worse case scenario?

Doesnt make sense to me, to reduce the level of service and resiliency at the HQ, to ensure the backup is available?

If your client is relying on Extension Mobility as a kind of DR solution.. I would be upgrading the client to 6.x. It will be worth it. Extension mobility will function without the publisher. So if one site does fail, the transition to the other site will be fairly seamless.

On top of that.. you get rid of all the Windows pain.. and upgrades become much easier also. There are a lot of good reasons to go to the appliance model.

In general.. your publisher is the master database.. so without it, basically anything that makes a change to the DB will not work..

Main ones..

1. Extension mobility

2. Call forward all

3. Any configuration changes by Admins

Other than that what other services are affected will be down to what services you have and how you have configured the services on each server. Go to CCMService pages and check the service activation on each box.



rob.huffman Fri, 06/06/2008 - 05:13

Hi Inaki,

I agree with Tim here :) (+5 for both these good posts Tim)

If you upgrade to CCM 6.x the DR site could still function nicely without the Publisher. This sounds like what would really offer the "best case" in a "worst case" Disaster Recovery situation.

You will need to go to CCM 6.x to have redundancy for EM. Here is the background (there is no way to do this on any CCM version until 6.x)

The configuration database is stored on a publisher server, and a read-only copy is replicated to the subscriber members of the cluster. Changes made on the publisher are communicated to the subscriber databases, ensuring that the configuration is consistent across the members of the cluster, as well as facilitating spatial redundancy of the database.

The publisher server is the only server that has read and write access to the configuration database. When configuration changes are made, other members of the cluster have a read-only copy of the database.

From this CCM SRND;

This changes with the release of CCM 6.x;

In prior versions of Cisco Unified Communications Manager, subscriber servers in the cluster use the publisher database for READ/WRITE access, and only use the local database for READ access when the publisher database cannot be reached. With Cisco Unified Communications Manager Release 6.0, subscriber servers in the cluster READ the local database. DB WRITES happens in both the local database as well as the publisher database, depending on the type of data. DBMS (IDS) replication is used to synchronize the databases on the nodes of the cluster. When recovering from a failover conditions such as loss of WAN connectivity for extended period of time, the Cisco Unified Communications Manager databases need to be synchronized with any changes that may have been made during the outage. This process happens automatically when database connectivity gets restored. This process may take longer over low bandwidth and/or higher delay links.

Database modifications for CallProcessing

User Facing features can be made on subscribers. These include updates for:

Call Forward All (CFA)

Message Waiting Indication (MWI)

Privacy Enable/Disable

Do Not Disturb Enable/Disable (DND)

Extension Mobility Login (EM)

Monitor (for future use, currently no updates at the user level)

Hunt Group Logout

Device Mobility

CTI CAPF status for end users and application users

Credential hacking and authentication

Hope this helps!



This Discussion