none
Presence Unknown between OCS 2007R2 and Lync RTM

    Soru

  • In a recently deployed Lync pilot, users on OCS 2007 R2 Std pool see users in Lync Std pool as "Presence Unknown".  The same goes for the reverse where Lync users see OCS users as "Presence Unknown".

    Lync users see other Lync users presence, and OCS users see other OCS users presence, but they cann't chat between the two pools. 

    OCS 2007 R2 is deployed on 2008 R2.  All updates have been installed and all 2008 R2 pre-req's have been installed and configured.  Certificates for both environments were generated from the same internal Enterprise CA, using the default Web Server template.  The Enterprise CA root certificate is installed properly on both servers.  It could be a certificate issue, but I'm not 100% sure how to verify.

    Any pointers would be appreciated. 

     

     

     

    05 Şubat 2011 Cumartesi 18:03

Yanıtlar

  • Upon initial installation, have you had another HDD (i.e. E:\) attached (hardware of virtual) for short period of time. I believe the installation bits uses some sort of smart algorithm to place the DB files on different physical locations where possible (not 100% sure, thou).

    First and foremost, if you have folder named RtcReplicaRoot on your C:\ as of now?

     

    Drago


    http://ocsdude.blogspot.com
    • Yanıt Olarak İşaretleyen netsec545 07 Şubat 2011 Pazartesi 22:20
    07 Şubat 2011 Pazartesi 19:17

Tüm Yanıtlar

  • Running a SIPStack trace from the OCS 2007 R2 server returns this error:

    TL_ERROR(TF_COMPONENT) [0]0A30.0A04::02/06/2011-16:45:34.861.00011405 (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(147))( 00000000014FFE70 ) Receive failed
    TL_ERROR(TF_NETWORK) [0]0A30.0A04::02/06/2011-16:45:34.861.00011406 (SIPStack,CTCPSocket::OnSocketError:TCPSocket.cpp(621))( 00000000014EA740 ) IoRecv operation failed, winsockErr=10054(WSAECONNRESET), HRESULT=10054(WSAECONNRESET)
    TL_ERROR(TF_NETWORK) [0]0A30.0A04::02/06/2011-16:45:34.861.00011407 (SIPStack,CTCPSocket::ReportNetworkFailure:TCPSocket.cpp(2013))( 00000000014EA740 ) Enter - IoRecv operation failed, winsockErr=10054(WSAECONNRESET), HRESULT=10054(WSAECONNRESET)
    TL_ERROR(TF_CONNECTION) [0]0A30.0A04::02/06/2011-16:45:34.861.00011408 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(157))$$begin_record
    LogType: connection
    Severity: error
    Text: Receive operation on the connection failed
    Local-IP: 192.168.1.10:63980
    Peer-IP: 192.168.1.20:5061
    Peer-FQDN: lync.domain.local
    Peer-Name: lync.domain.local
    Connection-ID: 0x16C03
    Transport: M-TLS
    Result-Code: 0x80072746 WSAECONNRESET
    $$end_record

     

    06 Şubat 2011 Pazar 16:52
  • Typically “0x80072746 WSAECONNRESET” is related to certificate issue (lack of trust.) Examine the log for “TL_ERROR(TF_CONNECTION)” entry in conjunction with "Text: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?”

    If this is the case, re-evaluate the certificate (specifically CN portion of Lync certificate).

     

    Drago

     

     


    http://ocsdude.blogspot.com
    06 Şubat 2011 Pazar 17:43
  • Thanks for the input.  I don't see anything in the log relating to a TLS negtiation failure.  I'll keep looking though.  Here is the trace from the Lync server:

    TL_ERROR(TF_NETWORK) [0]09A8.0E90::02/07/2011-15:36:30.816.0000000c (SIPStack,NegotiateLogic::ProcessPeerIdentity:NegotiateLogic.cpp(1148))( 0 )( 00000000069A12D0 ) Exit - failed to validate peer with S2S FQDN. Returned 0xC3E93D6A(SIPPROXY_E_CONNECTION_UNKNOWN_SERVER)
    TL_ERROR(TF_CONNECTION) [0]09A8.0E90::02/07/2011-15:36:30.816.0000000d (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(160))$$begin_record
    LogType: connection
    Severity: error
    Text: The peer is not a configured server on this network interface
    Peer-IP: 192.168.1.10:5061
    Peer-FQDN: ocs2007r2.domain.local
    Transport: TLS
    Result-Code: 0xc3e93d6a SIPPROXY_E_CONNECTION_UNKNOWN_SERVER
    Data: fqdn="ocs2007r2.domain.local"
    $$end_record

    TL_ERROR(TF_NETWORK) [0]09A8.0E90::02/07/2011-15:36:30.816.0000000e (SIPStack,CTLSSocket::EvaluateIncomingMessage:TLSSocket.cpp(1195))( 00000000069A0E90 ) Exit - negotiation logic failed, socket will be closed. Returned 0xC3E93D6A(SIPPROXY_E_CONNECTION_UNKNOWN_SERVER)

    07 Şubat 2011 Pazartesi 15:41
  • SIPPROXY_E_CONNECTION_UNKNOWN_SERVER

    Did you "Merge Topology" via Topology Builder to establish trust between the two environments?

     

    Drago


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 16:01
  • Yes, I merged the topology.  When I view the topology I see the BackCompatSite that contains my 2007 pool. 
    07 Şubat 2011 Pazartesi 16:10
  • "Exit - failed to validate peer with S2S FQDN"

    This is not good. Do you see the Legacy servers in Lync Control Panel -> Topology? (Listed as BackCompatSite)

     

    Drago

     


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 16:20
  • Yes, the legacy server appears in the LCP Topology.  Likewise, I can successfully move users from the legacy OCS pool to the Lync pool without error.
    07 Şubat 2011 Pazartesi 16:29
  • I am sorry about the question… J You do not use wildcard certificate(s), correct?

     

    Drago


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 16:50
  • Correct.  No wildcards.  Using a single certificate with multiple SAN's.  This is an internal Enterprise CA.  Both OCS and Lync were issued SAN certificates from the same CA.  They both have the root CA's cert loaded into the computer store's Trusted Root Certificate Authorities.
    07 Şubat 2011 Pazartesi 16:55
  • Puzzling, indeed. why don't you merge the topology one more time from Topology Builder, publish and verify the Lync log replication was successful?

    If still no go, we can pock together this afternoon if you are available.

     

    Drago

     


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 17:05
  • I've just noticed replication UpToDate: False.  I also see an error in the Lync log saying the below.  It does not seem to be a permissions issue, it seems to me that the replication share does not even exist.  The central management store is located on the same server as the standard server.  There is only a single Lync server in the environment.  Shouldn't this directory have been created during setup when we install the local configuration store?  Is there a way to recreate this directory structure?

    Log Name:      Lync Server
    Source:        LS File Transfer Agent Service
    Date:          2/7/2011 10:30:40 AM
    Event ID:      1017
    Task Category: (1121)
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      Lync.domain.local
    Description:
    File transfer failed for some replica machines. Microsoft Lync Server 2010, File Transfer Agent will continuously attempt to replicate to these machines.

    While this condition persists, configuration changes will not be delivered to these replica machines.
    Replica file transfer failures:
    lync.domain.local: Access failed. (Can't watch \\lync.domain.local\xds-replica\to-master.)

    Cause: Possible issues with transferring files to the replicas listed above.
    Resolution:
    Check the accessibility of file shares or https web services listed above.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="LS File Transfer Agent Service" />
        <EventID Qualifiers="50273">1017</EventID>
        <Level>2</Level>
        <Task>1121</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2011-02-07T17:30:40.000000000Z" />
        <EventRecordID>10588</EventRecordID>
        <Channel>Lync Server</Channel>
        <Computer>Lync.domain.local</Computer>
        <Security />
      </System>
      <EventData>
        <Data>Replica file transfer failures:
    lync.domain.local: Access failed. (Can't watch \\lync.domain.local\xds-replica\to-master.)
    </Data>
      </EventData>
    </Event>

    07 Şubat 2011 Pazartesi 17:51
  • We create the share.  Lync Server Deployment Wizard sets the permissions.

    Try this – read the manual one more time J, create the share, make sure it is specified correctly in TB, republish, then run Lync Server Deployment Wizard again on FE. Examine the deployment log file(s) for errors.

     

    Drago


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 18:01
  • I created the share during the initial setup that is used for the Central Management store.  \\lync.domain.local\lync.  This share definately exists, and exists in TB.  It has the following directories created:

    1-ApplicationServer-1

    1-CentralMgmt-1

    1-WebServices-1

    I do a search for files named xds-replica on the entire server and I come up empty.

    07 Şubat 2011 Pazartesi 18:17
  • The replicator agent service is failing with event id 3007.  Interestingly, there is no E:\ on the server, there is only a C:\.  Why is it looking for E:\, and can this be changed?

    Microsoft Lync Server 2010, Replica Replicator Agent Service could not be started.

    Exception information: System.IO.DirectoryNotFoundException: Could not find a part of the path 'E:\RtcReplicaRoot\xds-replica\from-master'.

    The executable for the Replicator service is using:"C:\Program Files\Microsoft Lync Server 2010\Server\Replica Replicator Agent\ReplicaReplicatorAgent.exe" -s /replicaRootDir:E:\RtcReplicaRoot\ /sqlInstance:(local)\rtclocal /sqlDatabase:xds

    Where is it getting this E:\ from ???

     

    07 Şubat 2011 Pazartesi 18:43
  • Upon initial installation, have you had another HDD (i.e. E:\) attached (hardware of virtual) for short period of time. I believe the installation bits uses some sort of smart algorithm to place the DB files on different physical locations where possible (not 100% sure, thou).

    First and foremost, if you have folder named RtcReplicaRoot on your C:\ as of now?

     

    Drago


    http://ocsdude.blogspot.com
    • Yanıt Olarak İşaretleyen netsec545 07 Şubat 2011 Pazartesi 22:20
    07 Şubat 2011 Pazartesi 19:17
  • Sure enough I had a USB drive plugged in.  After I now plug it back in, I see that it is E:\ and has a folder named RtcReplicaRoot.

    Any idea how to change this path, or do I need to re-install?

    07 Şubat 2011 Pazartesi 19:44
  • Use super glue to make the USB drive permanent J

    I know… not funny….

    With the USB drive plugged, run “Invoke-CsManagementStoreReplication” from LyncServer Management Shell. Then, run “Get-CsManagementStoreReplicationStatus”. Make sure the replication is OK.

    From Command Prompt run “xcopy E:\RtcReplicaRoot C:\RtcReplicaRoot /O /X /E /T /H /K”

    This will copy the folder and content while replicating the exact set of permissions needed (this is to have a good copy of the data on your C:\ drive)… and here I just ran out of ideas. Lets hope MSFT will now get involved and point to the correct way to change the path.

    Drago


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 20:16
  • I just got an idea… Actually \\lync.domain.local\xds-replica is nothing by share named “xds-replica”

    Go to \\lync.domain.local (with the USB drive connected) and you will see it as network share. Now, it will not let you browse it because of the specific permissions, but I assume the deleting this share and re-creating it again, while this time pointing to C:\RtcReplicaRoot and naming it “xds-replica” could do the trick. After all, the process looks for the share, not the physical path…

    Again, this is just an idea. I am little surprised no one else got involved by now.

     

    Drago


    http://ocsdude.blogspot.com
    07 Şubat 2011 Pazartesi 20:39
  • Gluing the USB drive in for now will be my temp workaround while I resolve some other issues.  Once E:\ was recognized, replication was again successful, and the backcompatsite recognized, users presence was visable and chat was successful.

    I'm to believe simply adding the path to C:\ will not work because the actual executable in the replication service is pointed to E:\.  I'll give it a try later today.

    Thanks for all your input Drago!!! You really helped me out here.  Maye a re-install of the front-end is my best option at this point.

    07 Şubat 2011 Pazartesi 22:20
  • Upon initial installation, have you had another HDD (i.e. E:\) attached (hardware of virtual) for short period of time. I believe the installation bits uses some sort of smart algorithm to place the DB files on different physical locations where possible (not 100% sure, thou).

    First and foremost, if you have folder named RtcReplicaRoot on your C:\ as of now?

     

    Drago


    http://ocsdude.blogspot.com


    Hello!

    This is very uncool. Everyone (well) with a DMZ edge server will have a external drive attached to the server during installation as you have to get the Topology over to that server with some kind of USB device. I'm having this very same problem and im not in the mood to reinstall the edge server. Anyone else with a workaround for this?


    / Janne
    05 Nisan 2011 Salı 21:48
  • Drago, I tried unsharing the folder from my G: drive but now im unable to share the same folder from the C: drive due to permissions. I also cannot recreate the share on the G: drive due to same reasons :)

    I dont know what kind of permissions is on the xds-replica folder and I think taking ownership will break it?


    / Janne
    06 Nisan 2011 Çarşamba 06:53
  • Finally I think I have a solution for this. If you accidentaly have the Local configuration store share created on an external drive during initial configuration, do as follows:

    • Stop and disable Lync Server Replica Replicator Agent
    • Like Drago wrote: xcopy X:\RtcReplicaRoot C:\RtcReplicaRoot /O /X /E /T /H /K
    • Unshare X:\RtcReplicaRoot\xds-replica\
    • From Programs and Features, Repair Microsoft Lync Server 2010, Core Components
    • Verify that the share has been recreated on the correct drive
    • Enable and start the Lync Server Replica Replicator Agent
    • On computer running the Central Management Server, Invoke replication (Invoke-CsManagementStoreReplication)
    • Wait two minutes and run Get-CsManagementStoreReplicationStatus
    • Verify replication status in Lync Server Control Panel

    Atleast this worked for me :)


    / Janne
    06 Nisan 2011 Çarşamba 07:44
  • Janne,

    I admire your wiliness to share. This is what makes this community the best Lync resource on the Net.

     

    Drago


    http://ocsdude.blogspot.com
    06 Nisan 2011 Çarşamba 14:27
  • Hello everybody

    you can easily change the share.

    Copy the folder to C: as written above

    Go to regedit and make a search for E:\RtcReplicaRoot\xds-replica

    It will be found somewhere under HKEY_LOCAL_MACHINE SYSTEM ...... Shares

    Double click and open the registry key. You will see Path=E:\RtcReplicaRoot\xds-replica just change it what you need

    You have to restart the system to rebuild the registry

    If anybody can provide a way how to rebuild without restart it will be perfect

    29 Mart 2012 Perşembe 17:00
  • Hi Drago,

    I have this issue, but my problem is that the rtcreplicaroot folder does not exist, and I have not deployed another server that I can copy it from. How may I recreate this folder?

    Thanks,

    Rich

    19 Haziran 2012 Salı 01:53