none
Migration from Lync 2013 to SFB RRS feed

  • Question

  • I am in the process of migrating from Lync2013 to SFB15

    new FE server is built with new standard pool and topology published.

    I have moved 1 test user to the SFB FE

    the user is unable to automatically signin.  my lyndiscoverinternal dns entry points to the Lync2013 FE server.  how do we get automated sign in for users on the SFB FE server?

    I am able to signin if I manually enter the config in the SFB client to point to SFB FE

    I need this step working so that I can move more users and test

    thanks

    Thursday, November 3, 2016 10:07 PM

Answers

  • managed to resolve my problem

    the edge server needed the following as it was not replicating

    Open REGEDIT
    navigate to:

    HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    add the new DWORD:
    ClientAuthTrustMode Value=2

    Now reboot the edge server. After it has restarted, you might need forcing the CMS to replicate:
    Invoke-CsManagementStoreReplication

    • Marked as answer by gemidriver Tuesday, November 29, 2016 10:26 PM
    Tuesday, November 29, 2016 10:26 PM

All replies

  • Hi gemidriver,

    Welcome to our forum.

    We could add another SRV record in DNS for SFB client auto-login, another SRV record should include FQDN of new pool’s FE, please refer to the following link to create SRV record:

    https://technet.microsoft.com/en-us/library/gg425884(v=ocs.15).aspx

    Notice: this link also apply to SFB 2015 server.

    If there are any questions or issues, please be free to let me know.


    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 4, 2016 5:47 AM
    Moderator
  • Hi

    I created the second srv record already, but this still hasn't resolved the auto login

    I thought it referenced the A record for lyncdiscoverinternal first before the SRV records?

    Sunday, November 6, 2016 11:32 PM
  • Hi

    I created the second srv record already, but this still hasn't resolved the auto login

    I thought it referenced the A record for lyncdiscoverinternal first before the SRV records?

    To test it just do a host entry in the local system refer to the new pool.

    It should work...


    Mihir Nayak If a post is helpful, please take a second to vote

    Monday, November 7, 2016 4:16 AM
  • I am able to specify the front end pool in the settings of the SFB client which does work.  but however for testing purposes I didn't want to have to make any manual changes for clients
    Monday, November 7, 2016 4:22 AM
  • when you did the SRV record for the new pool, after that did you clear the cache and profile before trying login ?


    Mihir Nayak If a post is helpful, please take a second to vote

    Monday, November 7, 2016 4:40 AM
  • yes, cleared profile,

    new machine
    Can't sign in to skype for Business

    couldn't find a Skype for Business Server for "domain.com.au" There might be an issue with the Domain Name System (DNS) configuration for your domain.  See KB2566790 for details and contact your system admin

    Monday, November 7, 2016 5:03 AM
  • It is very clear that something is missing in your internal DNS Server.

    Can you please ensure you have the configuration as similar to the below :

    Skype for Business and Lync 2013 are similar in how the client finds and accesses services in Skype for Business Server. The notable exception is the Lync Windows Store app that uses a different service location process. This section details two scenarios of how the clients locate services, first the traditional method using a series of SRV and A host records, second using only the Autodiscover service records. For all clients, the DNS query process continues until a successful query is returned, or the list of possible DNS records is exhausted, and the final error is returned to the client.

    For all clients except for the Lync Windows Store app During DNS lookup, SRV records are queried and returned to the client in the following order:

    1. lyncdiscoverinternal.<domain>   A (host) record for the Autodiscover service on the internal Web services

    2. lyncdiscover.<domain>   A (host) record for the Autodiscover service on the external Web services

    3. _sipinternaltls._tcp.<domain>   SRV (service locator) record for internal TLS connections

    4. _sipinternal._tcp.<domain>   SRV (service locator) record for internal TCP connections (performed only if TCP is allowed)

    5. _sip._tls.<domain>   SRV (service locator) record for external TLS connections

    6. sipinternal.<domain>   A (host) record for the Front End pool or Director, resolvable only on the internal network

    7. sip.<domain>   A (host) record for the Front End pool or Director on the internal network, or the Access Edge service when the client is external

    8. sipexternal.<domain>   A (host) record for the Access Edge service when the client is external

    The Lync Windows Store app changes the process completely because it uses two records:

    1. lyncdiscoverinternal.<domain>   A (host) record for the Autodiscover service on the internal Web services

    2. lyncdiscover.<domain>   A (host) record for the Autodiscover service on the external Web services


    Mihir Nayak If a post is helpful, please take a second to vote

    Monday, November 7, 2016 5:41 AM
  • Hi

    yes, I have all the required dns entries

    we have been using Lync since it was OCS

    Monday, November 7, 2016 5:52 AM
  • Is it possible to enable tracing and then share the logs here...

    From there we can able to see what is happening exactly ?

    It is not able to find the pool information though we have the correct information in DNS.


    Mihir Nayak If a post is helpful, please take a second to vote

    Monday, November 7, 2016 6:46 AM
  • Hi 

    can you  check the basic tests are successfull , like telnet to the Poolname with the port number , etc.  can you also check the certificate is in the correct form like the poolname as the subject name and  SAN entries as recommended ? Did you restart the SFB Fe server after installation. You can enable the logs from the client and analyze the same with snooper.


    Linus || Please mark posts as answers/helpful if it answers your question.

    Monday, November 7, 2016 9:51 AM
  • 1 Login: FAIL (hr = 0x80ee001c)

    VerifyOnEnableEvent result return 10

         ONENABLE_FAIL_SERVER_NOT_REACHABLE

       status=0x80ee001c

        ACTION: SERVER NOT REACHABLE

            NO MORE SERVER TO TRY

        ACTION : PERMANENT ERROR

    1.1 Lync-autodiscovery: FAIL (hr = 0x80004005)

    Lync autodiscovery completed with hr: 0X80004005 sipint:  sipext:  authint:  authext:  ucwaint:  ucwaext:  wts:  ucwaurl:  telemetryurl:  isServiceInRefresh: 0 isTempError: 0Lync autodiscovery completed with hr: 0X80004005 sipint:  sipext:  authint:  authext:  ucwaint:  ucwaext:  wts:  ucwaurl:  telemetryurl:  isServiceInRefresh: 0 isTempError: 0

    1.2 DNSAutoDiscovery: PASS

    Monday, November 7, 2016 10:30 PM
  • Hi gemidriver,

    By this issue, we suggest you create a new user in SFB 2015 server to check if it login automatically. If new user could login automatically, it will be related to Lync route group as the following link:

    http://windowsitpro.com/lync/lync-server-2013-routing-groups

    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.

    Please make sure migrated user to use same value of msRTCSIP-UserRoutingGroupID with new user, then check if the issue persist.

    If there are any questions or issues, please be free to let me know.


    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, November 14, 2016 6:36 AM
    Moderator
  • Hi

    I have a user who is in the new registrar pool of the Skype for Business Server FE

    the account is unable to autologin from the client.  it does autologin if I manually enter the FE server name in the Advanced Connection Settings - Internal server name

    Monday, November 14, 2016 8:23 PM
  • this is strange..
    if I enter either the Lync 2013 FE or Skype for Business FE server name in the manual configuration it works

    but wont work if I don't enter one

    anyone know why this is the case?

    Tuesday, November 15, 2016 4:16 AM
  • Hi gemidriver,

    To this issue, we suggest you check the following steps:

    1. Make sure no connectivity issues between SFB client and DC (include Ping and DNS resolve)
    2. Make sure no connectivity issues between SFB client and new pool’s FE (include Ping and DNS resolve)
    3. For testing, disable firewall and A/V software on SFB client and new pool’s FE
    4. All services are running in new pool’s FE
    5. Re-run certificate using deploy wizard on new pool’s FE

    If there are any questions or issues, please be free to let me know.


    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Sunday, November 20, 2016 2:48 AM
    Moderator
  • all tests working.

    I gave up on my test user, and I moved my account.  it works on the SFB FE

    I have also moved 5 other users who are online with the SFB FE

    I have an issue now that I can't access any external users from the SFB FE server

    in my topology builder my SFB server has the edge server from my current topology (Lync 13)

    what do I need to check from the new SFB FE server to make sure it can use the edge server for federation?

    Monday, November 21, 2016 1:29 AM
  • Hi, 

    Can you check the Site Federation Route Assignment settings from Topology and check which edge server is selected there also see whether it applies to the entire site. 


    Linus || Please mark posts as answers/helpful if it answers your question.

    Monday, November 21, 2016 9:42 AM
  • My entire site has the

    Site federation route assignment

    SIP federation - edg13.domain.com

    then my Edge server has the next hop as my new Skype FrontEnd server, I changed this from my Lync 2013 FE

    Then my Skype Front End Server specifies the Edge pool (for media) - edg13.domain.com

    I am able to receive incoming IM from federated parties, but not send to them

    Monday, November 21, 2016 7:36 PM
  • can you have a check  on the Certificate stores in the Edge server , remove all invalid ones and make sure that intermediate and root are all in proper containers. Check the cert validity and details using the remote connectivity analyzer. 


    Linus || Please mark posts as answers/helpful if it answers your question.

    Tuesday, November 22, 2016 9:03 AM
  • certificates are all fine.  they haven't changed on the edge server

    the lync 2013 FE users are accessing external fine

    it is just the Skype FE server with problems

    SFB event logs

    Connection to the Web Conferencing Edge Server has succeeded

    Edge Server Machine FQDN: edg13.domain.com.au, Port:8057

    No connectivity with any of Web Conferencing Edge Servers. External Skype for Business clients cannot use Web Conferencing modality.

    Cause: Service may be unavailable or Network connectivity may have been compromised.
    Resolution:
    Verify all Web Conferencing Edge Services in the topology are running, and network connectivity is available.

    The Edge server event logs

    Multiple incoming connections on internal edge from non-internal servers.

    In the past 134 minutes the server received 30 incoming connections on internal edge from non-internal servers. The last one was from host sfb15.domain.com.au.
    Cause: This can happen if an internal server is not present in the list of internal servers on the Access Edge Server.
    Resolution:
    If the server is a valid one, you need to add it to the list of internal servers on the Access Edge Server. If the server is invalid, you may be under an attack from that server.

    Tuesday, November 22, 2016 9:25 PM
  • the SIPStack from edge server

    TL_INFO(TF_PROTOCOL) [0]1024.053C::11/24/2016-02:46:41.234.0000029e (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3879290219] $$begin_record
    Trace-Correlation-Id: 3879290219
    Instance-Id: 1EE
    Direction: incoming;source="internal edge";destination="external edge"
    Peer: 10.190.66.55:51512
    Message-Type: request
    Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
    From: sip:sfb15.domain.com.au;tag=6B12341704025FA5B079146E10E29DB9
    To: sip:edg13.domain.com.au
    Call-ID: D242EEB8142DAAFDDAFB
    CSeq: 1 NEGOTIATE
    Via: SIP/2.0/TLS 10.190.66.55:51512;branch=z9hG4bK921736BD.E694E1BF829C8AF1;branched=FALSE
    Max-Forwards: 0
    Content-Length: 0
    Require: ms-compression
    ms-negotiate-data: LZ77-64K
    Supported: NewNegotiate,OCSNative,ECC,IPv6,TlsRecordSplit,PstnTrafficType,Draining
    Server: RTC/6.0
    $$end_record

    TL_ERROR(TF_CONNECTION) [0]1024.053C::11/24/2016-02:46:41.250.000003c9 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(389))[1646472262] $$begin_record
    Severity: error
    Text: The peer is not a configured server on this network interface
    Peer-IP: 10.190.66.55:51512
    Transport: TLS
    Result-Code: 0xc3e93d6a SIPPROXY_E_CONNECTION_UNKNOWN_SERVER
    Data: fqdn="sfb15.domain.com.au"
    $$end_record

    PLEASE HELP

    Thursday, November 24, 2016 2:56 AM
  • Hi gemidriver,

    We should configure static route for Edge’s internal interface to make sure Edge could communicate with FE server:

    https://technet.microsoft.com/en-us/library/gg412847(v=ocs.15).aspx

    If there are any questions or issues, please be free to let me know.   


    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 24, 2016 2:58 AM
    Moderator
  • I have the network cards set correctly, and routing works
    I can telnet on all ports from the edge to the new SFB FE server fine

    The existing infrastructure all works with Lync FE and Lync Edge
    Just not able to send external with the SFB FE / Lync Edge

    driving me crazy!!

    Thursday, November 24, 2016 3:01 AM
  • Can you also take a wireshark trace from the edge server and check  if there is any reset happening for the packets. 


    Linus || Please mark posts as answers/helpful if it answers your question.

    Thursday, November 24, 2016 9:11 AM
  • what specifics would you like me to capture?
    Thursday, November 24, 2016 7:47 PM
  • Frame 7602: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
    Ethernet II, Src: Vmware_9c:45:1d (00:50:56:9c:45:1d), Dst: Vmware_85:f4:2b (00:0c:29:85:f4:2b)
    Internet Protocol Version 4, Src: sfb15.domain.com.au (10.190.66.55), Dst: 10.190.66.46 (10.190.66.46)
    Transmission Control Protocol, Src Port: 60798 (60798), Dst Port: 5061 (5061), Seq: 0, Len: 0
        Source Port: 60798
        Destination Port: 5061
        [Stream index: 51]
        [TCP Segment Len: 0]
        Sequence number: 0    (relative sequence number)
        Acknowledgment number: 0
        Header Length: 32 bytes
        Flags: 0x0c2 (SYN, ECN, CWR)
            000. .... .... = Reserved: Not set
            ...0 .... .... = Nonce: Not set
            .... 1... .... = Congestion Window Reduced (CWR): Set
            .... .1.. .... = ECN-Echo: Set
            .... ..0. .... = Urgent: Not set
            .... ...0 .... = Acknowledgment: Not set
            .... .... 0... = Push: Not set
            .... .... .0.. = Reset: Not set
            .... .... ..1. = Syn: Set
            .... .... ...0 = Fin: Not set
            [TCP Flags: ****CE****S*]
        Window size value: 8192
        [Calculated window size: 8192]
        Checksum: 0x4eeb [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
        Urgent pointer: 0
        Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted

    Frame 7614: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0
    Ethernet II, Src: Vmware_85:f4:2b (00:0c:29:85:f4:2b), Dst: Vmware_9c:45:1d (00:50:56:9c:45:1d)
    Internet Protocol Version 4, Src: 10.190.66.46 (10.190.66.46), Dst: sfb15.domain.com.au (10.190.66.55)
    Transmission Control Protocol, Src Port: 5061 (5061), Dst Port: 60798 (60798), Seq: 2025, Ack: 3483, Len: 0
        Source Port: 5061
        Destination Port: 60798
        [Stream index: 51]
        [TCP Segment Len: 0]
        Sequence number: 2025    (relative sequence number)
        Acknowledgment number: 3483    (relative ack number)
        Header Length: 20 bytes
        Flags: 0x014 (RST, ACK)
            000. .... .... = Reserved: Not set
            ...0 .... .... = Nonce: Not set
            .... 0... .... = Congestion Window Reduced (CWR): Not set
            .... .0.. .... = ECN-Echo: Not set
            .... ..0. .... = Urgent: Not set
            .... ...1 .... = Acknowledgment: Set
            .... .... 0... = Push: Not set
            .... .... .1.. = Reset: Set
            .... .... ..0. = Syn: Not set
            .... .... ...0 = Fin: Not set
            [TCP Flags: *******A*R**]
        Window size value: 0
        [Calculated window size: 0]
        [Window size scaling factor: 256]
        Checksum: 0x99fb [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
        Urgent pointer: 0
        [SEQ/ACK analysis]
            [This is an ACK to the segment in frame: 7613]
            [The RTT to ACK the segment was: 0.000258000 seconds]
            [iRTT: 0.000330000 seconds]

    Thursday, November 24, 2016 8:06 PM
  • managed to resolve my problem

    the edge server needed the following as it was not replicating

    Open REGEDIT
    navigate to:

    HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    add the new DWORD:
    ClientAuthTrustMode Value=2

    Now reboot the edge server. After it has restarted, you might need forcing the CMS to replicate:
    Invoke-CsManagementStoreReplication

    • Marked as answer by gemidriver Tuesday, November 29, 2016 10:26 PM
    Tuesday, November 29, 2016 10:26 PM