NOTE: This blog post is context sensitive to the current state (9/2017) of on-premises SharePoint 2013 and 2016 environments and has no relation to any new evolving data labeling or retention in Office 365. It has come to my attention some very significant features will be announced at Ignite around filling the traditional Records Management feature gaps.
Stay tuned for a post on why you should upgrade/migrate to the latest and greatest!
You see many blog posts by many of my peers. SharePoint eDiscovery is great, Records Management is good (yeah, only good if not bad). But what you rarely hear is the truth of the matter.
Just like in the highlander series…”there can be only one”. As new features are added to any product, they will start to collide. The collisions are becoming more frequent and the regression tests more infinite.
That all being said, if you only had one to choose from, eDiscovery or Records Management. Which one would you choose?
eDiscovery is pretty awesome when taken as a single entity. The ability to find and lock down (aka Hold) items across Exchange and SharePoint for the purposes of litigation for example.
Records Management (again as a single entity) is great in that you can enforce the users to not be able to make modifications to declared records. Albeit, only in the sense that they live in the records center or you have enabled the “In-place records management” feature in a site.
So why can you only have one? Hmm, let’s get to the meat of it shall we?
eDiscovery holds are great in that they allow you to target content such that it does not get modified. It does this through the somewhat well known Preservation Hold Library. That’s all fine and dandy, but the reality that most people don’t get is that when you add a “site” as a source and then create the hold, it holds the entire site by default. Admins (not end users) can get around this by enabling the “hidden” feature of Query based preservation. But when you do this, it adds an entirely new issue of performance to the whole conversation, but we’ll leave that out here.
Ok, so where does the choice come in?
Well, if you want to put a hold on your entire SharePoint Farm, you have to select all the sites in your sources for the eDiscovery case. Its doable, painful, but doable. So what does that do? It of course will make it such that any time a user modifies a document, it will go into preservation hold.
Ok, so what happens when you need to archive a document to the records center? You aren’t destroying it…you aren’t modifying it (per se), you are following basic procedures to create a record. Well, unfortunately my friends, the reality is that you will get an ugly error that the document has in fact moved to the records center, but that a link could not be created:
This is so very bad. You now have a document sitting in the records center, but yet it is also sitting in the source site. What happens is you send it again, which is of course what a user will try to do! Yup, another version is created and unless you have versioning turned on, you get the crazy FileName_ZUOXUDF filename. The original document will sit there…forever…or…until the hold is lifted and then of course, the data owner may have left the company and whala…a orphaned record that no one really knows what to do with!
SharePoint has never truly been a records management platform (content organizer and rules are a complete failure).
Because of this, it’s the reason four different companies formed (RecordPoint, RecordLion, Gimmal, Collabware) to solve the problems that SharePoint has had for quite some time. I’ll skip the inadequacies of those products for now, but likely you’ll get my full opinion on them later in life…
This particular instance of features colliding though…it really pushes organizations over the proverbial limit of understanding and patience.
In reality, the way things should go is…are you sending something to a trusted records center? Yes? Ok cool…I’ll let that action occur because I know its going to someplace good and monitored and approved.
Not…fail no matter what cuz one feature overrides another!
Pick one…but only one.