The SharePoint team has teamed up with WAND, a leading provider of Enterprise Taxonomies, to provide a starting point and make their General Business Taxonomy available as a freely available download. The General Business Taxonomy consists of common functional areas that exist in most businesses. The General Business Taxonomy can be imported in to the SharePoint 2010 term store within minutes and provides a great starting point for customers looking to build out term sets and take advantage of the Managed Metadata Service. In addition to this freely available download, WAND provide a range of taxonomies covering a variety of domains including Products and Services, Jobs, Skills, Medical, Finance, Records Retention, Legal, Insurance, Manufacturing, Information Technology, and Mining

Download the General Business Taxonomy today and start to explore the benefits that taxonomy can bring to your business and your people.

If you’re new to taxonomy and the benefits it can bring to your business, take a look at the following sites:

• TechNet – Managed Metadata and Taxonomy Resource Center
• WAND Inc. Website
• WAND Blog

Document sets are similar to folders, but when you access a document set you get a web part page that can be customized. When you upload documents to a document set they are displayed in a web part that works just like a document library view. Several document set features make it faster and easier to work on projects of related documents. Here are a few of these features:

• Shared metadata enforces the same metadata on all items inside the document set
• Default documents can be automatically provisioned when a document set is created
• A web part page called the welcome page displays the contents of the document set and can also be customized to display more information than just documents

Document sets fit in with our overall document management vision by helping manage the unmanaged and bringing collaboration and metadata into document creation and management. Document sets can be used to organize and find content and they make it easy to group and relate documents. Document sets encourage using columns for metadata on the document set itself and the documents within. Shared columns put document set metadata on all of the documents inside and it is useful to display the properties of the document set on the document set welcome page. Document sets make it faster and easier to work on groups of related documents, saving time and money.

We built document sets based on scenarios that we saw both internally at Microsoft and from our customers. For example on the Office team we organize the parts of the products we build into features and each feature has a team that works on it. These features have specifications, development plans, and test plans. Document sets make it easier to create the necessary documents and manage a collection of documents for a feature.

We also saw customers with similar scenarios, such as sales proposals that require presentations, spreadsheets, and sales contracts. Rather than manage each item individually, in these cases there may be metadata that should be shared and workflow processes that should happen on the collection of items. We expect partners and customers to take document sets and customize them for specific vertical scenarios to support important processes such as managing cases and research projects.

Now that I have given a quick intro into what document sets can be used for, allow me to give an overview of the main features of document sets.

Welcome Page

When you go to a document set you will notice that it isn't your typical folder view. Document sets have a customizable welcome page. By default this page has a document set properties web part. From the document set settings page of the content type you can specify which document set columns show up in this web part. There is also a Document Set Contents web part which displays the documents that have been added to the Document Set.

This is an example of a non-customized document set welcome page with a few documents.

This is an example of a customized welcome page that has had the image changed and a note board added. The welcome page is shared by all document sets of a particular content type in a list so any changes will be reflected for all instances. This makes it fast and easy to make changes to the welcome page because the updates will be instantly available to existing document sets.

Allowed Content Types

You can select the content types that are available to the document set, allowing you to control the types of content that are available to be used inside the document set. 

Default Content

Documents can be specified to be automatically created when a new document set is created. Default documents can be specified, allowing you to control the templates people use for a document set. This saves the time of having to find and upload templates to get started with. Of course users can still upload their own documents to a document set as well.

Shared Columns

Document set columns can be shared to all the documents inside the document set. This will make the column read only so the value can only be changed by editing the properties of a document set. This saves users time because they only need to update metadata in one place and it will then be updated on all documents inside the document set. It also helps ensure that metadata is consistent. You can use shared columns to make sure all of the documents have certain metadata.

Send To

Send To locations that have been specified in Central Administration will be available to document sets so you can send them to a configured content organizer. You can also use workflow actions to send document sets to a content organizer. The content organizer is a new SharePoint 2010 feature for moving content based on metadata to folders, libraries, or other sites.

Customizable Ribbon

One of the major improvements with SharePoint 2010 is the ribbon interface that is similar to the ribbon interface used in the Office client applications. Document sets have their own ribbon to perform actions such as send to, delete, and capturing versions. This ribbon can also be customized to add new commands.

Versioning

Document sets have their own versioning that is used to capture a snapshot of checked in versions of documents and the properties of the document set.

Workflow

Document sets support workflows on a collection of documents. Several workflow actions specific to the document set are available in SharePoint Designer including capture a version and start an approval process.

Summary

Document sets are a great way to organize related documents for project based work. They provide a customizable and collaborative environment that you can use to meet the needs of multi document work products. They are also a central information architecture component that can be used to represent concepts such as research notebooks, sales proposals, and product specifications. Document sets make it easier to automatically provision templates, collaborate on a group of documents, and share information about documents (such as metadata properties).

Be sure to subscribe to the ECM blog RSS feed and keep reading the blog. I will be posting more blog posts about document sets where I will cover creating a custom document set content type and customizing the welcome page.

Quentin Christensen

Program Manager, Document and Records Management

Configuring Policy

The Information Management Policy settings page can be accessed by going to the site content types gallery, selecting a content type, and clicking on the Information management policy settings link. On the settings page you can fill in an administrative description, this is what is displayed to administrators when configuring policies. A policy statement can also be displayed, this is what will be shown to end users for example when they open a Word document they will get an information bar. There are for categories of policy: retention, auditing, barcodes, and labels. Retention allows you to specify actions that occur after a certain date. Auditing gives you options to select of operations to items that will be tracked. Barcodes and labels can be used to track documents.

Retention Actions

The retention actions include:

· Move to recycle bin

· Permanently delete

· Transfer to another location – You can select from configured Send To locations that will send the document to a content organizer

· Start a workflow – select from available workflows that are associated with the content type (or list in the case of location based policy)

· Skip to next stage

· Declare record – this will mark the item a record using the new in place records feature. At the site collection level you can specify whether a record should be treated as a normal item, block delete, or block edit and delete. In order to use this action the In Place Records site collection feature must be activated.

· Delete previous drafts

· Delete all versions

In the events section you will notice that you can select columns, and there is a disabled option to set a custom retention formula. This option is available if a custom retention formula has been installed on the server. You can check out the article Creating a Custom Expiration Formula Based on Metadata in SharePoint Server for more information about creation a custom retention formula.

Content Type Based and Location Based Retention

With SharePoint Server 2010 you can configure content type or location based retention. Content type based retention lets you specify that all items of a particular content type will follow a retention schedule. To specify a retention stage go to the information management policy settings page, which can be accessed from the main settings page for a content type. From there you can click on the enable button for retention and add new stages. It is important to note that pages, blogs, and wikis are content types that can have policy as well as documents.

Retention can also be specified by library and folder. To do this navigate to the list you would like to configure retention for, go to the list settings page and then click the link for information management policy settings. By default items will follow content type based retention. To change the retention schedule source click the change source link. Now all items in this list will follow the retention schedule that is specified for this list, rather than whatever is specified for the content type. To the left of the screen there is a tree control that can be used to navigate the folders in the list. You can use this control to select different folders to specify a retention schedule for that particular folder and all folders beneath it.

Folders inherit location policy from their parent. At the list level I can set a retention schedule for all items to expire 5 years after created date. All items in the list will receive then expire after 5 years. For the Confidential folder I need to retain items for 7 years, so now any items inside the confidential folder (including any new folders) will now expire at 7 years.

You can also set multi stage retention schedules. Let’s say that after a document has not been modified for more than 90 days previous versions will not be needed, so to save space I want all previous drafts to be deleted (because each version takes is the full size of the document, 10 versions means 10 times the space may be taken up). Also I do not want documents cluttering up this library because it is a collaborative space. After 1 year documents are no longer needed, but they do need to be retained for 7 years due to legal compliance reasons. I can set a second stage to send all documents to a record center after 1 year.

SharePoint Server 2010 provides greatly improved capabilities and flexibility for retention of documents. A few of the major improvements include multi stage retention actions, more out of box retention actions, and location based retention. Also improvements with creating workflows with SharePoint Designer make it much easier to create custom workflows to create retention actions to solve your needs.

Quentin Christensen

Program Manager, Document and Records Management

For any SharePoint project you should carefully consider what metadata will be needed to perform required operations and for users to find content. Evaluate how long it will take users to fill in that metadata, and evaluate the user impact. If lots of metadata is required but end users do not adopt the system because the overhead for creating content is high it will be difficult to have a successful implementation.

Metadata defaults help with this problem because you can automatically fill in metadata for users. If a particular field will have the same value 50% or more of the time then you should specify a metadata default to help users fill in forms faster. Metadata defaults can be specified for each column at the site level, list level, and folder level. Metadata defaults inherit from each other and the child default will always override. For example if a default is set on a folder and there are defaults for the list and the site column, the default for the folder will be applied. If there are defaults for a column and a list, but no default for a folder then when an item is added to that folder it will get the list default. When users create or upload a new item the metadata default will be applied and be displayed in the edit properties form. The user can then change the property as needed. By planning for and setting metadata defaults early it will be easier to evaluate what the metadata defaults should be and how they can be used to help make it easier to get metadata applied to items.

Metadata defaults are supported on the following column types:

· Single Line of Text

· Choice

· Number

· Currency

· Date and Time

· Yes/no

· Managed Metadata

Setting metadata defaults when editing columns:

When creating or editing a column at the site or list level there is a field to specify a default value. You can specify defaults at the site level, and then override them at the list level.

Setting metadata defaults with the tree control: 

In libraries you can use a tree control to set metadata defaults for the library and per folder. To do this go to library settings and click on the link “Column default value settings”. This will give you a tree control that you can use to navigate the folders in the library. You can set defaults at the root of the library as well as for each individual folder. Folders will inherit default values unless you specify a particular default value for the child folder.

Metadata defaults are a great way to help place metadata on columns. You can even use it to apply defaults on hidden columns so users never even have the option to edit the field, but they can use the metadata to navigate and retrieve content.

Quentin Christensen

Program Manager, Document and Records Management

A common content management problem is documents getting moved to different locations and links no longer working. Another problem is submitting content to a repository and being able to find it at a later time. These are the types of problems the Document ID feature handles. Document ID is a site collection level feature that when activated adds columns to all document content types. Whenever an item is created or uploaded and is set to a content type that inherits from document it will get a Document ID. The document sets content type is a special case non document content type that also gets Document IDs.

Quick Tip: You may want to activate the Document ID feature on site collections that already contain a large amount of documents. Because this event triggers a content type pushdown on the Document content type the process can take a while. As a result, Document ID activation is done through a timer job that by default is run nightly. If you would like to activate the Document ID feature right away please run the Document ID enable/disable job in Central Administration. There is a separate time job that assigns Document IDs to existing documents.

Document ID Settings

Document IDs consist of two parts, a prefix (that is randomly generated per site collection by default) and two sets of numbers. An example Document ID looks like this: J2W3DN6QF6XW-2-10. The first number is the ID of the list that the document was first created in and the second number is the ID of the item in that list. The prefix can be specified per site collection and can easily be changed from the Document ID settings page.

The Document ID settings page can be accessed in Site Settings at the root of the site collection, and will be in the Site Collection Administration category. On the Document ID settings page you can specify whether or not Document IDs are assigned and the prefix that is used. By default this is randomly generated so Document IDs will be unique across a farm. You can change this to a more readable prefix such as an abbreviation. If you change the prefix there is a check box that you can select to reset all Document IDs. If you do reset the IDs of existing documents then you will break the intended functionality of Document IDs (the ID will no longer work because no document with previous IDs will be found). Reset Document IDs should only be done fairly soon after IDs were initially assigned (before people use Document IDs.) On the settings page you can also specify the search scope to use, by default the All Sites scope, to find Document IDs across other site collections.

Document ID (linked to document) Column 

In list views and in view properties of documents the Document ID column can be displayed. The Document ID column is a URL with a format like: https://site/_layouts/DocIdRedir.aspx?ID=J2W3DN6QF6XW-2-40. When this URL is clicked search will be used to find the document. This allows the URL to work even if the document has been moved to another location.

Document ID Send To Hint URL 

In Central Administration you can configure send to locations that allow you to submit content to another site and a content organizer will automatically route the document to its final destination. In this case a Document ID lookup URL is returned (If the Document ID feature is activated on the destination) which also contains a HintURL on the end so users can find the document immediately even though search may not have indexed it yet. Here is an example of a link to the HintURL:

https://sites/_layouts/DocIdRedir.aspx?ID=J2W3DN6QF6XW-2-96&hintUrl=DropOffLibrary/A1.docx

Document ID in Documents

One scenario you can use Document ID for is to track the electronic version of a document with a printed one. For example you may print out a document and give it to people, but they have no way to find the electronic version to see if there have been updates. You can use a Word quick part to insert the Document ID into a document.

You may even want to create a template so whenever users create a new instance of a content type it has the Document ID right in the header or a page of the document. To do this upload a document into SharePoint where it will get a Document ID. Then download the document, customize the template as you want to use it for your content type and insert the Document ID Value property using quick parts from the Insert ribbon of Word. Then save the file as a Word Template (dotx) and create your content type. In advanced settings for the content type, upload your template. Now when people use the New Document drop down to create new items of your content type they will have the Document ID Value embedded as a quick part.

Find By Document ID Web Part

There is a Find by Document ID web part that can be used where users can enter Document IDs to lookup a document. You can find it in the Search category of web parts. You can use the Document ID web part in combination with Document IDs that are printed out on physical documents so users can look them up.

Of course users can also just copy the Document ID into a normal search box to find the document as well. DocID is a managed property so you may want to use the following search syntax: docid:doc id value, for example in search type – docid:J2W3DN6QF6XW-2-96.

Document IDs are a new SharePoint Server 2010 feature that makes it easier to find documents when they have been moved to other locations. When documents are copied a new Document ID will be assigned and when Documents are moved or cut and pasted they will retain their Document ID. You can also use Document IDs to track physical documents with the electronic version.

Quentin Christensen

Program Manager, Document and Records Management

If you happen to be one of those customers who is stuck looking at an empty term store then I’ve got great news for you.  The SharePoint team have teamed up with WAND, a leading provider of Enterprise Taxonomies, to make their General Business Taxonomy available as a freely available download.  The General Business Taxonomy consists of around 500 terms describing common functional areas that exist in most businesses.  The General Business Taxonomy can be imported in to the SharePoint 2010 term store within minutes and provides a great starting point for customers looking to build a corporate vocabulary and take advantage of the Managed Metadata Service.  In addition to this freely available download, WAND provide a range of taxonomies covering a variety of domains including Products and Services, Local Search, Enterprise, Jobs, Travel, Medical, Lifecycle, Finance and Records Retention.

Download the General Business Taxonomy today and start to explore the benefits that taxonomy can bring to your business and your people. 

If you’re new to taxonomy and the benefits it can brings to your business, take a look at the following sites:

• TechNet – Managed Metadata and Taxonomy Resource Center
• Dan Kogan (Senior Lead Program Manager) – SharePoint 2010 Metadata Webinar
• WAND – Taxonomy 101
• WAND Blog

Ryan Duguid
Senior Product Manager
Microsoft Corporation

You can download the SharePoint 2010 Administration Toolkit today and start to take advantage of this new set of capabilities within SharePoint Server 2010 by building your own Composite Content Applications that talk to SharePoint through CMIS or configuring SharePoint to interoperate with other ECM repositories through the CMIS Consumer Web Part.

Microsoft has been involved in defining the CMIS specification since the beginning and has invested significant resources to ensure that our customers are able to take advantage of support for CMIS in SharePoint 2010 just months after releasing the latest version of our platform.  We are excited about the opportunities that the CMIS standard will open up within the industry and look forward to seeing more ECM vendors deliver support for CMIS in their upcoming product releases.

For further reading on CMIS, visit these sites:

• Details of the SharePoint 2010 Administration Toolkit on TechNet
• Original announcement of the CMIS specification and Microsoft’s involvement
• OASIS Members Approve Content Management Interoperability Services (CMIS) Specification
• OASIS CMIS Technical Committee

Ryan Duguid
Senior Product Manager
Microsoft Corporation

First, some background.  At one point during the development of Content Management Server 2002, we spent some time with the folks that run the Microsoft.com set of websites.  One of the things they were very keen on was this taxonomy system that they had built.  It seemed fairly useful, and we considered implementing something like it, but didn't have the time, and there was a general concern that no one would actually do the work of tagging data.  During the development of MOSS 2007, we were spending most of our time rewriting our feature set to run on top of SharePoint, and once again, taxonomy fell off the list of things we were willing to tackle (and still, people would consistently say that people just don't tag).

Around this time people started tagging things in their own world.  The rise of digital cameras and mp3 players brought a huge amount of data that for the most part, had to be marked up with metadata in order to be searchable.   Some metadata was added to the files automatically (things like date, size, camera model, etc.), but specific user information wasn't there.  You quickly learned that if you categorized the images (either through folder location or tags) you could navigate your way through 10's of thousands of files (images, music, etc.) the way that works for you personally, rather than relying on default information like date the picture was taken.  People became more familiar with the concept of navigating their content via metadata - "Let's listen to all my Pearl Jam albums, I feel like listening to Electronica, find me photos of Dad".  It's only a small step from that to wanting to impose some sort of hierarchy - find me photos of my whole family, my extended family, I want to listen to all classical music, or perhaps just from the Baroque period.  Tagging all that data really unlocked a lot of potential.

Perhaps the landscape had changed...

We decided to run with it in the 2010 release.  There were a few main tenets that we tried to let guide us:

1. No one (well, almost no one) apply metadata for the shear joy.  It's always for a purpose.
2. #1 means that the reason for the system has to be for the end user benefit.  What can you do if you have this rich metadata applied?
3. In order for #2 to come to realization, the metadata has to be present, which means that applying consistent metadata needs to be as easy and ubiquitous as possible.

To that end, we set out to enable a bunch of new user scenarios for SharePoint 2010.

We started out the release with a blank sheet of paper and some very knowledgeable people in the information management space.  We also found that most people started twitching uncontrollably when the word "ontology" was mentioned.  'Tagging' was fine, 'metadata' was OK, at 'taxonomy' they started looking for an exit.  Telling people that a taxonomy was just a hierarchy calmed them down, but the whole ontology thing was too much of a stretch.  It also complicated things considerably, and we could still get a huge amount of value out of a taxonomy, so this was our starting point.

Some features were very obvious - filtering list views based on hierarchy inclusion, search refinement, etc.  Some were a small step from this - if you have a consistent vocabulary across an enterprise, you can start to do some interesting things.  You can match areas of expertise to specific content or workflows.  You can start to relate content in totally different systems based on something with more context than a simple string.  What if you could relate your analytics content to your taxonomy system and get a real-time view of what topics people are viewing instead of simply guessing based on their position in a URL namespace?  How about overlaying your security model with your metadata so that certain people had rights to view content based on the metadata applied to it?  How about we get down to business and focus our resources and ship a compelling collection of features.

To that end, we came up with the following components in the system:

The taxonomy repository itself, we call it the Term Store.  Some companies have very top down strict taxonomies, so some term stores might have a very few people allowed to edit them.  We'll have to support having multiple term stores.

The taxonomy system needs to be able to support a complex enterprise.  A simple flat list of strings isn't going to be sufficient.  To that end, we support the following concepts and behaviors:

• Terms - A term is the central object in the taxonomy system.  It's the concept itself.  It's very hard to come up with a name for a concept and have it be sufficiently descriptive and not too vague.  Term is what we came up with.
• Labels - Terms have to be known by a bunch of different names.  When someone types "check" it should be the same thing as someone that types "cheque".  "USA" and "United States" and "United States of America" are all referring to the same term.  We call these names labels.
• Default Label - It's a whole lot easier if one label is the default.  You can find it through any of its synonyms, but we'll display the default label in most circumstances.
• Termset - A collection of related terms in a hierarchy is a termset.  Things like "locations" and "products".
• Term Reuse - This is a key point to the system.  If you have two termsets "Capitol Cities" and "Locations", the term "London" and all of it's synonyms, etc. should be the same in both.  We don't allow a term to have two parents in the same termset, but it can have two parents in different termsets.
• Homographs - A homograph is a word that is spelt the same, but has a different meaning.  You should be able to have a hierarchy that has "Paris" existing in both France and Texas.  To keep things a bit more sane for the user, we don't allow homographs to have the same parent.
• Multiple language support - A given term has a bunch of meaning associated with it.  The translations belong to the term in the same way that synonyms do.  If a term doesn't have a translation, we use the default language.
• Groups - Groups in the taxonomy system are simply collections of termsets that share a common security assignment.  Termsets and terms aren't ACL'd, groups are.
• Deprecated terms - if a term shouldn't be used any more, it can be deprecated.  This doesn't remove it from the system, you just can't apply it to new content moving forward.
• Terms that are unavailable for tagging - this is slightly different from deprecated terms.  A deprecated term is deprecated in all occurrences in the taxonomy and isn't shown to the user when tagging.  Unavailable terms are only unavailable in a specific termset, and are still displayed when browsing the hierarchy at tagging time.  The purpose of this is to allow things to be hierarchical without allowing people to tag with the wrong term.  For example, in the Capitol Cities termset, you might have continents in it so that people can find a particular city, but they would be marked as unavailable for tagging (with respect to Capitol Cities) because they should not be selectable at tagging time.
• Merging terms - at times, you might get multiple terms in the system that really are the same thing.  They might be in the same termset, or they might be in different termsets.  When you merge them, you get a single term with all of the properties, and this new term will be reused in all termsets that the original terms existed.
• Open Termsets - There are times when a highly managed taxonomy makes sense.  You shouldn't be able to add random countries to the list of known countries.  However, you probably don't want to give taxonomy editing permissions to everyone that is creating a new codeword.  Open termsets allow content editors to add new terms to a hierarchy at content authoring time.  It's a bit of a meeting point between bottom up folksonomies and top down taxonomies.
• Keywords - The degenerate case of a folksonomy is a simply flat list of strings.  They have no extra semantic meaning.  This is the enterprise keywords termset. Terms here don't have a hierarchy, definitions, synonyms or translations.  However it is possible to move a keyword into a managed termset and add this additional data.
• Local termsets - The taxonomy field type gives you all sorts of useful features, but you probably don't want "places to order food from" to wind up in your enterprise taxonomy.  Local termsets are only visible within a single site collection.

OK, that's a nice set of features in the taxonomy system.  What do we want to do with all those terms and termsets?

The next set of features involve integrating the taxonomy system with SharePoint.  The primary place this happens is in the new managed metadata field type.  Think of it as a choice field that went to the gym.  It's much more powerful.  The metadata field type is a normal field that can be applied to any content type (list or document library).  However it has a few nice things associated with it:

• Termset binding - You can specify what termset a field should be bound to.  You can have lots of fields bound to the same termset.  When you update the termset, all of the bound fields use the changes immediately.
• Path or node display - You can choose to display the default label of the term by itself "Paris" or its path "Europe > France > Paris".
• Multi-lingual rendering -   If a given term has been translated to a given language, when your UI is set to that language, the term translations are displayed.
• Content type syndication - This isn't a taxonomy feature per se, but it's part of the enterprise metadata feature set.  We allow a term store to have a site collection defined as it's "hub".  On that hub you can publish content types, and these content types will be pushed out to all consuming site collections.  This means that in addition to having a consistent vocabulary across your enterprise, you can have a consistent set of content types using all that goodness.
• Rich editing - when you are applying a term to an item, you can search across the entire termset (including synonyms) or view the tree itself.  It makes it possible to choose from thousands of choices, which would normally break lookup and choice fields.
• Editing support in the rich client applications - the document information panel in the Office client applications allows for applying terms.
• Offline editing in the rich client applications - when you edit in the rich client applications, a copy of the bound termsets is cached locally.  You can tag on the plane.

Once data is in SharePoint, other SharePoint features can deliver additional goodness:

• Better listview filtering - not only can you filter in the normal "everything with value X" but you can also do inclusive filtering, displaying everything tagged with X or a child of X.
• Better metadata navigation behavior - The metadata navigation feature allows you to navigate through libraries using hierarchies other than the folder hierarchy.  The termset is one of the allowed hierarchy types, meaning that you can browse your libraries along multiple axes.  You can now free your data from the tyranny of the URL or folder namespace.
• Routing and policy - The document routing feature can direct your content based on the metadata applied to it.  Taxonomy fields can even be used to create folder hierarchies at the routing destination.  Retention policies can be driven off of taxonomy fields as well.
• File open / save - Can't remember exactly where your document is stored in a large library?  You can use the taxonomy field to filter the open dialog display.

Now that we have all that nice consistent metadata on our content, we can do a few more things:

• Content by query Web Part enhancements - You can configure the CBQ to filter based on taxonomy fields, including descendent inclusion.
• Automatic search refinement - The search system is aware of all taxonomy fields, and if a result set has a sufficient amount of data with the same taxonomy fields, a search refinement will appear, allowing users to filter their data.
• Power user profile and social tagging - it doesn't make much sense to have a corporate taxonomy and then do your social tagging using just string matching.  All of the social properties are actually sourced from the taxonomy system, meaning that you won't get people asking you where a good place to stay in Paris, France when you are an expert on Paris, Texas.

And since we know that we can't possibly implement every feature that everyone would want, everything is accessible through our API.  In future blog posts, we'll go over how to use this API to deliver some compelling features.

Hopefully this is a nice introduction to the work we did around taxonomies and enterprise metadata.  We had a lot of fun coming up with the design and implementation, and hope that it resonates with you.

Thanks for reading.

Pat.Miller at Microsoft.com

I'd like to answer a common question about how to modify the behavior the Variations feature in SharePoint 2010 uses when propagating pages. That is, how pages in the source variation site are copied and appear on target variation sites as minor draft versions.

Page propagation is triggered by publishing a page on the source variation site by default. Each time you publish a source page, the Variations Event Receiver adds a work item to the Variations Propagate Pages timer job queue. When the timer job runs, it will begin executing the first 100 page propagation work items. For each work item, Variations will copy the source page to all target sites, creating the page if it does not yet exist, or appending a draft minor version if the target page does already exist.

In some cases, users might not want changes to a page on the source to necessarily propagate to all targets. That is, users might want to make source-local changes and have the option to make changes globally applicable when they want. This often takes the form of a question like "How can I stop variations from overwriting my target pages every time I publish a source page?" Variations in SharePoint 2010 helps you do this.

In SharePoint 2010, we've worked to improve the Variations feature's server citizenship by moving all Variations operations to the timer service. This way, server administrators can control the frequency with which operations run and better manage server load. The "Update Variations" button now adds a work item to the same Variations Propagate Page timer job queue as does publishing a page when "Automatic Creation" is enabled. What differentiates "Update Variations" is that you can also use this button to propagate source draft versions without publishing them on the source variation site.

When you run this PowerShell script to enable "On-Demand Page Propagation," all Variations Propagate Pages timer job work items are filtered and discarded except those added to the queue by the Update Variations button:

Enable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("https://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", "True")
$folder.Update();

Disable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("https://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Remove("DisableAutomaticPropagation")
$folder.Update();

"Update Variations" in SharePoint 2010 can be used to propagate the current version of a page on-demand provided that the Variations Propagate Page Timer Job is enabled

In MOSS 2007, some users disabled the "Variations Propagate Pages" timer job in Central Admin as a workaround. With the timer job disabled, publishing a source page would not cause SharePoint to copy the source page to any target page. Authors on the source variation site could then use the "Update Variations" button to propagate the current version of the source page on-demand.

Clicking "Update Variations" in MOSS 2007 immediately propagated the current version of the source page to all target pages, "skipping the line" and bypassing the Variations Propagate Pages timer job. So when the timer job was disabled, "Update Variations" could still be used to propagate pages.

However, when the timer job is disabled, publishing pages on the source continues to add work items to the timer job queue if the "Automatic Creation" option is enabled, as it is by default. Over time, the queue can grow and contain hundreds or thousands of work items, all of which would begin to execute if the Variations timer job were re-enabled in the future. If you upgrade to SharePoint 2010 with a backlog of work items, SharePoint will discard these.

With the new “On-Demand Page Propagation” functionality, you can achieve this content distribution model out of the box.

"Update Variations" in MOSS 2007 works differently under the hood from its counterpart in SharePoint 2010

Things to keep in mind:

• “On-Demand Page Propagation” affects the entire site collection; that is, if you enable this setting, no source page will be copied to any target page when the source page is published. Only the "Update Variations" button will cause pages to propagate when the timer job is enabled.
• Source pages will be copied as draft minor versions to all target variation sites when you use the "Update Variations" button.

Thanks for reading. Happy propagating!

Josh Stickler
Program Manager

1. Personal email management
2. Project and case management
3. Email archiving
4. Records management

Each of these scenarios has a set of desired outcomes and set of capabilities that best meet those outcomes so let’s take each one in turn.

Personal email management

Personal email management is all about empowering end users to take control of their inbox, making it easier to organize, find and take action on email.  Users want a mail client that makes it easy to manage email on a day to day basis and expect their IT department to take care of backup and restore.

Project and case management

Project and case management is all about sharing information and managing a group of related artifacts in a single location with a common security model, metadata model and information management policy.  Users are looking for a solution that makes it easy to collaborate and find information while leveraging workflow to drive common business processes.

Email archiving

Email archiving is all about taking control of the proliferation of email within an organization, driving down the cost of provisioning ever increasing inbox requirements and applying broad brush time based disposition.  Email archiving is typically driven by IT who implement rules and retention policy that is typically transparent to end users.

Records management

Records management is all about identifying business critical content, driving appropriate classification and then applying relevant retention management policies.  Accurate classification of content and applying appropriate metadata ensures that information is easy to find and use throughout the enterprise.  At the same time, appropriate use of retention policies ensure that businesses can gracefully age content that is no longer of value while adhering to relevant government and industry regulations.  Email is a critical part of any modern records management strategy and so businesses need to make it easy for end users to identify and classify email that is considered to be business critical content.

Outlook 2010 and Exchange 2010 provide great capabilities to deal with personal email management and email archiving while SharePoint 2010 provides an ideal platform for storing email that is part of project and case management or an effective and encompassing records management strategy.

Of course there is a natural flow or continuum as email may start by being well managed in a user’s inbox, it may have an email archiving policy attached to it but a user may decide to manage it as part of a project and then finally declare the email as a record upon project completion.  As I said at the start, there are no hard and fast rules but hopefully I’ve given you a better frame of reference for working out what systems are required to support email from creation to disposition depending on the required business outcomes.

If you want to hear more about this topic, I’ll be presenting a webinar with Colligo, one of our partners who provide an add-in for Outlook that makes it easy for users to drag and drop email in to SharePoint, applying the appropriate Content Type and metadata attributes as part of the process.  The webinar is on June 17th so sign up now.

Ryan Duguid
Senior Product Manager – ECM and Compliance
Microsoft Corporation