SharePoint 2010 introduced managed metadata for the first time – the Managed Metadata Service (MMS). You can create a hierarchy of terms (metadata) and then use those terms to classify content stored in SharePoint. If you decide to rename a term, all items classified will be updated to reflect the new term. That’s the managed bit.

For an overview, please read an earlier blog post: SharePoint Managed Metadata Overview (Nov 2010)

Whilst the MMS is a great addition to SharePoint, it doesn’t cover all taxonomy requirements. This post will briefly explain the different types of taxonomy and what SharePoint can and can’t do to implement them.

The short version:

The SharePoint MMS can create taxonomies with a single hierarchy or multiple hierarchies using term sets. It can also be used for folksonomies by using a keywords list of tags. It can nearly do polyhierarchies, by reusing terms across term sets, but with limited uses.  If you have a deep taxonomy hierarchy to implement, you may need to add FAST to your SharePoint deployment.

The details:

Types of taxonomy

A taxonomy is a hierarchical form of classification. You define a hierarchy of metadata terms that can then be used to classify and describe stuff.

There are three main types of taxononomy:

• Single hierarchy
• Multiple hierarchies
• Polyhierarchies

And then there’s the informal rebel, the folksonomy.

Single Hierarchy

The simplest of taxonomies – a single hierarchy containing all the terms you plan to use. In this example, I’ve started with Flowers. That means the only things I’m going to classify are flowers. If I want more in a single hierarchy, then flowers would be a sub-class with a parent – e.g. plants, which may have a parent – organic material, that may have other sub-classes like mammals, which would have a sub-class for primates etc.  A single hierarchy is simple in theory but quickly becomes complex as you try to organise all possible terms.

Which is why, unless you are a library or garden centre, you end up with…

Multiple (Faceted) Hierarchies

In the digital world, we don’t need items to be located in only one place. We can use multiple hierarchies to describe them.  I might be looking for tulips. I might be looking for anything with red petals. I might want flowers that open earlier or later in the year for my garden.  Thanks to multiple hierarchies, I can find what I want without having to know where to look first.

Polyhierarchies

The most complex of taxonomies – a polyhierarchy is where a child or sub-class has two or more parents instead of just one.  Jasmine can be in the form of a shrub (small bush) or a vine (tall climbing plant).  Instead of being listed twice, the word is listed just once and linked to the two different parents.

Folksonomy

A folksonomy is the informal version of a taxonomy. It is simply the use of tags to describe objects. An object may have many tags. A tag may be reused for many objects.  There is no hierarchy – all tags are equal and there is no relationship between them.  You don’t define the tags first. You create them as you go. Once a person has created a tag, it’s added to the list.

A folksonomy can seem chaotic and confusing. Its success on the Internet, on sites such as Flickr, has been because it is a lot easier and quicker to simply tag items than have to select from a pre-defined hierarchy that may not match your vocabulary (imagine if plants were described using their Latin names).

SharePoint and Managed Metadata

SharePoint’s MMS can be used for both taxonomies and folksonomies.  Within Central Administration (and can also be accessed via Site Collection Administration) is the Term Store Management tool.

Keywords

SharePoint’s folksonomy is a group called Keywords:

When any item is tagged, either using the Enterprise Keywords column available in lists and libraries or by tagging site pages, the tag is added to the Keywords group (1. above).  As you start to type a tag, SharePoint will automatically suggest matching tags as you type (2.), to avoid having multiple spellings of the same word.  You can manage your keywords (3.) If you want to clear out unnecessary tags, you simply delete them.  If you also have a taxonomy, you can move popular keywords into the term set and make it part of a formal hierarchy. This is a great way to develop an effective taxonomy rather than a taxonomy filled with unused terms.

Term Sets

SharePoint uses term sets to create taxonomy hierarchies, with the following levels:

You create a group to contain one or more term sets.  A group with a single term set would be a single hierarchy. A group with multiple term sets would be a multiple or faceted hierarchy.

Within a term set, you create terms. Each term can itself have terms. In the image above, we have a group called Taxonomy Examples (created for this post). The term set is called Colours. The first level of terms contains Blue. Beneath blue is a second level of terms: Royal Blue, Cambridge Blue and Navy Blue.

Terms can be re-used across term sets, which sort of (but not quite) enables polyhierarchies.

In the image above (click on it to view in larger detail), I have a group called Plants. It contains term sets for Shrubs and Vines. The Shrubs term set contains a term called Jasmine. The term has been re-used and linked to the term set Vines.  If you look at the right side of the page,  displaying the term properties for Jasmine, in the box ‘Member of’ we can see the term is linked to two term sets. If I rename Jasmine, both term sets will be updated.

To create this polyhierarchy, the group Plants is the class, and the term sets are the first sub-classes. It has to be done this way because you cannot re-use a term within the same term set.  But this creates a challenge because only the built-in Enterprise Keywords column allows users to pick terms across groups and term sets. Managed Metadata columns have to point to a specific term set.

Whilst you cannot re-use a term in the same term set, there is nothing to stop you having duplicate terms, i.e. two or more terms with the same name. The downside is that you are creating extra terms, each with its own properties, which is extra work to manage and can be confusing for people.  But duplicates enable you to use a single term set that works better with the Managed Metadata column.

It’s probably easier to demonstrate:

The image above on the left is displaying the term store within the MMS. At 1. is the polyhierarchy example: A group for Plants with term sets for Shrubs and Vines, each linked to a single term, Jasmine (it has a slightly different icon to show it is linked to more than one term set).  At 2. I have created the alternative scenario, a single hierarchy with duplicate terms. This time, Plants is the term set with first-level terms for Shrubs and Vines. Each has a second-level term called Jas.

The MMS is used in two ways within SharePoint lists and libraries:

• Enable the built-in Enterprise Keywords column, which points to the entire term store (all groups and term sets).  It is always a mult-value field (people can enter one or more tags) and if the words entered are not already in a term set or the keywords group, they will be added to the keywords group. (Side note: the label ‘Enterprise Keywords’ can be confusing since it points to all groups in the MMS, not just the Keywords group).
• Create columns of the type ‘Managed Metadata’ which must be pointed to a single term set. However you can then specify if the column is to contain only a single value versus multiple values, and whether or not people can create and add their own tags or must choose from the list provided.

The top-right image is displaying the properties form for an item in a document library, with the built-in Enterprise Keywords column (3.) enabled. As I type in Jas, three suggestions are offered – Jas in the term set Plants, under the term Shrubs; the duplicate Jas in the same term set Plants, under the term Vines; and, Jasmine from the group Plants, displayed once but showing both term sets that it is linked to. In this image, the correct method would be to use the Polyhierarchy (from 1.) so that I can classify the document as about Jasmine, regardless that it is both a shrub and a vine.

The bottom-right image is displaying the properties for a Managed Metadata column (4.). When you create a column of the type Managed Metadata, you have to point it to a single term set.  This is where the polyhierarchy (1. in the image above) fails in SharePoint because I can’t point the column to the group Plants, I have to pick one of the term sets within the group, either Shrubs or Vines. I don’t want separate columns for each sub-class within plants. My alternative approach (2.) with duplicate values does work because Plants is the term set. But then how do I decide which Jas to pick to classify my document?

And there’s another gotcha.  One of the most useful reasons for implementing managed metadata is to refine search results.

The image above is displaying a standard SharePoint search results page. On the left side of the page are the search refiners.  I have two term sets listed – Department and Products.  Under Products, I can refine results by SharePoint, Content and Apps.  Here’s the rub. My term set hierarchy is as follows:

• Term set: Products
  • First-level term: SharePoint
    • Second-level term: Content
    • Second-level term: Apps

The standard search refiners in SharePoint do not display a hierarchy under the term set, it is simply Term Set as the heading, and all terms listed beneath, regardless of their position in the term set hierarchy.  A deep hierarchy within a term set does not work well with the standard search refiners, they are better suited to flat hierarchies – term set as the class with just one sub-class of terms.  In this example, I should either keep the term set Products but have just one level of terms – the product names (SharePoint, Office etc.) or make the product the term set if I want to classify by feature, e.g. term set: SharePoint, terms: Content, Apps etc.  The alternative is to upgrade my SharePoint deployment to include FAST, which is Microsoft’s advanced search and taxonomy tool. FAST includes the ability to configure your search refiners to match your taxonomy hierarchy.

In conclusion, the Managed Metadata Service enables you to create all three types of taxonomy: single hierarchy, multiple hierarchies and polyhierarchies, as well as the folksonomy of keyword tags.  However, you can only use all these methods with the built-in Enterprise Keywords column, which cannot be locked down if you want to restrict what words can be used to classify content.  The Managed Metadata column can be locked down but only works with a single hierarchy, meaning you either have a deep single hierarchy or have to create separate columns for each term set.  Search refiners work best with multiple (and flat) hierarchies, they do not work well with a single deep hierarchy.

To design the MMS effectively for search, you have three choices:

1. Flatten your taxonomy:

• Use multiple term sets, each with a list of terms – i.e the term set is the class, the terms are a single sub-class. Do not have a hierarchy deeper than that.
• If using the Managed Metadata column, you will need a column per term set.  Essential if you need to restrict people to picking from your defined lists of terms.  Aim for fewer term sets. This will likely mean not going to deep with your taxonomy (in my Plants example, I’d need to either drop the final level – Jasmine, or drop the sub-clases of shrubs vs vines vs flowers, and just have a term set of Plants with terms for the type: Tulips, Roses, Jasmine etc.
• Use the Enterprise Keywords column when you don’t mind people adding their own tags (will be added to the Keywords group). Matching terms will be suggested to help avoid unnecessary duplicates.

2. Upgrade your deployment to FAST

If your taxonomy is too important to flatten but you still want to use search refiners (you should, reasons for classifying content usually include making information easier to find), you need to consider whether or not to configure FAST in your SharePoint deployment.  FAST includes advanced search refiners that include displaying a deeper taxonomy hierarchy.  It also includes the ability to auto-classify. But may involve additional licenses so you need to factor the cost into your project.

3. Use a specialist add-on

The third option is to use an alternative (non-Microsoft) taxonomy solution that can be added to your SharePoint deployment.  You are likely to also require an auto-classification tool.

If you are immediately thinking that option 1 is not good enough for your taxonomy needs, before heading to the second or third option consider if your taxonomy is good enough for your organisation’s needs.  Folksonomies have succeeded where taxonomies have failed because of their ease of use.  It’s no use having a deep and detailed taxonomy hierarchy if people make mistakes, choose the defaults or just click the first in the list to get through classifying their information. And auto-classifiers are a long way from perfect.

No metadata is better than bad metadata.

Related blog posts

• SharePoint Managed Metadata Overview

One TechNet article I’m always dipping into for reminders when designing SharePoint solutions is the capacity management article defining boundaries, thresholds and supported limits for sites, lists and libraries. For the full article, read SharePoint 2010 Capacity Management: Software boundaries and limits (at time of writing, updated 14 July 2011 following changes introduced with Service Pack 1).

First up, Microsoft definitions:

• Boundary = static limit that cannot be exceeded by design
• Threshold = configurable limit that can be exceeded to accommodate specific requirements
• Supported = Configurable limits that have been set by default to a tested value.

Second, there have been a lot of changes introduced following Service Pack 1 released in June. The last major update to the software boundaries and limits was September 2010.  These tables have been updated to reflect the changes.

What follows is my summary and additional notes with references at the end. Some items are in a different order to the key reference as I’ve organised by layer – web app – content DB – site collection – site – list/library – page followed by some of the key services. Note: When a Max.Value has an asterisk next to it, that usually means you’ll never (or shouldn’t, IMHO) get close to it…

Farms and Web Applications

Content Databases and Site Collections

Lists and Libraries, Documents and Pages

Column Limits (Large Lists)

When designing large lists or libraries, consider the following. SharePoint 2010 supports SQL row-wrapping and can wrap up to 6 times (means one item actually occupies 6 rows instead of 1).  The maximum size per row is 8,000 bytes, with 256 reserved for built-in columns, which means the total number of user columns must not exceed 7744 bytes, regardless of how many row-wraps are used.

All the following values are Threshold limits.

External data column typically have a primary column (text field); hidden ID column (multi-line text) and secondary columns (text, number, Boolean or multi-line) based on the data types defined in the BDC.

Tips include creating and using an index to organise a large list – allows filtered views and faster results.

Security

The short version: keep tidy via Active Directory. Put users into Active Directory (AD) groups, put AD groups into SharePoint groups. Don’t forget, you can’t add Sharepoint groups to SharePoint groups.

Search

User Profiles

Blogs

What	Max Value	Limit Type	Notes
Blog posts	5,000 per site	Supported	Won’t be using SharePoint for busy blog sites then… Plenty of other reasons not to. For large and public blog sites, using a dedicated tool like WordPress (what this post is being written on)
Comments	1,000 per site	Supported	Techcrunch definitely couldn’t run their site on SharePoint…

Business Connectivity Services

Workflow

Managed Metadata

PerformancePoint

SharePoint Workspace (formerly known as Groove)

Project Server

.

Related Blog Posts

• SharePoint Sizing pt 1 – Servers
• SharePoint Sizing pt 2 – Databases

References

• SharePoint 2010 Software boundaries and limits – TechNet
• Designing large lists and maximising performance – TechNet
• Data storage changes for SharePoint 2010 (post Service Pack 1) – SharePoint Team Blog
• Techniques for managing large lists – SharePoint help, Microsoft.com
• Managing large lists in SharePoint for users and site admins – Joel Oleson

This post is filed in the Architecture & Planning section of the SharePoint 2010 Handbook on this site.

SharePoint 2010 includes service applications for managing information that traditionally has been stuck in spreadsheets. The challenge can be choosing which tool best fits your needs. Here’s a rough guide, based on only editing and viewing data in a web browser. From the user’s perspective, no Office client required…

…however, first a licensing note. SharePoint Lists are available in all versions of SharePoint 2010. Excel Web App is available for all versions of SharePoint 2010 but requires Office 2010 licenses to use (you don’t need the software, just the license). InfoPath Forms Services, Access Services and Excel Services all require SharePoint 2010 Enterprise Edition.

Second: This post is just covering services to store and manage structured or semi-structured data typically found in Office . It’s not covering the analytics side, i.e. PerformancePoint and Excel Services, and it’s not covering integrated application features, i.e. Business Connectivity Services or External Lists.

And off we go…

The short version:

• Use SharePoint lists for simple applications with not toooo many columns
• Use InfoPath web forms if you’re creating a lot of columns of the type ‘Multiple Lines’…
• Use Excel Web Apps, if you’re licensed, if you are trying to make a list behave just like a spreadsheet. You know you’re going to need Freeze Panes at some point…
• Use Access Services if you’re creating a lot of columns, need more functions to calculate, more queries to filter and more items to view than a list can possibly handle… and you’re on a budget that excludes more expensive alternatives

Now for a bit more info:

*
Note this refers to the Excel web application that displays the full Excel spreadsheet, not Excel web parts that display a named range of data from a spreadsheet.

Table explanation: X = requirement can be met by the feature.  / = sort of, but another feature can do more or better.  – = not applicable (Excel Web App doesn’t use views to display content). Blank = no, requirement cannot be met by the feature.

Lists

Easiest to use and most common choice for replacing spreadsheets for managing information. Don’t forget lists include calendars, tasks, links, contacts etc.  You can create calculated columns using common functions from Excel, including ‘If’ statements. And you can have multiple different views to manage the data. Different people can edit the list at the same time provided they are editing different items. And finally, if there’s a process involved, you can integrate a workflow to manage the data.

The limits:

• You can only have so many columns before lists become unusable. You have a single form for editing individual items and all columns will be displayed on it. You can use Datasheet views instead to display a limited set of columns. But note: Datasheet views won’t work for any columns containing Managed Metadata, they will be read only.
• According to Microsoft capacity planning guidelines, you can store up to 30,000,000 items in a list. However all views must return less than 5,000 items. And in reality, the number is often far lower before performance degrades.

InfoPath

InfoPath is used to create forms containing semi-structured data, i.e a mix of numbers, calculations, and large clumps of text. The sort of files that could have been created in either Excel or Word because neither really fits the purpose.  With InfoPath you can create web forms for people to fill in and automatically submit to a SharePoint library. You can have multiple views within the form and control which view is displayed when a user opens the form. And you can choose to promote certain properties into SharePoint columns for quick access without opening the full form.

Pros:

• Managing semi-structured data, including lots of text.
• Integrated workflows to manage updates to the form

Cons:

• You can only edit one item in a web form. If you need to edit lots of items at once, you are unlikely to be including lots of text and InfoPath wouldn’t be the right tool.
• The same Microsoft capacity planning guidelines for lists also apply to InfoPath forms libraries

Excel Web App

With SharePoint Server 2010, you can integrate Office Web Applications. They are similar, but not quite twinned, with the Office Web Apps available with Windows Live Online.  You store the spreadsheet in a SharePoint library and open it in the browser instead of the full Excel desktop client.  You don’t get full Excel functionality but it should be more than sufficient for editing content.  Excel trumps lists in that you can use that popular feature – Freeze Panes – to scroll across lots of columns without forgetting which item you are viewing.

Pros:

• Freeze panes
• Bigger range of functions for calculations
• Excel data visualisations can provide dashboard-style analytics

Limits

• In the web-browser, only one person can edit the entire spreadsheet at a time.
• Creating views is a manual effort, it is still just a spreadsheet.

Haven’t found a definitive answer as to how large an Excel spreadsheet can grow and still be opened in the browser.

Access

Access, that client database tool loved by users and loathed by IT usually in roughly equal proportions, has joined the world of SharePoint. You can now create web databases in Access and publish them as a SharePoint site. Forms and reports can be edited and analysed using just a web browser.

Pros:

• You can go column-crazy and choose how many appear in the different forms available within Access, including single item view, multiple items and datasheet views <- side note: lists use Access Services built-in, even in SharePoint 2010 Foundation, to display datasheet views.
• Whilst you don’t get workflow integrated, the query capability offers much more compared to configuring list views enabling different forms to be used for different stages of data update. (You just can’t email reminders automatically when data needs updating).
• Increased capacity compared to lists. Lists can store 30 million items and still be supported but no more than 5,000 items will be displayed in any view. There is no defined limit to the number of records that can be stored in an Access web database, the default is 500,000. But Access queries can contain up to 200,000 items, with a default value of 50,000. But don’t get too excited – see performance note below.
• Better option than Access client databases in networked mode. Access Services in SharePoint uses far better caching mechanisms to lock/unlock items and you don’t need to compact every 5 minutes.

Limits

• Less flexible permissions compared to lists. With lists, you can set permissions per site, list and item. With Access Services, you set permissions per site only.  You can lock columns to read-only in forms but everyone is affected. There’s no concept of a ‘super’ user from the content perspective. Changes to the database schema can only be made by people with Full Control or Design permissions to the site.  And anyone who can view the site can open it in Access 2010 if they have Access installed on their computer. And they can export the table contents to Excel…
• Consider it a replacement only for lists, spreadsheets and simple databases. Lots of limited functionality, such as not being able to do table joins, you have to use field lookups instead (DBAs may howl). Queries can only get so complex and you may resort to doing calculated columns within the table (DBAs – don’t bother howling, it’s no different to a calculated column in a SharePoint list – which is what the table becomes when it is published to SharePoint).

Whilst scale is way beyond SharePoint lists, it’s nowhere near fully-fledged databases (SQL or NoSQL) with web front-ends. The challenge is that it can do enough for users that they inevitably want that other 20% of requirements you said no to.

From a performance perspective, users will experience a significant delay (more than 10 seconds) waiting for a form or report to open if the underlying table or query contains more than 1,000 items. Possibly less – it’s comparable to the delay opening a normal SharePoint list of equivalent size.  The difference is that the delay is due to caching in the background. Once the form opens, editing and filtering is nearly as quick as if working in the full Access client, even if the form contains 10,000+ items. This is where it trumps lists.  If you’re displaying more than 1,000 items, aim for fewer forms and use the Datasheet form which enables filtering without refreshing the query – in effect, you’re viewing a list but without the limit of 5,000 items. May publish more guidelines in a separate blog post.

And there you have it, a rough guide to the different ways you can store and manage data in SharePoint.

References

• SharePoint Editions comparison – Microsoft
• Capacity Planning Guidelines – blog post to be published

Not a million of references for this one, most is based on experience tinkering with SharePoint over the past 12 years. It’s come a long way from that document management add-on to Exchange I first saw in 1999

In February 2011 I did a presentation at a Records Management (RM) seminar on SharePoint 2010. Specifically, exploring what SharePoint 2010 has to offer in the field of EDRMS – Electronic Document and Records Management.

The presentation is embedded below and a brief summary of the talk follows:

First things first. SharePoint is not a dedicated RM solution. It is a platform targeting a range of different information and knowledge-type solutions. That influences what RM features do and don’t get included. If you’re wondering about the cars in the slides. One’s a Freelander – an all purpose 4-wheel drive that can be driven on and off the road. One is a Defender – it’s designed for off-roading. You can drive it on the road, but wear padded underwear. If you want one car to go on and off the road (off intentionally, not by crashing), then get the Freelander. If you want the best off-roader, get the Defender but you might want to buy another car for driving up and down the motorway, especially up (I had an ‘experience’ that involved a Defender going up the M6 in the Lake District at under 5 miles per hour).

Features

SharePoint 2010 has had quite a positive bump in features that help with records management. A sampling:

• Managed Metadata Service – brand new feature that lets you define and manage a hierarchical taxonomy centrally and apply changes automatically across all site collections. Big time saver if you need to redefine metadata. Also great for improving search through refiners. Plenty of gotchas too – it is a v1 feature. See references at the end for a related blog post.
• Content Type Syndication – Content types were first introduced in SharePoint 2007 but were limited to the site collection, i.e. if you have multiple site collections you had to redefine the content types for each one. You now have the ability to syndicate content types – create them in one site collection, then publish across all web applications and site collections via the shiny new Managed Metadata Service. Another big time saver and enables more consistent application of information management such as classification (metadata columns) and retention settings.
• Multi-stage retention settings within information management policies, e.g. review this doc annually for 6 years, after 6 years move it to the archive.
• Built-in workflow now includes a ‘Declare as record’ action.
• Document IDs – another new feature, gives documents a permanent URL or permalink. Means if you move them around SharePoint, they can still be found and embedded links won’t break.
• Document Sets – another new feature and can take a bit of explaining. It’s technically a content type, which can be confusing because it can also contain content types… In short, think of it like a lever-arch file containing lots of papers. The papers – documents – can each have their own metadata and retention requirements. But they can now also be managed as a set. The file – Document set – can also have its own metadata and retention. When time’s up and the file is to be archived, everything within the file is also archived.
• The RM Centre (or Center if you’re in the US) – first introduced in SharePoint 2007, it now has a Content Organiser to automatically route documents to libraries. Documents can be uploaded manually or automatically via workflow and are routed based on content types (content types crop up a lot in SharePoint 2010…)
• In-place RM – a new approach, you can now declare records in-place within collaborative team sites instead of routing to a central records management centre. Could have a whole debate on the pros and cons, there’s a slide summarising towards the end of the presentation.
• There’s a nifty new feature that has nothing much to do with SharePoint and everything to do with Windows Server 2008 – the File Server Resource Manager where you can define properties and set rules to automatically classify documents using the defined properties.  Worthy of a separate blog post.

Scale

SharePoint has always struggled with scale. It’s recommended that site collections grow no larger than 100GB. Depending on your average document size, penchant for metadata and keeping version history, that equates to roughly 200,000 documents per site collection.

However, that limit now only applies to collaborative sites, i.e. where documents are frequently being updated. If you are using centralised sites purely to manage records and archives, i.e. the documents are no longer updated, Microsoft now supports Content Databases (that hold the site collections) growing to 1TB. That could mean up to 1 million documents per site collection. There are some criteria – it must be a single site within a single site collection given a dedicated content database. And all the usual backup/restore arguments hold. Snapshotting is a good approach to managing this sort of size.

Another level of scale is that you can now have multiple records management centres (previously there could be only one). If you have 5 records management centres, you could now be storing up to 10 million documents. However, beyond that size – 5TB – you may want to consider a different approach. SQL Server 2008 includes Remote Blob Storage – placing files direct on the file server instead of within the database. This approach is recommended if you need to store more than 5TB of content but does mean a more complicated backup/restore procedure – you now have two different stores to keep backed up in sync.

Cloud

Another subject that probably warrants a dedicated blog post. Microsoft has been positioning SharePoint in both camps – on-premise or online using Microsoft’s datacenters. However, most companies requirements are not a simple either/or choice.  It’s no different to other departments within the organisation. Why have employees? Contractors would be cheaper and enable more efficient and flexible use of resources – scale up/down on demand.  The reality is most organisations have a mix. Hybrid cloud solutions are far more likely.

Decisions

If you’re planning on just using SharePoint for records management, there’s still a fair bit of work to do before you should even consider installing the technology. The first decision is whether to go for a centralised store versus in-place records management.

There are plenty of reasons to need more than just SharePoint. e.g. Cross-platform requirements – Microsoft products tend to play nicer with siblings than with others in the playground.  More in-depth feature requirements – such as Outlook integration, partners have built add-ons to the basic offering provided by SharePoint. Hybrid on-premise/outsourced/online systems = partners. And if you want to jump start your deployment with pre-defined settings, partners again will come to the rescue.

But most important of all, regardless of technology or technologies, there’s a lot of prep work to complete before you start playing with the toys.

And a final note that was added to the presentation following discussion during the event. The records management-specific features are targeting traditional records management, i.e. documents organisations are legally required to keep for a specific period of time.  We are seeing records management evolve to cover all types of information that may be consider legally admissible in court. That’s a very different definition. I see organisations trying to deploy the former whilst using the latter definition that stretches waaaay beyond documents. A simple example – financial and tax documents have to be kept for 6 years. If you are required to present one in court during those 6 years, you’re in trouble if you can’t. However, if a legal case begins in the 7th year, you can say you have deleted the documents. That’s fine, as long as you really have… One of the best comments from the event came from the Information Commissioner’s Office (ICO) which has been handing out a fair few fines in relation to failing to adequately protect documents:

It’s time people started culling documents they are not required to keep

Amen to that. By keeping everything, organisations are struggling to properly manage anything…

Related blog posts:

• SharePoint Managed Metadata Overview
• Introduction to Content Types
• SharePoint Capacity Planning – Sizing databases

One of the new features with SharePoint 2010 is the option to add-on FAST for advanced indexing and search capabilities. The short presentation below gives an idea of the extras you get with FAST versus just using SharePoint. The focus is on internal indexing/search solutions. FAST offers a lot more over SharePoint for use with public facing web sites but that’s a whole other scenario.

The presentation below contains a walkthrough the basics of what are content types in SharePoint 2010 and what’s new. Enjoy!

Additional notes…

How to set-up Content Type Syndication Hubs

• Create a site collection to host the hub. (I create a standard one for all admin-y stuff – http://servername/sites/admin/
• At the root of the site collection, go into Site Settings | Site Collection Features and activate ‘Content Type Syndication Hub’
• Go to Central Admin | Manage Service Applications
• Select the Managed Metadata Service (not the connection and don’t click the URL, select by clicking to the side of it)
• Click on Properties in the ribbon and enter the URL for the syndication hub (http://servername/sites/admin/ and click OK
• Select the Managed Metadata Service Connector
• Click on Properties in the ribbon and check the box next to ‘Consumes content types from the…. (should show the URL)
• To see images showing the above steps, visit Setting up Content Type Syndication Hubs – Furuknap’s blog, Dec 09