Posted in Electronic records, Products and applications, Records management, Retention and disposal, Sharepoint 2010, SharePoint 2013

SharePoint 2010 – Send to Records Center / Centre

SharePoint 2010 includes the option to send a document from the site where it was stored to the Records Center (Records Centre in Australia), and other locations. The option is set at the Central Administration Web site under General Applications – Configure Send to Connections. See http://technet.microsoft.com/en-us/library/ee424395(v=office.14).aspx for the details of how to configure this option.

The ‘Send to action’ list offers three options when a document is sent to the Records Centre (options which are then available across the farm):

  • Copy the document (which simply makes a copy)
  • Move the document (which appears to remove the document entirely. Microsoft state that ‘users will no longer be able to access the document from its original location’, suggesting it is not actually deleted from the original location)
  • Move and leave a link (see below)

Microsoft state (in the link above) that this option will ‘… delete the document from its current location, move it to the destination repository, and leave a link at the current location indicating that the document has been moved’. If Document IDs have been enabled, the Document ID will disappear next to the document icon, which then shows a hyperlink ‘hook’ to the document in the Records Centre. A user clicking on that link will be advised that the document has been moved.

The impact of versioning, and metadata, on ‘Send to’ moves

There are a number of issues, and potential problems, with the ‘Send to ‘ move option that need to be understood. Some of these might be sufficient to decide against using the Send to Records Centre option (or even using the Records Centre).

  • Versioning. If versioning has been applied to the document library, and versions exist, only the most current version will appear in the Records Centre. The Document ID will be the same as the current version. However, any previous versions remain in the original library. In one sense, it is good to show previous versions, however any of these previous versions can be restored. When this happens, the version that is restored now appears, with the original document number (and a ‘hook’ still on the icon). The logic of this appears to be that, if a previous version is restored, the version that has been sent to the Records Centre is no longer the current version. However, it remains – with the same Document ID – in the Records Centre.
  • Metadata. Any additional, local metadata that has been added to the Content Type in the original Site Library will disappear when the document is moved. Metadata in Content Types stored in the Content Type Hub will remain.
  • Created date. The ‘Date Created’ field in SharePoint is the date the document was created in SharePoint. When the document is sent to the Records Centre, it is assigned a new ‘Date Created’. The date created field on the original document remains unchanged.
  • Permissions. Any permissions that may have been applied to the document, via inheritance from the Library or Site, are removed and the document inherits the permissions of the relevant library in the Records Centre.

The implications for ‘Send to Records Centre’

The issues documented above could affect planning and decision making regarding use of the Records Centre and the ‘Send to’ functionality. Some issues to consider include:

  • Loss of versions when the document is moved
  • Ability to restore a previous version (and confusion about which is the current version)
  • Loss of metadata applied locally to content types
  • Changes to access permissions

If any of these are concerns for the organisation, consideration might be given to leaving documents in place where they were stored and managing them in that way. The Record Centre could instead be used to archive and apply retention policies to content from network drives.

Posted in Access controls, Electronic records, Governance, Information Management, Products and applications, Sharepoint 2010

Understanding and managing access permissions in SharePoint 2010

By default, access permissions are set at the Site Collection level and then inherited downwards, to all libraries (and document sets), lists and documents on the main page and to all subsites and their libraries (and document sets), lists, and documents.

The default permissions are usually:

  • Site Owner (full control of the site)
  • Site Members (can add and edit)
  • Site Visitors (can view only)

Breaking the inheritance model of access permissions is relatively simple to do but can create confusion and, if not done correctly, make content completely inaccessible even to the Site Owner. Breaking the inheritance model on documents is particularly dangerous as there is no easy way to identify or manage access restrictions applied across the farm.

Simple access controls via de-inheritance

The simplest way to limit access to a site or the content on a site is to de-inherit the access permissions. To change this on:

  • Sites, go to Site Actions – Site Permissions
  • Libraries/Lists, go to Library/List – Library/List Permissions
  • Document Sets or documents, click on the down arrow next to the name and click on Manage Permissions

… then choose ‘Stop Inheriting Permissions’. If that option is not there, then the Site, Library/List, Document Set or Document may already have permissions on it. (You may see the following statement: ‘Some content on this site has unique permissions which are not controlled from this page. Show me uniquely secured content’).

But there’s a catch, creating the first layer of confusion. When you stop inheriting permissions, the same permission groups remain on the page. But didn’t you just STOP inheriting those permissions?

The reason I think Microsoft left the default permission groups there is so you don’t inadvertently lock yourself out of the Site, Library/List, Document Set or Document – if no group is left and you navigate away from that page, you will almost certainly be denied access. The really good thing to note is that, if you have realised you are about to make something inaccessible (and before you navigate away), you can click on ‘Inherit Permissions’.

So, after you stop inherited permissions the next things you need to do are (a) remove any groups you no longer want to access the site, and then (b) add or create a group you want to access the site. To do that, you click on ‘Grant Permissions’. The dialogue box that appears asks you to select users or groups, and then grant the specific permissions. A group must exist to add it and these are added at the Site Collection or Site Level.

Note that a created group does not on its own have specific permissions, it is only a group of names. You create the permissions when you give that group access to the site, library/list, document set, or document. If you have a group already, you can add new names to that group.

I’d recommend you create a group at the Site Collection level because it will appear there anyway and you need to understand what impact that has – any new group you create will have access to anywhere else in the site by default UNLESS you break the inheritance model.

Slightly complex access controls via de-inheritance and groups

The most common use case for slightly complex access controls are at the library/list, document set or document levels. That is, there is a business requirement to restrict access to one of those, or provide access to a specific document set and nothing else. For the sake of this posting, we will consider the case of a library, in a second level sub-site, that contains multiple document sets, each with multiple documents. The business area wants to restrict access to one of the document sets to a specific group of people.

This is where you need to exercise great care as, without careful planning, you could inadvertently allow all the members of that group to access anything else across the entire site collection where access is inherited. This is because, when you create an access group, the group will appear across the entire site collection.

To allow access to a document set only within a site collection (and assuming there are multiple sub-sites each of which inherit from the top level), you need to first understand access permissions already set.

First, break inheritance on all sub-sites; by default this will leave the default groups plus the new one you have created, so you you only need to remove that new group on all sub-site access permissions. This will remove the new group from all libraries/lists, document sets and documents on each site.

Second, you need to add the group to the specific document set. To do that, stop inheriting the permissions, which leaves the default access permissions, then add the new group by clicking on Grant Permissions.

Now, if you go to the site permissions, you will see the new group listed (which can be a bit disconcerting), and the statement (against a yellow background): ‘Some content on this site has unique permissions which are not controlled from this page. Show me uniquely secured content’.

What this means is that members of the group you have added:

  • Cannot access the site, or site collection (they will get an ‘Access Denied’ message).
  • Can see the document set they have been given access to (but no other document set or document in the same library)
  • Can see the site’s libraries and lists but cannot see any content in those lists. This is a good reason for being careful about naming those libraries.

As noted already, access permissions can be very difficult to manage and very easy to get wrong. Careful planning will help to ensure you don’t lock yourself out.