Hi everyone
We have and are continuing to grow a SharePoint 2010 environment to manage
our electronic records across our (not for profit) organisation with 7,500
employees across the State. Our environment includes four main web
applications: team sites, project sites, publication sites, and app sites.
We are also using the platform to build our new intranet on a separate web
application.
For most of 2012, we considered the Records Center (an app site) a key
element in the design. We then discovered some interesting issues with the
Records Center that led us to re-consider its use. I have written about
these issues in my blog here:
http://andrewwarland.wordpress.com/2013/03/27/sharepoint-2010-send-to-records-center-centre/
The following is an extract from the blog post describing the issues we
found:
- Versioning. If versioning has been applied to the document library, and
versions exist, only the most current version will appear in the Records
Center. 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
Center.
- 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 Center.
We also looked at the ability to apply retention periods to sites and
sub-sites in SharePoint 2013. I blogged about that too:
http://andrewwarland.wordpress.com/2013/05/18/sharepoint-2013-site-disposal-policies/
This suits project sites really well, and we already have several that we
will apply those retention policies too once we upgrade. A great thing
about being apply to apply it to project sites is that we get ALL the
various content that the project team created, including documents, lists,
calendars, pictures etc. Moving just the documents to an archive location
would mean we would lose all that additional rich content.
As we have no more than one and a half years of content currently stored in
our SharePoint environment, we decided to wait until we implemented
SharePoint 2013 rather than to try to work through the Records Center
issues.
We are looking at using the Records Center to 'archive' (as in, move)
electronic records currently stored in network shares, then delete them
from those shares. This will allow us to apply retention policies to those
records in the Record Center, something that is not possible on the drives.
We may also create separate Records Centers to store specific types of
records - for example HR records.
One very important consideration to keep in mind are storage limits in
SharePoint sites. These are documented here:
http://technet.microsoft.com/en-us/library/cc262787(office.14).aspx
If you are to use a Records Center keep in mind the following limits, taken
from the above URL:
- Less than 5% of the content in the content database is accessed each
month on average, and less than 1% of content is modified or written each
month on average.
- Do not use alerts, workflows, link fix-ups, or item level security on any
SharePoint Server 2010 objects in the content database.
Often the difficulty for records managers faced with SharePoint is a lack
of knowledge about how it works from a 'back-end' perspective. The more you
can learn the better you will be able to decide the best configuration for
your requirements.
Andrew Warland
Sydney, Australia
On Thu, Oct 31, 2013 at 3:31 AM, Mangiaracina, Ann <[log in to unmask]
> wrote:
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
