cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
751
Views
10
Helpful
8
Replies

DCR default credentials error

helexis
Level 1
Level 1

Internal error in communication channel.

Already have CSCsu84143 installed.

I have a multiserver environment with 2 servers (DCR master = CM & IPM; DCR slave = RME & DFM)

1 Accepted Solution

Accepted Solutions

I always recommend using short hostnames for certs and multi-server trust. However, if you must use FQDN, then the cert must use the FQDN, and the slave needs to be registered to the server using FQDN.

In the case of my local servers, the IP had been changed while keeping the servers' hostnames the same. Only problem was, DNS was pointing the current hostname to the old IP addresses. The fix was to change the servers' hostnames to match the new DNS entries for the corresponding IP addresses. I then regenerated the certs for the new short hostnames, and re-established the peer relationship using the short hostnames. Everything has worked fine since.

View solution in original post

8 Replies 8

helexis
Level 1
Level 1

Forgot to include my versions:

LMS 3.1

CS 3.2

CM 5.1.3

CV 6.1.8

CWA 1.1.0

IPM 4.1.0

IU 1.8.0

LMS Portal 1.1.0

RME 4.2.0

DFM 3.1.3

Joe Clarke
Cisco Employee
Cisco Employee

Make sure you do not have on-access anti-virus scanning running on NMSROOT. If you do, disable it, then restart Daemon Manager.

(I saw this suggestion in the other threads.)

No anti-virus installed on either server.

Unfortunately, the logs don't provide all the details needed to see why the method lookup is failing. Typically this is triggered by AV scanning, but in this case, I cannot say why it's happening. Restarting Daemon Manager on the DCR master should workaround this, but without knowing the root cause, it could return. If you open a TAC service request, it should be possible to get to the bottom of this.

It did return. I rebooted both the master and the slave and it doesn't help.

Another symtpom is that I cannot manually add a device to the DCR. It lets me go through all the motions but when finished the newly entered device is not inthe all devices list.

I saw this exact problem on a pair of local servers. The problem there was hostname weirdness. Were the hostnames of these servers ever changed?

Ok...so I think you may be on to something here...

The hostname hasn't been changed...

However, I am still having issues with shortname vs. FQDN and certificates.

This is more relevant in a multiserver environment.

The certificates has changed from FQDN to shortname only...

Please advise best practice with FQDN and certificates...especially when device center doesn't use FQDN for its links.

I always recommend using short hostnames for certs and multi-server trust. However, if you must use FQDN, then the cert must use the FQDN, and the slave needs to be registered to the server using FQDN.

In the case of my local servers, the IP had been changed while keeping the servers' hostnames the same. Only problem was, DNS was pointing the current hostname to the old IP addresses. The fix was to change the servers' hostnames to match the new DNS entries for the corresponding IP addresses. I then regenerated the certs for the new short hostnames, and re-established the peer relationship using the short hostnames. Everything has worked fine since.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: