After migrating to Skype for Business and removing Lync 2010/2013 pools, you may encounter an event ID 1034 stating that the LS File Transfer Agent encountered an error while accessing a file share.
The file share referenced will be the share on the removed Lync 2010/2013 pool. If you run the command Get-CsCentralManagementStoreReplicationStatus -CentralManagementStoreStatus, you will se an entry of DeletedReplicas that states the server FQDN of your deleted Lync pool/server. If the server is deleted from the topology not to be used again, you can proceed with deleting the server from the XDS database.
The easiest way to accomplish this, is to make sure that all Lync server components are removed from the Lync server in question. Simply go ahead and remove the Lync components from the server using Add/Remove programs. Make sure to reboot the server after the removal of the Lync components. The error message in the event log should disappear after this operation.
If this is not successfull, you will have to remove the replica ID’s from the SQL database(XDS).
Recently I came across a strange problem which I thought I would share.
The scenario is Lync Server 2013 Standard edition and Lync Server 2010 Mediation server(in process of migrating). The problem started when a user reported that he wasn’t able to receive incoming PSTN calls. Outbound calls was working just fine.
I started investigating the problem and ran some tracing with Wireshark on the Mediation server along with Lync Server logging tool. The Wireshark traces showed that the Lync Mediation server was sending “487 – Request terminated” to the PSTN gateway after receiving a CANCEL.
Snooper logs was showing the same messages and also in some cases “504 – Server timed out”. The Lync Monitoring server had no records of the call beeing established at all. After checking with the service provider of the PSTN gateway and doing some thorough checks of the unassigned numbers and all other kind of stuff(including the use of this script from a colleague to check all registered telephone numbers used in Lync and other systems), I was left in the dark. There was no reason for this not to work as it should.
Solution: Rebooted the Lync 2013 FrontEnd server, and everything worked like a charm.
Key takeaway from this post: When in doubt, reboot 🙂
This post focuses on some key points I’ve come accross when migrating from Lync 2010 to Lync 2013(causing small delays in progress :)).
Static Routing: One of my first migrations took a bit longer to Complete due to faulty routing on the new Edge server. The static routes were created on the server prior to activating the NIC, which lead to failure to communicate. Once the routes were deleted and recreated, everything worked like a charm.
Office Web apps has to be published to the internet using HTTPS and SSL certificate, otherwise you won’t be able to share Powerpoint’s with your federated contacts. Consider using the same URL for internal and external use because this allows for the SSL certificate to be used on both sites on the IIS. How to publish Office Web Apps server
Mobility login: Problems with Exchange Web Services(EWS). Make sure Exchange Web Services External URL is set correct. Consider using the same URL for internal and external web services.
This script provided by MVP Ståle Hansen is an excellent Resource for setting Exchange URL’s.
External web services URL: Remember to change External Web Services FQDN on the new Front End pool, your web services won’t work unless you do 🙂
Client Version policy: Remember to allow legacy clients to login to the new Lync 2013 server(for Legacy). Default is Blocked for Lync 2010 Clients older than 4.0.07577.4103(CU6, June 2012).
This applies only to Lync 2013 on Windows Server 2012.
After installing Lync on Windows Server 2012, replication between Edge server and Front End stops working. This could be as a result of the stricter certificate handling on Windows Server 2012. Check out this post by Terence Luk on how to fix this problem. Another solution to the problem could be found in this article by Herman Seminiano. Both solutions fixes the problem.
This post will be updated as I discover more points to remember during future migration projects.