Sharepoint 2010 : Administering Enterprise Content Management - Document Management (part 8) - Content Type Syndication

1.14 Content Type Syndication

SharePoint 2010 includes a new feature called Content Type Syndication. As the name suggests, this feature provides you with the capability to publish content types from one designated site collection to other site collections, Web applications, or even farms. In prior versions of SharePoint, content types were limited to being configured within an individual site collection. To share content types consistently across multiple site collection, you often had to rely on custom code solutions or third-party tools. SharePoint 2010 allows you to share content types in much the same manner as enterprise metadata. When content types are published using Content Type Syndication, the back-end services ensure the following.

• Consistent application of metadata

• Consistent application of policy

• Consistent application of workflow associations

The following system and service elements are central to making Content Type Syndication work and must be configured prior to publishing content types.

• Content Type Syndication Hub

• Managed Metadata Service

• Managed Metadata Service Connection (Proxy)

Setting Up a Content Type Syndication Hub

Prior to configuring the service applications for syndication, you need to set up a special designated site where your source content types will be created and maintained. This will be a highly controlled site, and only people responsible for managing and maintaining these content types will have access. The hub can be based on any site template, but for the examples here, you will set it up within a team collaboration site, where the people managing these content types might want to collaborate with each other while they manage the content types.

Begin by creating a new site collection in SharePoint Central Administration. After you have created the new site, visit the site and activate the Content Type Syndication Hub site collection level feature. You can do this by clicking the Site Collection Features link in the Site Collection Administration settings group on the Site Settings page. Activating this feature will enable the functionality needed to publish, unpublish, and republish source content types.

Setting Up the Managed Metadata Service

With the Content Type Syndication Hub site in place, you now must configure the Managed Metadata Service to use this site as a designated content type hub. To do this, perform the following steps.

1. Open a browser and go to the SharePoint Central Administration website.

2. Under Application Settings, click Manage Service Applications.

3. Highlight the Managed Metadata Service instance you want to use to publish content types from the new hub site. To highlight, select the service in the table without clicking the service’s name.

4. Click the Properties icon on the Ribbon.

5. Scroll down to the bottom of the Properties page to find the Content Type Hub property.

6. Enter the URL of the site collection you created for use as a content type hub.

7. Optionally, select the Report Syndication Import Errors From Site Collections Using This Service Application check box.

8. Click OK.

9. When you return to the Manage Service Applications page, select the Managed Metadata Service Connection and click Properties on the Ribbon.

10. Select the check box labeled Consumed Content Types From The Content Type Gallery At <http://UrlYouSpecified>.

11. Click OK.

After you have specified a content type hub for an instance of the Managed Metadata Service, you cannot change it or remove it. You may elect to disable the syndication of content types from that hub on the service connection side, but you would need to do so for every service connection in the enterprise that consumes content from the given service instance.

Publishing Content Types from the Hub

When you have established an active content type hub, you can begin to create content types for publishing. To do so, simply visit the site content type gallery, which can be found on the Site Settings page, and click Create to get started. When you have created your new content type and created or assigned the site columns, you are ready to set up the new content type for publishing. Figure 22 shows an example content type that has been created for publishing within the Content Type Syndication Hub site. Notice the new Region column, which is a managed metadata field.

Figure 22. Content type for syndication

After you have created the content type, click the Manage Publishing For This Content Type link, shown in the Settings in Figure 22. From the Content Type Publishing page, you can perform the actions described in Table 11.

Table 11. Content Type Publishing for This Content Type

ACTION	EXPLANATION
Publish	Make this content type available for download for all Web applications (and site collections) consuming content types from this location.
Unpublish	Make this content type unavailable for download for all Web applications (and site collections) consuming content types from this location. Any copies of this content type being used in other site collections will be unsealed and made into a local content type.
Republish	If you have made changes to this content type, the content type needs to be republished before the changes are available for download to all Web applications consuming content types from this location.

This page also provides publishing history information, including the date on which one or more service applications successfully published this content type. After you have selected the action you want to perform, click the OK button. Within a few minutes, the published content type should become available in site collections or Web applications that consume the associated Managed Metadata Service. The content is made available through the firing of a timer job that provides the back-end processing. If you want to check on the status of the job or run the job immediately, you can do so from the Monitoring area of SharePoint Central Administration. The job is named Content Type Subscriber, and it will be bound to the associated Web application that is consuming the service.

Configure Content Type Publishing in Subscribed Site Collections

How do you know if your site collection is receiving content types through syndication? There is a settings page available within Site Settings that allows you to review which services are publishing content types to your site collection. To access this page, click the Content Type Publishing link in the Site Collection Administration Settings group on the Site Settings page. The page provides the settings options and information described in Table 12.

Table 12. Content Type Publishing for a Site Collection

SETTING	EXPLANATION
Refresh All Published Content Types	The next time the Content Type Subscriber timer job runs, update all published content types. Select this check box and click OK.
Content Type Publishing Error Log	Contains errors that happened during content type syndication for this site. Click the link to view the log.
Hubs	Lists the service applications that are publishing content types to this site collection. To edit content types that have been published from these locations or to create and publish a new content type, select the hub URL. To view the subscribed content type on this site collection, select the content type name.

Real World: A Note on SharePoint Server 2007 Customizations

Many organizations quickly adopted SharePoint Server 2007 because they could see the strategic long-term benefits of the technology. In some cases, however, organizations determined that the functionality specific to Enterprise Content Management was insufficient for their detailed requirements. Then these organizations often opted to make significant customizations. The motives for these efforts varied. Some organizations needed tighter records management and improved automated movement of content that occurred behind the scenes; others needed a set of standardized content types and site columns across the entire enterprise.

As many of these organizations begin their efforts to upgrade to SharePoint 2010, there will be some big decisions to make about how to handle these customizations. Libraries that are riddled with event handlers, content types that are present in the file system hive, and customized retention and expiration workflows and field types abound. How do you correlate these existing customizations with the new features and functionality provided within SharePoint 2010? You have the following options when you want to upgrade to SharePoint 2010.

• Rebuild from scratch.

  • Create new sites.

  • Configure all of the features to meet your needs.

  • Migrate all of your content to the new sites.

• Go forward with your customizations.

  • Keep your existing customizations in place, where supported.

  • Use new features to meet new needs.

  • Upgrade your existing sites and keep your data in place.

• Remove customizations where there is feature overlap.

  • Use new features to meet the requirements met by existing customizations.

  • Remove customizations where you can, replacing them with the implementation of new features wherever possible.

  • Upgrade or migrate your existing sites based on the anticipated impact of the customization adjustments.

Some people assume that a major version upgrade means a hardware refresh and/or a migration, and that’s fine, because the tradeoffs described here will be easier if that’s how the upgrade is handled. Of course, the word “migration” is used as if it’s easy to accomplish, and it’s not easy at all. Often you must purchase and use special tools to reclassify all of the information and preserve metadata during a migration.

If you are like most people who want to take advantage of the new features and management capabilities included in SharePoint 2010, but you have numerous overlapping customizations, you will need to either take those customizations forward or remove them where there is overlap.

When it’s possible to remove customizations where there is overlap with new features, that is clearly the better option. Or course, you will need to define requirements for their removal, especially if you upgrade your sites in place. You may find that you need additional code or customizations to reclassify existing data or to back out the prior customizations and configure the new features. The key to success in this endeavor is to exercise good project management and requirements-gathering discipline. Clearly document what you have, what overlaps, and what you think you can safely remove. Design a plan for removing the prior customizations for sites that already exist while configuring the new features in their place. Where you must retain customizations that provide overlap in existing sites, and you still want to use the new features for newly created sites, you may have to update those customizations accordingly.

SharePoint Server 2007 marked a revolution in the world of collaboration and content management for mid-sized companies, as everyone did their best to move to a standardized platform that met most of their needs. In the process, however, it became one of the most overcustomized software packages in history. As you move forward into the world of SharePoint 2010, remember that, although the system provides ultimate flexibility, any customizations created will have to be maintained for years to come, especially during an upgrade.

Records Management

Records management was introduced with SharePoint Server 2007, with a special site template called the Records Center. The Records Center site provided a set of capabilities for managing, disposing, preserving, and holding records. Records Center sites were managed by a special group of people called records managers, whose responsibility it was to maintain the records stored in the site, as well as monitor and update the routing rules (file plan) to ensure that inbound records were stored in the correct place.

In SharePoint 2010, you can still manage records within a Records Center site, sometimes referred to as a records archive. You can also opt to manage records in place, alongside active documents where they are stored within the system. This is because many of the features previously provided as part of the Records Center site are now available as individual features that can be enabled within any site collection. This provides you with maximum flexibility when determining how best to manage declared records. For example, you could specify a different retention policy for documents declared as records, or you could have such documents moved to a records archive for storage and management. You could also opt for a mixture of in-place records management and archival records management, which involves holding a document in place as a record for a specific duration and then automatically moving it to a records archive for long-term storage and management.

The following sections examine the records management capabilities delivered with SharePoint 2010, including new features that enable you to perform records management in any site. You will also explore the administrative interfaces and configurable items of each feature and cover key concepts that Microsoft considered when developing the records management functionality in SharePoint 2010, including the topics in the following list.

• Records management and upfront preparation

• Records management features

• Improved Records Center site

• In-place records management

• eDiscovery and hold

• Retention and reporting

• Scalability

This section begins with a look at the need to perform upfront preparation before configuring records management.