What follows in this post is a brief sample of the type of courseware that Combined Knowledge and Mindsharp are writing for SharePoint 2010 as part of our participation in the World Education Alliance. If you're looking for SharePoint 2010 Training, we would invite you to join one of our Mindsharp or Combined Knowledge classes. Enjoy!

Why Publish Content Types?

There are four main reasons to publish content types. They are:

• Consistency
• Identity
• Location
• Lifecycle Management

Consistency

The first scenario is about consistency: Is it (the content type) the same across the enterprise? When one stops to think about it, content types and metadata are really about consistent governance and management and standardization of information in the enterprise. In other words, if I build out content type "A" in Site Collection 1, is it the same construct as when it is used in site collection 2? The MMS will answer this question in the affirmative and yet provide localized extensibility for greater usability of the content type in specific scenarios.

Identity

The second scenario is about identity: What is in the content type? When it comes to the enterprise, is this content type about the same topic with the same metadata? What metadata is in the content type? Understanding the construction of the content type helps us understand it's focus, purpose and meaning.

Location

The third scenario is about location: Where is this content type and how can I use it? The MMS will allow you to search for the content type, navigate to it, aggregate data with it and find data using it.

Lifecycle Management

The fourth and last scenario is about lifecycle: This scenario encompasses the creation, consumption and disposition of the content type in the enterprise. More specifically, the content type can be mapped to a document's lifecycle and then utilized across the enterprise in distinct ways. We'll use workflows to move the document from one lifecycle stage to the next, ensuring that compliance is enforced, tracked and audited.

Understanding Terms

The MMS has some terms that we'll use, so here are some terms and definitions:

• Hub - A site collection designated as a "source" from
  which we share content types throughout the enterprise
• Content Type Syndication - Publishing, sharing, pushing
  one or more content types across site collection, Web App.,
  and farm boundaries

Note that a taxonomy is not the same thing as an ontology. And ontology is the philosophical study of the nature of being, existence or reality in general, as well as of the basic categories of being and their relations. By contrast, when we refer to a taxonomy, what we're referring to is a hierarchy of objects that will likely include synonyms, equivalencies, parent/child relationships and metadata. In contrast, a folksonomy can be thought of as "free-form" without a hierarchy of terms from which to draw metadata values.

Content Type Publication

The core value of Content Type Publication is the ability to create a data element that has metadata, workflows and policies attached to that data element, and then publish it to the hub and from there, syndicate it to all web applications, site collections and sites in your farm and in child farms. For example, let's suppose your organization develops a policy that says all blog posts are to be expunged 12 months from the last date of modification. Well, you can develop a content type that includes that policy that will kick off a workflow to delete the blog post after 12 months. You'll then publish this content type to a hub and from there, syndicate it across your farm.

Publishing Content Types

Content Types are created within a normal content type gallery and then are "published" from a "normal" Site Content Type Gallery to a hub within the MMS. Each MMS gets one hub for CTS. If you need more than one hub in your farm, you'll need another MMS. It is not a requirement that an MMS syndicate content types nor is it a requirement that a service connection to an MMS consume content types from that service. Setting a site collection to be the hub enables necessary components on the hub for it to operate properly.

The elements that get published include the following:

• Content Type with all the corresponding columns
• Document Set Content Type
• Policies
• And workflow associations, but not the workflows themselves

You'll need to ensure the workflows are available downstream where the content types are going to be syndicated. Once those content types land in the destination gallery, they will be re-associated with the workflow(s). If the workflow doesn't exist in the destination site, then no assignment is made and the content type will function to the extent it can without the workflow.

For the content types that are on the hub site collection, you can perform the following actions:

• Publish: this means that the content type is being syndicated for the first time
• Unpublish: this means that the content type should no longer be in syndication. The effect of an unpublish action is that the content type is made read/write at the local level and is still available for use at the local level, but it's no longer available in a read-only version from the hub.
• Republish: this action is used when changes to the content type have been made and you want to push those changes out to the consuming audience
• Roll-up errors from consuming site collections: it is possible, in a scenario where there are thousands of content types being published from a single hub, that some content types will contain errors. In those instances, all of the consuming sites will report their errors back to the hub so that the content types can be fixed and republished.

From the consuming side of the syndication, you can:

• Extend a published content type: consuming sites can add more columns to the content type in order to give that content type more specificity in the local environment
• Derive from a published content type: this means that we can use that published content type as a place from which to inherit to create new, local content types
• View import errors: this will allow the consuming site to view the errors that it is reporting back to the hub
• Refresh all content types consumed from the Hub: this action allows the consuming site to erase all of the syndicated content types and perform a new, full download of the existing published content types from the hub. This can be especially helpful when the hub has been down or the consuming site has been down or connectivity has been lost and there is a need to capture all of the new, updated changes from the hub.

Setting up Content Type Publishing

There are several steps to setting up the MMS for content type syndication in your farm. First, you'll start at the site collection layer by associating the site collection with the MMS. The MMS is turned on from within Central Administration and the service-to-web application association is also executed within Central Administration. The site collection can be associated at the time the application service is created, as illustrated here, where we're creating a new human resource metadata hub at a new site collection called hrhub.

The MMS can use any site collection as its' hub for content type syndication as long as the owner of the MMS service has permissions to that site collection. The site collection hosting the hub does not need to reside in the local web application with which the MMS is associated. Once the hub is selected from within the MMS, the syndication service can be shared and all of the other consuming sites will need to consume from the shared services' hub. Technically speaking, the syndication is not a push technology, it is a pull technology. So the consuming sites pull the content types from the hub in a pre-configured frequency. That's why, in some ways, it's better to talk about the content types being published as opposed to be syndicated. However, be aware that the literature and informal blog posts will use both terms. In both cases, they are describing a publishing/pull architecture.

Note that the content types themselves haven't changed from SharePoint Server 2007 to SharePoint Server 2010. They are still data elements coupled with metadata, policies and workflows. The content type galleries, aside from some UI changes, also look to be pretty similar.

So, in our example in this module, we're going to create a new content type named "Candidate Evaluation Form" (not illustrated) and then publish it to other content type galleries where it can be consumed and the metadata can be extended. Since the publishing is at the content type layer (not the gallery layer), we decide to put all published content types in the hub in their content type group.

We derived the Candidate Evaluation Form from the Document content type to create a new content type. The Candidate Evaluation Form contains these unique metadata elements (not illustrated):

• Job Number
• Department Number
• Hiring Contact

Once the service application is started, you'll find the publishing action in the properties of the content type itself, "Manage Publishing for The Content Type". If this link doesn't appear, then that means that the service is not started or this site content type gallery does not reside within a publishing hub. Recall that each Managed Metadata Service can have only one hub and that content type publishing is not a requirement in order for the hub to be installed and to operate.

When you click on the "Manage Publishing for this Content Type" link, you're taken to the managectpublishing.aspx. page. On this page, you're able to perform the following actions:

• Publish
• Unpublish
• Republish

Because this is the first time this content type is being published, only the Publish action is available. Until the content type has been published, it cannot be unpublished or republished.

The most common scenario for using the unpublish/republish actions is when you want to update the content type by either adding metadata to the content type or deprecating metadata from it. You can also modify other properties of the content type, but those scenarios will be less common. So let's assume that you want to update a published content type with new metadata while retaining the current metadata on the content type. Here are the steps you'd take to ensure the new metadata is published:

1. Unpublish the content type. This action will remove the content type from being pulled by consuming sites. Note that this action does not affect content types in consuming sites - their content types will continue to work as needed and as expected.
2. Modify the content type as needed.
3. Republish the content type: This action will put the updated content type back into the published role and the consuming sites will be able to pull the updates to the content type to their location and begin using the additional metadata

Consuming a Published Content Type

The first configuration element for the consuming site is to ensure the site is associated with the same application service. This is accomplished in Central Administration. Highlight the web application you wish to associate with the Managed Metadata Service application, then select Service Applications from the ribbon.

By default, all of the service applications appear in the Default group. But you can group the applications into different groups or you can select "Custom" and select your own mix of service applications to associate with the web application. In our illustration, we chose Custom and associated the HR metadata service and the user profile service with the Portal web application.

The act of consuming a content type that is published is a Site Collection Administrator act - in other words, you must have site collection admin privileges to set this up. The link you'll want to select under Site Settings is Content Type Publishing Hub. Note that in Beta2, these links in the site collection admin area are not in alphabetical order, so you'll have to hunt to find it.

That link will take you to the contenttypessyndicationhubs.aspx page. On this page, you will see the hub with which your site is associated. You can check the Republish all content types on next update check box if you wish or leave it blank. Leaving it unchecked will mean that you will not receive updates via the Republish action at the hub. Selecting the checkbox means that you'll re-copy all of the content types at the next update interval.

The update interval is run by the Content Type Subscriber timer service (one for each consuming site collection), which, by default, it set to run every hour at a randomized time between 0 and 59 minutes after the hour starts. You can customize the frequency of how often this timer service runs and, if needed, click the Run Now button (not illustrated) to force the consuming site collection to come to the hub and copy down the content types to their galleries.

Once copied down, the content type will appear under a pre-configured group called Published Content Types.

Once the content type is copied down to the consuming site, it can be extended with additional metadata and other, new content types can be derived from it. Moreover, only the Advanced properties are available on the published content type, with all of the other properties being set and controlled by the administrators managing the source content types at the hub. This means, for example, that you can't associate a different workflow with the content type than has been associated at the hub.

Notice also, that the interface will show the source of the content type to be the consuming site collection. This is because the pull action is a copy action, not just a set of pointers that point back to the source content type source. So the content type is copied and a new content type is created in the consuming site collection.

Bill English, MVP