Known issues and Best practices for file caching appliances – Nasuni, Synology, Morro Data, etc

We have a number of clients running MyWorkDrive as the remote access Web client and map drive for files stored with remote caching appliances/tools from companies like Nasuni, Synology and Morro Data.

With these, the files are stored in the cloud and pulled down locally to the on premise device when accessed by the user.

There are four considerations to make when deploying MyWorkDrive with a remote storage file caching appliance.

1) We generally recommend you keep the MyWorkDrive server next to a “ready cache” of all available files and documents, that way the MyWorkDrive server doesn’t have to wait for the document to be downloaded from the cloud before passing it on to the end user or up to Office Online for editing.
​
Clients who are able to deploy in this manner, where all available documents are stored on the appliance the MyWorkDrive server is locally connecting to, report far few issues with file performance – timeouts, slowness – than anyone else using a caching type appliance as part of their solution.

2) To maintain performance and stability, MyWorkDrive has a built in timeout feature when accessing network shares. If the share does not respond within a certain time (default is 2 seconds), MyWorkDrive proceeds to mount shares without the unresponsive volumes. This keeps the client from hanging and the server from slowing down waiting for or attempting to serve file shares which may be offline.

We have seen a pattern where caching appliances have a tendancy to “go to sleep” and need to “warm up” before they will respond to share requests in a timely fashion.

We made some specific improvements to our software to address this case, as it presented as a clear pattern, but in some cases you may still find it necessary to adjust our timeout setting to prevent shares from failing to map on first access after a period of non-use. Contact us for specific details about adjusting the DirectoryExistsMillisecondsTimeout setting if you notice a pattern of needing to login twice to get shares on caching appliances to appear in MyWorkDrive clients.

3) Nasuni, in particuarly, exhibitied a problem with AzureAD SSO logins failing because the Nasuni wouldn’t recognize a UPN (user@domain.ext) and would only take a pure username. To address this, we added a parameter to the settings of MyWorkDrive to allow the domain named to be stripped off after authentication and prior to mounting shares being mounted for the user.

New clients have not been reporting this issue, so it is likely Nasuni updated their devices to accept UPNs for usernames, but if you come across a situation with a Nasuni where shares are not mounted after SSO login (and delegation is set correctly!) , contact us for specific details about adjusting SsoRemoveDomainBeforeImpersonation setting.

4) Finally, we have experienced that Cache/sync appliances often do not handle the syncing of file locks well. Say a user attached to the appliance at HQ opens a document to edit. A lock is placed on that file via SMB to indicate to other users that file is read only and cannot be edited.

If that lock is not sync’d to other locations, like a traveling support technician or a field office in another country, a user outside of HQ could open and edit that same document and result in a conflict to resolve, their changes being lost, or overwriting the person in HQ.

You’ll want to make sure your cache/sync appliance vendor supports replicating file locks.

For Nasuni, we have noted that the default “read” file lock applied by MyWorkDrive may not be correctly replicated, and the setting LockFileAccessMode may need to be changed to ReadWrite. If you are using a Nasuni, please test file locking across your Nasuni appliances. If it is not working, contact us for details about changing the LockFileAccessMode.