10-07-2009 08:34 AM
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)
Solved! Go to Solution.
10-07-2009 11:51 AM
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.
10-07-2009 08:37 AM
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
10-07-2009 08:38 AM
Make sure you do not have on-access anti-virus scanning running on NMSROOT. If you do, disable it, then restart Daemon Manager.
10-07-2009 08:40 AM
(I saw this suggestion in the other threads.)
No anti-virus installed on either server.
10-07-2009 08:55 AM
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.
10-07-2009 08:58 AM
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.
10-07-2009 11:32 AM
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?
10-07-2009 11:43 AM
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.
10-07-2009 11:51 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide