Presence Unknown between OCS 2007R2 and Lync RTM


  • 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. 




    2011年2月5日 18:03


  • 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?


    • 回答としてマーク netsec545 2011年2月7日 22:20
    2011年2月7日 19:17


  • 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
    Peer-FQDN: lync.domain.local
    Peer-Name: lync.domain.local
    Connection-ID: 0x16C03
    Transport: M-TLS
    Result-Code: 0x80072746 WSAECONNRESET


    2011年2月6日 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).




    2011年2月6日 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-FQDN: ocs2007r2.domain.local
    Transport: TLS
    Data: fqdn="ocs2007r2.domain.local"

    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)

    2011年2月7日 15:41

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


    2011年2月7日 16:01
  • Yes, I merged the topology.  When I view the topology I see the BackCompatSite that contains my 2007 pool. 
    2011年2月7日 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)



    2011年2月7日 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.
    2011年2月7日 16:29
  • I am sorry about the question… J You do not use wildcard certificate(s), correct?


    2011年2月7日 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.
    2011年2月7日 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.



    2011年2月7日 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
    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.
    Check the accessibility of file shares or https web services listed above.
    Event Xml:
    <Event xmlns="">
        <Provider Name="LS File Transfer Agent Service" />
        <EventID Qualifiers="50273">1017</EventID>
        <TimeCreated SystemTime="2011-02-07T17:30:40.000000000Z" />
        <Channel>Lync Server</Channel>
        <Security />
        <Data>Replica file transfer failures:
    lync.domain.local: Access failed. (Can't watch \\lync.domain.local\xds-replica\to-master.)

    2011年2月7日 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.


    2011年2月7日 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:




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

    2011年2月7日 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 ???


    2011年2月7日 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?


    • 回答としてマーク netsec545 2011年2月7日 22:20
    2011年2月7日 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?

    2011年2月7日 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.

    2011年2月7日 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.


    2011年2月7日 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.

    2011年2月7日 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?




    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
    2011年4月5日 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
    2011年4月6日 6: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
    2011年4月6日 7:44
  • Janne,

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


    2011年4月6日 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

    2012年3月29日 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?



    2012年6月19日 1:53