Cleaning Up File Shares Fight For the Users

2015-21-April-Tron.jpg

In our ongoing quest to clean up our file shares (because we know some day Microsoft will pull the rug from them), today we're going to look at the opportunity that security identifiers (SID) offer. 

Objects that belong to the custodianship of a security identification (SID) code can potentially impact the size of your unstructured content storage location in a significant and immediate way. These objects are an early opportunity within your project -- if you decide not to consult the existing team.

If you intend to use retention periods as coefficients in your various archive/deletion/destruction algorithm(s), you are better positioned to do so if your organization is at least five years old. See the “Statistical Analysis Template” figure in this post.

Compare the stacked percentage column of information growth on the left hand side to the two sample retention management columns on the right. I offer two retention management columns in response to the span of the organization’s information growth so that senior leadership of the Accounting/Finance function can understand the difference between the shallow vs. deep retention choice.

By making this choice, they acknowledge and embrace their content management preference as well as share responsibility for server performance.

Legacy Content

But retention management is only one piece of the archive/deletion/destruction algorithm.

My senior leadership and I haggle a bit on this, but you remember those SIDs I was discussing in this article? This is legacy content sitting on the file share -- objects created by departed employees who no longer have an Active Directory ID attached to them. I pore over the duplicate object reports regularly as more teams are incorporated into the project to find the SIDs that created objects by the same name.

The logic here is this: if the SID created an object by the same name, at least this former employee or contractor probably matrixed into a variation of the current team, if not reported directly to it. This is enough justification to assign custodianship to the senior leadership of the existing version of the team for which I’m producing duplicate objects reports.

Collating all the SIDs allows you to assign their most likely point of origin. I work in the Energy industry at the moment, so maybe the SID was a member of the Exploration team, or Production, or more likely they worked across Facilities teams. But you get the idea: I know the SID, the probable team(s), the number of objects, the total size of those objects, and the date when those objects were last accessed/changed. These useful descriptions become a kind of crib sheet.

Fight for the Users

Armed with an annotated complete list of SIDs, I run full object reports for each of them and show them to the senior leadership of that team. I know whether or not the objects belonging to that SID have been edited recently. That doesn’t impact my decision to offline them. However, it’s just as crucial a moment with my customer as presenting the eighth version of the hotly debated destination folder structure -- our Directors want, no, need -- to know what content is reassigned to them.

Success rate? I am fortunate … I can usually make a compelling argument to archive the objects off if the custodian is reluctant. Usually, however, the person does not need convincing. That helps with my case to my senior leadership. The SIDs’ objects will be archived offline, we’ll get the space reduction we need. The difference is, we interacted extremely well with the user community.

Because, for a file share clean up project to be successful, you must listen closely to the customer. You must be a good, vocal partner with the focal point of each team to facilitate the work ahead.

As of this week, I’ve identified 68.25 percent of the objects as eligible for one of the following treatments: deduplication, deletion, destruction or the offline archive. And the good news is: there’s more work to do. 

Creative Commons Creative Commons Attribution 2.0 Generic License Title image by  JD Hancock