the procedure was done exactly as noted above on the pub only.

TAC instructed me on how to do this and that is why i followed the instructions given.

If there are alternative ways to do this please advise and version of CUCM is stated in my original post i think but just in case CMCM 6.1.1.2000.3

Thanks for your response.

I overlooked the version in subject matter, however the command that I mentioned is certainly available in release CUCM 6.x.

As I mentioned try this command if the dbreplication reset command fail to resolve the broken dbreplication.

Another excellent feature within CUCM 6.x is the Cisco Unified Reporting. It provides detailed reports including Database status, and highlights any inconsistencies within the various aspects assoiciated with replication, such host and sqlhosts files etc..

You can open or select this reporting facility from within the CUCM administration, open the drop down menu where you select the OS admin option, and there you will see 'Cisco Unified Reporting'.

When the Reporting page appears click on the 'System Reports', you will then see the numberous reports available, one of which is the 'Unified CM Database Status'.

Click on this report, and then click on generate report. This will take several minutes to complete. Once complete it will give a comprehensive report, and may highlight what could be possibly wrong.

On the right of the page is the option to download the report, so you can effectively save the report and forward to Cisco TAC.

HTH

Allan.

thanks much.

The TAC has asked for this on my current case.

with respect to the clusterreset commandline util is there anything that should preceed it or follow it or is that all you have to do is issue the command itself.

I have seen it there but since the TAC has not asked me to do it i've not used it.

also if used will this interrupt phone service?

thanks again.

paul.

The utils dbreplication clusterreset resets the database replication on an entire cluster.

Before you run this command, run the command utils dbreplication stop first on all subscribers servers, and then on the publisher server.

Also once the clusterreset has completed, initiate a 'reset all' from the publisher.

After the reset it is recommended to reboot each of the subscriber once the dbreplication status shows a status of 2 for each node.

Unfortunately I have experienced unpredicable results with dbreplication before, therefore I cannot guarantee that it will not be service affecting.

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.

Therefore any changes to the local database will be synchronisation once the dbreplication is established.

HTH

Allan.