SharePoint Archives

I’ve just signed up for a webinar that KnowledgeLake are holding entitled “Realizing True Records Management with Microsoft SharePoint 2010“.

KnowledgeLake were gold sponsors at the SharePoint Best Practices conference that I went to in London earlier this year, and, I have to say, it was a top-notch event. I had visited KnowledgeLake’s booth and I’m curious about how good their product actually is.

So, it was with interest that I read the “Reasons I should attend“. These included the following:

LEARN how records management on SharePoint 2010 can lower cost and risk through transparent application of compliance policies and consistent disposition of content
DISCOVER why SharePoint will succeed in records management where other ECM platforms have failed
WATCH the demonstration of a document lifecycle in SharePoint: the capturing of paper and electronic files including email, application of metadata and classification criteria, search, retrieval, viewing and application of record declaration
RECOGNISE how to outline an enterprise approach for the implementation of SharePoint 2010 records management
HEAR the customer case study by MOEITS and how they are using SharePoint. The solution saved the union nearly $1 million and realised a return from their investment in four months.
CONTRIBUTE to the Question and Answer session

Now, the first reason seems to be pretty standard when describing the virtues of any content management system. As is a demonstration, as well as hearing a customer case study..(Just change the name of the ECM system.)

What really grabbed me by the short and curlies was the second reason “Discover why SharePoint will succeed in records management where other ECM platforms have failed“. Now, this is interesting…I want to hear about this secret sauce that McSharePoint has.

Reason 4 is also one that got my attention. Here the phrase “enterprise approach” really stood out. I’ve been involved with SharePoint since 2007, and, coming from an ECM background, it was very evident to me that SharePoint 2010 is now being hawked as a bigger beast. And this is not only in the “functionality” of SharePoint 2010, but also in other ways. There are more “enterprise-level” whitepapers out now, and the official Microsoft SharePoint training is focusing more on the “business-side” rather than just pure technology.

I’ve registered for the webinar. I’ll be taking notes, and will try and report back on my findings.

Reference Links

Realizing True Records Management with Microsoft SharePoint 2010
KnowledgeLake
European SharePoint Best Practices Conference 2011

Killa Hertz & The Case of the Missing Documen...

The Search application is not available for (all t...

Post-move SharePoint site Comparison

Tips for creating Great PowerPoint slides

Is Microsoft a Religious Experience?

Killa Hertz & The Case of the Missing Documen...

How does FirstDoc “do” 21 CFR Part 11 ...

Case Study – A social Content Management sys...

Recently a friend of mine was working on creating a Document Management portal.

That is, he was using SharePoint as the user interface, and was populating the pages with web parts that would allow the user to interact with a back-end document management system.

He had built up the Portal using SharePoint 2007, and had created several sub-sites that contain web parts that were relevant to the requirements of specific groups of users. He had run some informal testing and had confirmed that the web parts were offering the business users the functionality that they required. He had also spent some time on the design of each page. He was using a standard master page so that each sub-site had the same look and feel, but had made small tweaks to each page so that the presentation of the web parts was optimal.

Then he wanted to move the system to a SharePoint 2010 system. Fortunately the Portal site was not yet in use, and nothing extra, or unknown, had been done to the sites, so was pretty sure there wasn’t any customization. However he wasn’t sure what the best way to get his Portal from 2007 to 2010. So he called me.

We had a look at the options:

In-place upgrade,
Database Attach
Build the site from scratch.

SharePoint 2010 had already been installed on a new, suitably spec’d server, so an in-place upgrade was not an option.

We examined the database attach method. This would involve making a backup of the 2007 content database, restoring it in the new SQL Server installation on the the new server, This sounded like a good option. The only thing we were worried about was the third-party we parts (the ones that hooked into the third-part document management system). We weren’t quite sure how these were going to respond.

We considered the third option – building the site from scratch on SP2010. This also introduced new challenges. Could we migrate the default. master from 2007 to 2010? I knew that 2010 didn’t use default.master, but now used v4.master. What impact would that have? We also had the ribbon to contend with, as well as the “Tags & Notes”, and “I like it” buttons. (The sites were meant to be static, offering only the ability of users to work with their documents. It was not meant to be a “social” site.)

One other benefit of an in-place, or database attach upgrade, was the fact that SharePoint 2010 offered a “Visual Upgrade”. That is, the 2007 look and feel is maintained, and there was the ability to “preview” how the sites would look in 2010. Once you were happy with them, you could make the changes permanent.

This would have been nice, but, because of the fact that we wanted to make sure that we could document how the Portal was built up, we decided that option 3 would be the best option.

So – the decision was made. The first step was to install the third-party web parts. And this is where it got interesting. We were using the latest version of these web parts that were SharePoint 2010 compatible, so we thought there would be no problem.

Except there was one small thing…

The third-party web parts were designed to use WSE. WSE, or Web Services Enhancements, is an add-on to the .NET framework that offers improvements to security and communication. It was released in 2005. The SharePoint server had been installed by another department according to a “standard”, and this included WCF, or Windows Communication Foundation. WCF was brought out as the “next-generation web service/interoperability framework”.

So here was the question: Do we get the department that installed the SharePoint server to uninstall WCF, and install WSE? Or do we ask the vendor to test, and certify that their web part technology will work with WCF?

Removing WCF and installing WSE would have very little impact to the overall scheme of things (the server was not being used for anything else), BUT it would mean a non standard installation.

On the other hand, the vendor has stated that their application was compatible with SP2010, and one would assume that it would be designed to use the newer WCF component.

Currently the discussion is going back and forth between the two options.

One thing though, this small compatibility issue wouldn’t have become quite so obvious if we had not decided to build up the Portal from scratch.

Related material: