Answered by:
Migration from Lync 2013 to SFB

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=2Now 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 -
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 clientsMonday, 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 Businesscouldn'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:
-
lyncdiscoverinternal.<domain> A (host) record for the Autodiscover service on the internal Web services
-
lyncdiscover.<domain> A (host) record for the Autodiscover service on the external Web services
-
_sipinternaltls._tcp.<domain> SRV (service locator) record for internal TLS connections
-
_sipinternal._tcp.<domain> SRV (service locator) record for internal TCP connections (performed only if TCP is allowed)
-
_sip._tls.<domain> SRV (service locator) record for external TLS connections
-
sipinternal.<domain> A (host) record for the Front End pool or Director, resolvable only on the internal network
-
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
-
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:
-
lyncdiscoverinternal.<domain> A (host) record for the Autodiscover service on the internal Web services
-
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 -
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 worksbut 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:
- Make sure no connectivity issues between SFB client and DC (include Ping and DNS resolve)
- Make sure no connectivity issues between SFB client and new pool’s FE (include Ping and DNS resolve)
- For testing, disable firewall and A/V software on SFB client and new pool’s FE
- All services are running in new pool’s FE
- 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.- Proposed as answer by jim-xu Sunday, November 20, 2016 4:31 AM
Sunday, November 20, 2016 2:48 AM -
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_recordTL_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_recordPLEASE 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 -
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 fineThe existing infrastructure all works with Lync FE and Lync Edge
Just not able to send external with the SFB FE / Lync Edgedriving 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 permittedFrame 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=2Now 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