OCS 2007 migration to OCS2007 R2, users moved to R2 can't see presence info for users on 2007

I have a small OCS 2007 setup and I just got a new OCS 2007 R2 server going.  I moved my account to the R2 server and I can sign in and see all my contacts, but they are all dimmed out and I can't message them.  The presence info is not there.  I assume this should work as most migrations will take some time to move all users over.  Is there something I'm missing?
jpletcher1Asked:
Who is Participating?
 
jpletcher1Connect With a Mentor Author Commented:
Figured it out..  I did not have this hotfix installed.  After putting this on it works.

Install the Hotfix that is described in KB 975858 for Windows Server 2008 R2.

975858  (http://support.microsoft.com/kb/975858/ ) An application or service that calls the InitializeSecurityContext function together with the ISC_REQ_EXTENDED_ERROR flag may encounter a TLS/SSL negotiation failure on a computer that is running Windows Server 2008 R2 or Windows 7 operating system
0
 
Jeff_SchertzCommented:
Assuming that the other users are still on the R1 server you should look at the event logs on both OCS servers.  There may be certificate-related problems preventing MTLS communications between both Frton-End servers.
0
 
jpletcher1Author Commented:
Yes, the OCS R2 Server complains about the certificate on the OCS R1 server, but they both have internal certificates that were given out by the same CA, and they both have the chain installed up to the root certificate too.  Below is what I see on the R2 server.  I have run the BPA and things check out fine there.  Not sure what the problem could be if it is certificates.

TLS outgoing connection failures.

Over the past 1 minutes Office Communications Server has experienced TLS outgoing connection failures 1 time(s). The error code of the last failure is 0x80004005 (Unspecified error) while trying to connect to the host "OCSR1_ServerName".
Cause: Wrong principal error could happen if the peer presents a certificate whose subject name does not match the peer name. Certificate root not trusted error could happen if the peer certificate was issued by remote CA that is not trusted by the local machine.
Resolution:
For untrusted root errors, ensure that the remote CA certificate chain is installed locally. If you have already installed the remote CA certificate chain, then try rebooting the computer.
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

 
jpletcher1Author Commented:
Is there a way i can turn up logging to see exactly what it sees wrong with the certificate?  I see there is an OCSlogger utility.  Which items would it help to monitor from there?
0
 
jpletcher1Author Commented:
When I analyze the sipstack logs I see this, but it doesn't tell me much about what specific it has issues with negotiating on..

TL_ERROR(TF_CONNECTION) [0]1100.0D64::09/02/2010-20:08:29.824.00000265 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(157))$$begin_record
LogType: connection
Severity: error
Text: Outbound TLS negotiation failed
Local-IP: OCSR2_IP_ADDRESS:58207
Peer-IP: OCSR1_IP_ADDRESS:5061
Peer-FQDN: OCSR1_SERVER_NAME.domainname.com
Connection-ID: 0x3500
Transport: TLS
Result-Code: 0x80004005 E_FAIL
$$end_record
0
 
Jeff_SchertzCommented:
That error indicates that the R2 server is most likely resolving the R1 server using a different FQDN then what is configured in the Subject Name field on the R1 server's certificate.  It appears you have a naming mismatch in the configuration.
0
 
jpletcher1Author Commented:
Yes, I have checked this several times and the fqdn of the R1 server is exactly what the R1 certificate subject name is.  I realize all the errors that are coming up seem to pertain to an issue with certificates and naming, but I can't find any mismatches.  I'd like to do detailed logging where I could see exactly what it finds wrong, but I'm not sure what to log.  I have OCSlogger running and the resource kit tools so I can analyze the logs, but I just can't find the information I need.
0
 
jpletcher1Author Commented:
Jeff or anyone - do you know which logging in OCSlogger would give me detailed information on the certificte erors?  When I do sipstack logging I can see that it apparently doesn't like the certificate, but it never says why or what specifically.

The certificate on the R1 and R2 server are from the same internal Microsoft CA server.  Both servers have the full chain installed.  Both certificates subject names match the fqdn exactly for the server.
0
 
jpletcher1Author Commented:
This is the error I see on the R1 server.

A significant number of connection failures have occurred with remote server Server_FQDN IP x.x.x.x. There have been 133 failures in the last 468 minutes. There have been a total of 133 failures.
The specific failure types and their counts are identified below.
Instance count - Failure Type
129 80072746
4 8007274D

This can be due to credential issues , DNS , firewalls or proxies. The specific failure types above should identify the problem.
0
 
shaunclarkeCommented:
Thank youu jpletcher1!

That solved it for me as well! Thanks heaps!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.