SharePoint Records Repository & In Place Records Thoughts Part 2

Following on from Part 1

Lets consider a simple example of in place v central records when it comes to aggregated content.

So imagine we have an image that will constitute a record at some point within it's lifecycle.
The sensible thing to do is create a content type for the image and define an appropriate information management policy etc.

So we are ready for the image to be published and viewed within our organisation. We may go through some approval or workflows and finally when all the business processes have been met, we declare it as a record....fine, that's the correct thing to do.

So we have a library containing our image content types and we use an image from the library in some content within our organisation - in this simple example we are using it within a publishing page layout.

So here's our image in all it's glory.

And here is our image content type in its document library.

So we now want to declare this as a record...fine.

In a central repository model we simple send to > records center and we are left with a nice link.
Great its now a record in our central repository.

And back to the home page.
Oh!!!!!

If we are using in place records management we can simple declare the record in situ.

And our image will not be removed.

Although this is a simple example it is an effective one.
Any content within your organisation is potentially a record, be it images, documents, etc etc.
As it is business content then it will probably come under the remit of some records management policy.

So when planning your records management architecture it is worth bearing in mind how you will aggregate any records-based content to other/all areas of your farm.

In place or central repository?
Plan, plan, plan !!!!!

SharePoint Event Receivers & Expiration Policy

More event receiver fun this week.

I've been writing some synchronous event receivers this week, one of which has been causing a headache, name ItemDeleting.

The event receiver acts correctly when users manually delete an item...great
The event receiver also acts correctly when a workflow deletes an item...great

If an item has an information management policy attached to it 'permanently delete' or 'move to recycle bin', the Expiration Policy timer job will kick in and delete the item.

BUT the event receiver will not be fired when the timer job executes!!!!!!

Cause : when the Expiration Policy timer job deletes an item it actually does an SPItem.SystemUpdate(); rather than SPItem.Update();


Worth bearing in mind if you need to capture an event driven from the Expiration policy timer job.

SharePoint Records Repository & In Place Records Thoughts Part 1

Something I've been thinking about for a while now and finally decided to get something on record (see what I did there).

Records management in SharePoint is an emotive subject and I'm not going to cover the rights and wrongs of RM implementation.

I have had many discussions on the implementation of SharePoint records management with regards to In Place Records and a Central Repository approach, and while I agree each has it merits, one thing that many people don't consider is what actually constitutes a record and how do we manage a record once we realise that it's not just about documents.

So firstly lets identify what a record actually is......

Records Management ISO defines records as:

Information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business.

ICA's definition of a record as:
recorded information produced or received in the initiation, conduct or completion of an institutional or individual activity and that comprises content, context and structure sufficient to provide evidence of the activity.

In both the above definitions a record is defined as a piece of information but for some reason we all
think of a record as a document or group of documents. e.g. word, pdf, cad, excel etc etc.

This is where the SharePoint content types really do come to the fore. As we all know a content type can be any piece of information within a farm.

So it's easy...lets create a content type for each piece of information (impractical but possible).

Lets take a scenario.

Great Corp have an intranet and like most intranets they have news on the homepage.

Now this news may be an announcement content type or a custom content type, but very rarely is it a document, but it is a record.

But hey that's fine we will create a Great Corp News content type and use that as our news information container.

We'll even put our records managers hat on and give it an information policy, auditing, expiration and a workflow.

See it's dead easy given the wonderful functionality that SharePoint gives us.

So now we can add the news, as a content type, to our homepage.

Ok so now lets imagine that this piece of news is important, in fact its vital and can be classed as a vital record.

It may be a safety related piece of news or something similar which has to be managed following our formal records management process.

So lets declare it as a record, it's the sensible thing to do.

Scenario 1 - In Place Records

We can declare the news item (vital record) as a record using in place records management.

The vital record news item is now locked and cannot be edited or changed, which is absolutely correct.

Scenario 2 - Central Records Repository

Ok so lets declare this news item as a record inside our central repository

Oh wait a minute, we can only send document based records to our central repository.

OK it's not the end of the world, we can use our content type information management policy, workflow or similar to move it to the records centre.

We will have to move it and leave a link. If we copy it we will have two identical records in two different places in our farm...not good!

Gotcha....although the information management policy will let us set this rule, you cannot transfer a non document derived content type to the records centre!!!!


In conclusion

I understand the reasons that many organisations want to use a central repository for all of their formal records. However you should consider the following:

• Much of your content within SharePoint will be list based and not necessarily document based.
• Your information architecture policy should reflect this and you should identify the information that will constitute a record, not just the documents
•  Declaration of records should take into consideration the limitations of a central repository without code and add-ons.

In part 2 I'll look at the technical issues that have to be overcome for central and in place records management....

SharePoint Foundation 2013 Search

It appears that the lightweight search (search server express) is included in SPF 2013 with some nice additional web parts in the results interface

It also includes the refinement webparts on the left - note the timeline slider bar...NICE!

SharePoint 2013 HTML Field Security

Another nice feature of SP2013 is the ability to restrict what contributors can embed in site pages.

Under site collection settings there is an entry for HTML field security.

We can dictate what domains are safe regarding embedded content

When a user tries to embed code in an editable region they will get the following error if the domain isn't set in the HTML field security

However, note that the error tells the user of an alternate way to embed the code using the embed command.

So now if the user chooses embed from the ribbon

It appears that the HTML security is bypassed!!!!!

Definitely one to watch, especially if this still appears in the RTM version

SharePoint 2013 - New Task Lists

The task lists appears to remain much the same in SP2013
However the user interface has changed somewhat!

We now have a timeline that appears above the task list.

We can also change the colours of the task list items, something that we had to use jQuery for in the past.

We can also choose whether to display a task on the timeline

Another nice touch is the ability to indent tasks so that the list resembles MS Project

And finally the ability to open with project and sync changes back to SharePoint

*This is taken from the preview version of SP2013 and may be subject to change!

SharePoint Solution Setup Package MSI

After a few more hours of head banging VS2010 setup projects I decided there has to be an easier way.
It doesn't help that the custom actions can only be dll, exe and vbs, or that the post build command interface is a bit lousy - when it works!

I was toying with the idea of running a vbs to call the powershell to install and uninstall a wsp file, but we are dealing with 64bit and vbscript calls to ps files don't play nice with 64bit!

So I did a little hunting around for a solution and found the wonderful PS2EXE on codeplex.

The plan was to convert my ps1 files to exe's and then have my msi project call them as exe's...straightforward you would think....perhaps.

So here's how I progressed :

1. Make sure you put full paths into your ps1 files - you can't use contextual paths as the installer runs in the system32 context.

2. Covert your ps1 files to exe's using the PS2EXE

3. Add your files into your VS setup project

4. Add your exe files created from PS2EXE into the custom actions sections

5. Make sure you mark your custom actions files as false for the installerclass

6. Ensure your target platform is set to 64bit

So when you run your setup.exe the final step of the install will execute your powershell files that have been converted to exe's.

Although this is probably not the best solution for some powershell files, its perfect for solutions (wsp's).

Hope this saves your msi frustrations!