CiscoWorks on 2 servers not synchronizing

[anke]

Hello,

I have a setup with two servers that don't seem to synch properly. We changed the names of all of our routers (#180), updated DNS etc. Then I deleted them in CS (Master>Common Services>Device and Credentials>Device Management>CS@master). And they got re-discovered ok. After a netconfig job I realised that RME still had them under their old name. I then deleted them in RME (Slave>RME>Devices>Device Management>RME Devices). It's been a nightmare ever since to try and get them back. At one point it let me manually import them, but now not the new devices. Our network is so big that there are constantly changes. But they are not reflected. My questions is "Why do I have x number of devices in CS@Master and y number of devices in CS@Slave? Is there a place/log I can verify communication between the servers and/or devices that get synchronised (or not)? What are the things I need to make sure are configured for synchronisation to work?

I didn't do the installation, but CiscoWorks is working generally ok. I restored the DBs already and that didn't change a thing.

Any help would be greatly appreciated. By the way, our software is CM 4.0, RME 4.0.

Thanks

[Joe Clarke]

The only things required for successful DCR synchronization are SSL connectivity between master and slave servers, SSL certificate trust between the master and all of the slaves, and for the short hostname of the master to be resolvable on the slaves (and vice versa).

However, if you really have RME 4.0, I highly suggest you upgrade. The current release of RME 4.0 which you can get as a free update is RME 4.0.6 which has a considerable amount of bugs fixed in it.

[akemp]

I'm curious, if you enter the dcrcli "lsmode" on the master and then the slave do you see something like this ? (I've got a 2 server cluster that should be very similar)

On the Master

dcrcli> lsmode

DCR ID: prolnm06-DCR-2572288

DCR GROUP ID: Group2572288

DCR Mode is Master. Registered Slaves are:

DCR Slave ID:prolnm05-DCR-5233821 URL:prolnm05:443

and on the Slave:dcrcli> lsmode

DCR ID: prolnm05-DCR-5233821

DCR GROUP ID: Group2572288

DCR Mode is Slave

Master URL:prolnm06 Port:443

It appears that your CS's aren't talking from your problem description,

[anke]

Yeah, I got something similar. Just different numbers. Group ID the same on both servers. slave has a master url, master has slave-id and url, which is all matching (the numbers). have an All-Caps URL, I'm sure that doesn't matter?

Does above output confirm that the servers are talking to each other?

[akemp]

They think they are talking to each other. The quickest way you can verify that its current is to add in a device on the master, get its ID (lsids ip=X.X.X.X, then check to see if that device shows up on the slave in a few minutes)

You haven't changed the host name, regenerated or imported the PKI certs, or changed the system identity/password ?

[anke]

I tried that, but I haven't got another ciscoworks server that I could use as a slave. Tried adding other devices, didn't work.

Yes, when I thought they didn't talk to each other I deleted the certificates on both machines (Server > Security > Peer Server Certificate Setup) and recreated them. Is there anything I need to watch out for?

[akemp · Accepted solution]

I'd redo the whole trust relationship from scratch. Remove the peer server certs from each server. Generate or import the PKI cert. Restart the daemons (required step after creating or importing the new cert). Enter in the system identity into both systems. Import new cert from other server on each box. Delete and recreate the Application Registrations under home page administration. And now the important part: go under Common Services, Devices and Credentials, Admin, Mode Settings, and change mode on the slave to ... slave.

Its a trickle update so it might take a while for them to sync. I usually install Ciscoview on all slave servers just to check for the invenory sync status. After about an hour they should be in sync for all apps.

[anke]

Even though i really don't see why the homepage application registration settings would have anything to do with it, it appears working I have more or less the same amount of devices in CS (master), CM (master) and RME (slave). I'm gonna have to do minor adjustments and will see if it gets updated properly. But thanks for the application registration tip. never would have thought of that. Like i said I didn't install it, so don't know that this has to be done.

Thanks

[akemp]

It might seem a bit weird, but the LMS 3.0 DCR is actually dynamic now instead of the leaden lump it was in LMS2.X. In 2.X is served the purpose of a look at me once list and every application grabbed what it needed , stuffed it into its own little propriatary DB and ran merrily away. Now just watch the DCR log files and see how

The PKI construction this release got a bit stricter. Previous releases just the name had to match in the application declaration on the homepage. Now the cert including the hash have to match.