SharePoint Server 2016 Technical Preview may be somewhat short on attention-grabbing, “oh, wow!” features, but one of the most interesting is “durable links.”  Bill Baer, the product manager for SharePoint at Microsoft, describes the nuts and bolts behind the scenes pretty well in this post here.

I’ve been spending a little time playing with durable links myself in preparation for TCSC’s annual fall seminar series, where I’m talking about SharePoint 2016.  While durable links certainly has promise, I’ve found myself hoping this is just the first iteration, as my testing suggests that it’s not as generally useful as one might hope after first hearing of it.

Let’s dive in.

First things first, here’s the scenario where durable links works.

  1. You must be running SharePoint Server 2016.  Obviously, this isn’t going to work in 2013 or previous. (I just tested it, and durable links does work in SharePoint Online.)
  2. You must have Office Web Apps Server or Office Online Server (the new name) deployed.  Yes, this means we need another server stood up, as you still can’t provision OWA/OOS on a SharePoint server.  But the durable links functionality absolutely relies on loading the document in your browser, so OWA/OOS is a necessity.
  3. You must use the URL that the document preview panel provides.  You can’t simply right click on a document in a library, copy it’s URL to the clipboard, paste it somewhere, and expect it to keep working.  You need to get a link that includes the ?d={ID} query string parameter.
  4. You can’t move the file out of its site collection.  Bill Baer explains that the ID the durable link relies upon is stored in a content database.  This means that the link has to be associated with a site collection, because to jump from one site collection to another could involve moving from one content database to another.  I have to wonder why the IDs weren’t stored in a service application database or something similar, so that the IDs could be retained no matter what site collection the file ends up in, but oh well.

So given all the above, your durable link will work no matter what filename or subsite/library path you include in your link, just so long as you keep the ?d={ID} query string parameter.

This is definitely cool, because it means that you can rename files or (theoretically) move files from one document library to another, or even one subsite to another, and the document will still load in your browser through Office Online Server.  Here are some screenshots showing what we’re talking about:

 

DurableLinks-URL

DurableLinks-Durable

 

DurableLinks-NotDurable

 

Based on these screenshots, you can see that loading the file depends on three parts of the URL, the rest of which can be discarded.

http://portal.tcscdemo.com/sites/team1/Documents1/green%20tree%20falling.docx?d=w7a4a35fb348646fb9a673ddfe7fe7ef4

.docx tells SharePoint to handle the link with Office Online Server.  http://portal.tcscdemo.com/sites/team1/ tells Office Online Server which content database to look in, and ?d=w7a4a35fb348646fb9a673ddfe7fe7ef4 specifies the document to retrieve.  Everything else is just junk.

So, all well and good so far.  The one complaint I have, though, is that while renaming files works just fine, the other major use that most people would envision for durable links is the ability to move a file from one library or site to another and have the original link work.  While in theory this should work just fine as long as the document ID travels with the document, the problem is that as soon as you move the document, the ID changes, breaking the original link.

DurableLinks-AfterMove

In summary, durable links so far works really well for renaming files, but until we get a good way to move a document from one library to another and retain its ID, renaming files is really all it’s good for.