Lync Meeting Content and Attachments That Won’t Download
My most recent adventure involved a scenario where files uploaded or attached to a Lync meeting couldn’t be saved by many of the meeting participants. You could press the Save As or Open buttons, but the progress indicator would just sit at 0% and never move. Some users in each meeting could actually download the content, but the behavior did not follow specific users or meetings. Permissions in the meeting were set to allow anyone to download, so it didn’t appear to be an issue specific to the meeting settings. The Lync QoE report submitted by each client gave me a rather unhelpful message:
A resource was unable to be downloaded via HTTP
Time to do some tracing. Firing up Fiddler allowed me to see the client make a download attempt to the external web services site, but I was getting a 404 Not Found response from the server. Sure enough, I was able to find the same hit from my client in the IIS logs on the Front End server.
GET /DataCollabWeb/Fd/05f08f60-e18a-5f5c-b73d-2331aa486896/{ED48B5A7-1CD5-4D5F-9D04-6EC08A6F8FEF}/S4S3N9QD/bc2f8fb2-0948-f75b-9a96-fddf0018beef.bin - 4443 - 192.168.200.224 Mozilla/4.0+(compatible+;+MSIE+9.10.9200.16688+;+Microsoft+Windows+Professional++;+Placeware+RPC+1.0) - 404 0 2 22
Odd. IIS was unable to locate the file the Lync client was asking for. IIS serves up these files from the Lync back-end file share, which pointed me in the direction of the DFS share. This was configured to replicate between two file servers, but nothing looked obviously wrong after opening the share folder.
After some more thought I opened the individual shares on each server. Bingo. They each had different, unique content, only one of which matched what I saw in the actual shared Lync namespace! The Front Ends connections were being distributed across the different DFS members and the content was not being replicated on the back-end, which created scenarios where a file would appear to be missing.
Digging in to the DFS logs allowed me to see the servers had stopped replicating almost 90 days earlier. DFS in 2008 R2 and later uses a feature that prevents replication from restarting if an automatic recovery occurred after a network or power outage. So a brief issue a few months back actually caused DFS to stop replication, and it never resolved itself.
You can switch the automatic recovery back to pre-Server 2008 R2 behavior with this command (from an elevated command prompt) on each DFS node:
wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE
Even still, that change does not magically fix DFS. If a node has been unable to replicate for more than 60 days DFS will also prevent the replication from occurring due to a MaxOfflineTimeInDays parameter. You can view that default value with this command:
wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
And if you need to adjust that value you can use this command on each node:
wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=120
This actually still did not resolve my problem. In the interest of time I was able to use the following steps to get replication flowing again:
- Disable the secondary node in the Replication Group through the DFS Management Console.
- On the secondary node, remove the existing file share to close all connections to it.
- Copy all of the content from the secondary node to a temporary location.
- Remove all content from the (now unshared) folder on the secondary node.
- Share the empty folder on the secondary node.
- Re-enable the secondary node in the DFS Management Console.
- Copy the temporary saved data to the primary node’s file share, skipping any duplicate files.
Issue the following command on both nodes to poll Active Directory for an update:
dfsrdiag.exe PollAD
You should see Event Log entries logged that indicate replication is starting and that an initial sync has completed. After validating replication was working I was able to successfully download newly uploaded meeting content from any connected client.