locked
Unable to Federate Lync Server 2010 with Microsoft RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Dear Fellows,

    We are unable to federate our Lync infrastructure with Microsoft despite of many efforts. We are unable to identify the root cause. Whenever Microsoft representative attempts to federate following error occurs:

    Validation Test Result:

    FAIL - Unable to form TLS connection with partner Edge.

    Validation Test Details:

    A 504 (Server time-out) response was received from the network and the operation failed. See the exception details for more information. ResponseCode=504 ResponseText=Server time-out DiagnosticInformation=ErrorCode=1017,Source=sipfed.microsoft.com,Reason=Cannot route From and To domains in this combination

    Federation Enablement:

    Enablement failed for sipdomain.com

    Any thoughts or idea would be appreciated.

    Thanks.

    Junaid Ahmed


    Saturday, May 12, 2012 8:44 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Sharon, I think he is talking about federating with microsoft.com as in the error it says sipfed.microsoft.com and not federation.messenger.msn.com.

    JunaidAhmed83,

    Is this correct? trying to federate with MS directly? if this is the case your MS Rep needs to request federation to your enviroment via the submission tool. when we did it the tool was closed for a while. also please see these validation requirements on federating with microsoft.com.

    VALIDATION REQUIREMENTS

    1. Live Communications Server 2005 or greater must be used.
    2. A publically available DNS SRV record for _sipfederationtls._tcp.sip_domain for port 5061 that points to a valid A record for the Access Edge server.
      For example:

    set type=SRV
    _sipfederationtls._tcp.microsoft.com
    Non-authoritative answer: _sipfederationtls._tcp.microsoft.com SRV service location:
    priority = 0
    weight = 0
    port = 5061
    svr hostname = sipfed.microsoft.com
    set type=A
    sipfed.microsoft.com
    Non-authoritative answer:
    Name: sipfed.microsoft.com
    Address: 131.107.115.72

    1. Internal and External firewalls must be configured to allow Bi-directional traffic on TCP port 5061 to the Microsoft access edge sipfed.microsoft.com, at IP Address: 131.107.115.72
    2. The access edge server must be configured to allow federaitons, and Microsoft's SIP domain - microsoft.com - must be added to the allow list of the access edge server. For more information regarding OCS Acess Edge setup and deployment, please visit http://technet.microsoft.com/en-us/library/bb870345.aspx
    3. The certificate used on the Public interface of the Access Edge must be signed by a public Certificate Authority and have the SIP domain in the FQDN of the server in the "Subjext Name = ServerName.SIP_Domain" section of the certificate, or in a seperate "Subject Alternate Name = SIP_Domain" section of the Certificate. If multiple SIP domains will be serviced by the same Access Edge server, the SN= should be the FQDN of the access edge server itself, with a SAN= entry for each SIP Domain that will serviced by this edge server, and the entire chain of authority must be verifiable. For more information on installing certificates please visit http://technet.microsoft.com/en-us/library/bb663762.aspx

    If this post answered your question, Mark As Answer If this post was helpful, Vote as Helpful ---------------------------------------------------------- http://lyncme.blogspot.com

    • Proposed as answer by Tim_MCP Thursday, May 17, 2012 1:36 PM
    • Unproposed as answer by JunaidAhmedpk Saturday, May 19, 2012 9:19 AM
    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:39 AM
    Thursday, May 17, 2012 1:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes public certificate is being used (from Digicert).

    for internal certificates we are using Internal CA(Windows Server 2008). for external we are using Digicert

    There is no firewall at the moment, so all the ports are accessible from outside as well as inside.

    Since it is a Digicert cert, I assume you already ran the Digicert utility and fixed the root chain on your edge server. If thats the case, the only thing I can advise is to run "Lync logging" and packet capturing  on port 5061 while Microsoft is performing the validation. May be that would offer you some hints.

    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:38 AM
    Monday, May 28, 2012 1:15 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It is also possible that you are missing Microsoft Intermediate Certificate. Please work with your Microsoft representative and ask him or her to retrieve the chain from http://fedreq/CertChainGuide.htm (Microsoft internal resource) and provide it to you.

    hth,

    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:38 AM
    Monday, July 16, 2012 7:20 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Sorry guys for updating late.

    Although strange, but issue was resolved after publishing the topology again on all the Lync 2010 servers (without making any change to topology or certificates).

    Thanks.

    Junaid Ahmed

    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:38 AM
    Sunday, October 7, 2012 4:38 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,Junaid,

    Did you complete the PIC provisioning?You should receive email from Microsoft told you that the provisioning  is completed.You can check the following link to get more details about the provisioning process.(Download the guide from here )

    http://technet.microsoft.com/en-us/library/ff945947.aspx 

    And here is the general question about PIC Provisioning

    https://pic.lync.com/provision/Logon/FAQ.htm 

    Hope these useful!

    B/R

    Sharon

    Sharon Shen

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.

    Monday, May 14, 2012 8:13 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Sharon, I think he is talking about federating with microsoft.com as in the error it says sipfed.microsoft.com and not federation.messenger.msn.com.

    JunaidAhmed83,

    Is this correct? trying to federate with MS directly? if this is the case your MS Rep needs to request federation to your enviroment via the submission tool. when we did it the tool was closed for a while. also please see these validation requirements on federating with microsoft.com.

    VALIDATION REQUIREMENTS

    1. Live Communications Server 2005 or greater must be used.
    2. A publically available DNS SRV record for _sipfederationtls._tcp.sip_domain for port 5061 that points to a valid A record for the Access Edge server.
      For example:

    set type=SRV
    _sipfederationtls._tcp.microsoft.com
    Non-authoritative answer: _sipfederationtls._tcp.microsoft.com SRV service location:
    priority = 0
    weight = 0
    port = 5061
    svr hostname = sipfed.microsoft.com
    set type=A
    sipfed.microsoft.com
    Non-authoritative answer:
    Name: sipfed.microsoft.com
    Address: 131.107.115.72

    1. Internal and External firewalls must be configured to allow Bi-directional traffic on TCP port 5061 to the Microsoft access edge sipfed.microsoft.com, at IP Address: 131.107.115.72
    2. The access edge server must be configured to allow federaitons, and Microsoft's SIP domain - microsoft.com - must be added to the allow list of the access edge server. For more information regarding OCS Acess Edge setup and deployment, please visit http://technet.microsoft.com/en-us/library/bb870345.aspx
    3. The certificate used on the Public interface of the Access Edge must be signed by a public Certificate Authority and have the SIP domain in the FQDN of the server in the "Subjext Name = ServerName.SIP_Domain" section of the certificate, or in a seperate "Subject Alternate Name = SIP_Domain" section of the Certificate. If multiple SIP domains will be serviced by the same Access Edge server, the SN= should be the FQDN of the access edge server itself, with a SAN= entry for each SIP Domain that will serviced by this edge server, and the entire chain of authority must be verifiable. For more information on installing certificates please visit http://technet.microsoft.com/en-us/library/bb663762.aspx

    If this post answered your question, Mark As Answer If this post was helpful, Vote as Helpful ---------------------------------------------------------- http://lyncme.blogspot.com

    • Proposed as answer by Tim_MCP Thursday, May 17, 2012 1:36 PM
    • Unproposed as answer by JunaidAhmedpk Saturday, May 19, 2012 9:19 AM
    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:39 AM
    Thursday, May 17, 2012 1:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Validation Test Result:

    FAIL - Unable to form TLS connection with partner Edge.

    Any thoughts or idea would be appreciated.

    - Are you using a Public certificate for your "Access Edge"?
    - What CA are you using?
    - Do you allow outbound HTTP access for your edge server?

    Friday, May 18, 2012 2:05 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Dear Tim,
    Thank you for the response, Yes i am talking about federating with Microsoft Directly.

    We have fulfilled all these requirements long before posting this post, but still not able to federate.

    1. We have Lync Server 2010

    2. SRV Record is in place and pointing to A record which points to Edge Server external interface (public IP)

    3. No firewall is in place for the time being. bothway communication is allowed and verified to port 5061 and 443

    4. Microsoft.com is also added in the Federation allowed domain list.

    5. Certificate we are using is from DigiCert and includes the FQDN name of Access Edge and the A record (used in SRV)

    6. Microsoft's certificate chain has also been imported as per guidelines provided by MS

    Still we are getting this Error 504 mentioned above.

    Thanks.

    Junaid Ahmed


    Saturday, May 19, 2012 9:14 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Dear Adminiuga,

    Yes public certificate is being used (from Digicert).

    for internal certificates we are using Internal CA(Windows Server 2008). for external we are using Digicert

    There is no firewall at the moment, so all the ports are accessible from outside as well as inside.

    Thanks.

    Junaid Ahmed

    Saturday, May 19, 2012 9:17 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Dear Sharon,
    Thank you for your response. I have gone through these links and these are not saying anything for federating with Microsoft. These are for other IM providers. We need to federate with Microsoft itself.

    Thanks.

    Junaid Ahmed

    Saturday, May 19, 2012 9:19 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Are you able to federate with any other OCS/Lync deployments?

    Also, in your topology for your edge pool, did you specify 3 diffrent IP Address for sip, av and webconf? or just 1?

    If this post answered your question, Mark As Answer If this post was helpful, Vote as Helpful ---------------------------------------------------------- http://lyncme.blogspot.com


    • Edited by Tim_MCP Thursday, May 24, 2012 2:57 PM
    Thursday, May 24, 2012 2:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes public certificate is being used (from Digicert).

    for internal certificates we are using Internal CA(Windows Server 2008). for external we are using Digicert

    There is no firewall at the moment, so all the ports are accessible from outside as well as inside.

    Since it is a Digicert cert, I assume you already ran the Digicert utility and fixed the root chain on your edge server. If thats the case, the only thing I can advise is to run "Lync logging" and packet capturing  on port 5061 while Microsoft is performing the validation. May be that would offer you some hints.

    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:38 AM
    Monday, May 28, 2012 1:15 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It is also possible that you are missing Microsoft Intermediate Certificate. Please work with your Microsoft representative and ask him or her to retrieve the chain from http://fedreq/CertChainGuide.htm (Microsoft internal resource) and provide it to you.

    hth,

    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:38 AM
    Monday, July 16, 2012 7:20 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Sorry guys for updating late.

    Although strange, but issue was resolved after publishing the topology again on all the Lync 2010 servers (without making any change to topology or certificates).

    Thanks.

    Junaid Ahmed

    • Marked as answer by JunaidAhmedpk Sunday, October 7, 2012 4:38 AM
    Sunday, October 7, 2012 4:38 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I know this article goes back a bit.  But I've just gone through federating with Microsoft.  I initially encountered the same error message.  "Unable to form TLS connection with partner Edge". Microsoft sent me a list of common validation errors and resolutions.

    The one that resolved it for me was "The partner does not have Microsoft’s certificate chain installed".  rI used RUCT to retrieve the certificate and install the sipfed.microsoft.com certificate on my Edge server. Computer account, Local Computer, Trusted Root Certificate Authorities.  Once done we passed verification and I was able to IM our PAM.

    Common Validation Errors and their meanings.
    Error:
    Unable to resolve DNS SRV Record
    Cause:
    SRV record for the SIP Domain was not found in publicly available DNS, or the SRV record is not configured correctly.

    Resolution:
    The customer needs to create and/or configure an SRV record using the following guidelines:
    http://technet.microsoft.com/en-us/library/bb803629(TechNet.10).aspx
    Error:
    Unable to establish connection on port 5061 with partner Edge
    Cause:
    This is typically a mis-configured firewall issue or the target Edge server is not listening on 5061

    Resolution:
    The Edge server needs to be accessible externally, be online, and listening on port 5061. In addition the firewall needs to allow traffic in and out for this server on port 5061. 

    Please make sure the access edge is online with OCS services running and accessible remotely. Use the following guidelines:
    http://technet.microsoft.com/en-us/library/bb803617(TechNet.10).aspx
    Error:
    Unable to form TLS connection with partner Edge
    Cause:
    This is the most common error and it can be caused by a number of things:
    ·         A firewall blocking communication between MS and the partner
    ·         The partner has not added Microsoft.com to their allow list
    ·         The partner does not have Microsoft’s certificate chain installed
    ·         The partner is using an untrusted certificate chain
    Resolution:
    See the resolution steps in the box above for information regarding firewall issues. 
     
    The partner must add “Microsoft.com” to the allow list on their edge servers, otherwise their edge servers will deny traffic from Microsoft.
     
    The partner also needs to install the Windows root certificate package (http://support.microsoft.com/kb/931125) and their edge server’s certificate must be issued by CA that is included in that package.  A list of the CAs included can be seen here:http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx.


    Best Regards Randy Chapman

    Monday, October 28, 2013 2:30 PM