This info is from Marcel Madena
How to publish and consume Content Types across Farm and Farms. This new feature is available through the Metadata Services Application, which maps the Site Collection in which the Content Types are shared, working like a Hub. The Content Type Hub publishes the Content Types and through the Metadata Service Application they are replicated to the Subscribers. These subscribers can be Site Collections that are in different Web Applications even in different Farms.
Content Types Synchronism is done by 2 Timer Jobs that are executed in the background. They are:
Content Type Hub – Responsible for managing the Content Types to be published.
Content Type Subscriber – Responsible for publishing the Content Types from the Hub to the Content Type Gallery of the Site Collection.
Any Site Collection of you choice needs to be configured as the one and only Content Type Hub. The Metadata Application Service is a service for sharing metadata, whose main feature is the storage of keywords and term sets and is the place to configure a Hub for Content Types.
The Metadata Service Application can be created through Manage Service Applications
Enabling the Taxonomy feature, this feature is hidden and not enabled, which is needed to use the Managed Metadata column type. Fortunately, this is a Farm feature so we need to enable it only once. Run the following command using stsadm: STSADM -o activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C -url http://<server> -force
So, now that we have the basic setup complete and prepared the environment, we need to connect the Managed Metadata Service to the Hub site collection. Within Central Administration, navigate to Manage Service Applications under Application Management. Select the Managed Metadata Service you wish to connect to the hub (to top row, not the connection below) and select Properties from the ribbon. On the bottom of the properties page, you can enter the url of the Site Collection hub. The service is now connected to the Hub. In the Hub site collection, this has caused the activation of the Content Type Syndication Hub feature.
Note: An important point to be commented is that once the URL Configuration for the Content Type Hub is set, this cannot be changed by the user interface. You can change the content hub location afterwards if needed thanks to PowerShell: Set-SPMetadataServiceApplication [MetadataServiceName] -HubUri [NewHubURL]
Performing operation "Hub uri by default, all published packages will become unpublished, and all subscriber sites will redo syndication. This is a very costly operation. And packages have to be republished on the new hub site." on Target "Managed Metadata Service".
Another thing to remember is to only use the WebSite address (FQDN, Friendly Name or Host Header) and not the full URL you would use to access the site.
Examples of what will work:
Examples of what WILL NOT work:
Publishing – Manual
In this type of publishing go to Site Actions > Site Settings > Site Content Types and for each Content Type created, under the Settings go to Manage publishing for this content type as shown.
Shortly after that, one of the options for publishing is available
Note: Because we are publishing it for the first time, only the Publish option is available. If you have already published the Content Type, the other two options are available and the current disabled.
Just for clarification, I am commenting on the publishing options:
Publish – The Content Type is delivered for being consumed in other Site Collections that reference it.
Unpublish – The Content Type is retracted. Its copy remains in the other Site Collections, however its status changes to be no longer Read-Only.
Republish – Redo the Content Type Publishing. It should be applied in cases where there was some change in it.
How to consume Content Types
In order to consume the Content Types of the Content Type Hub, make sure you are referencing the Metadata Service Application that offers the service application. This applies only if you are using another Web Application as Hub, otherwise you’re already entitled to use it within your Web Application.
To consume the published content type in our site collection, we navigate to Site Settings and find the Content type publishing option in the Site Collection Administration menu. Click “Content type publishing” and at the top, you will find an option to refresh all published content types during the next update, check this. When you now go to your Site Content Types gallery in your subscriber site, you should see the published content type listed.
Make sure you have referenced the service application in the Central Administration > Application Management > Configure service application associations. Note: I can have two Web Applications, the 81 serves as Publisher and the 80 as Subscriber. Both use the same service Managed Metadata Service.
In the beginning of this article I quickly commented on the Timer Jobs that are responsible for the Content Types Synchronism, now just exploring a little more, if you want to trigger them after publishing or unpublishing Content Types for a quick check, go to the Central Administration > Monitoring > Check job status and select the desired job definition according the Figures 12 and 13:
Note: By forcing the execution of the Timer Jobs above, always trigger the Content Type Hub (Publisher) first and then the Subscribers. The execution is asynchronous, so despite the status changes quickly after triggering the job, probably it will still be running. Note that there are two Subscribers consuming the Content Types (port 80 and 81) even though the Hub is on port 81, just because other Site Collections within the same Web Application can take advantage of Content Types.
After the asynchronous execution, you have the option to check at the Site Collection Subscribers whether the Content Types were successfully replicated. One possible way is to access the Content Types via Site Actions> Site Settings> Site content types (Group Galleries) and check whether the Content Type is there.
Tip of the day
Do not use Features to deploy the Content Types that need to be published in the Hub, because by doing this you will be creating a dependency on them with a FeatureId and must install the same Feature on the Site Collections Subscribers.
In order to consume more than one Content Type Hub, you need to create another service application for that. This is applicable in case you want to create different scopes for Content Types, e.g. the separation of Content Type Hubs for consumption in an Intranet Web Site and the other one in an Internet Web Site.
In the version of SharePoint Server 2010, the Service Metadata Application enables the sharing of Content Types, which promotes the Content Type Syndication in different Site Collections from different Web Applications, and even in different Farms!
Enjoy this feature to create a new Design sharing Content Types!
Content Type Hub FAQ and Limitations
Content type hub is a new feature in SharePoint 2010 to manage content types centrally and publish them to the subscribed sites. As any other new feature introduced in SharePoint 2010, content type hub also has its known limitations and some workarounds for those limitations. If you are eager to know more about content type hubs, please visit my post on SharePoint 2010: Content Type Hubs – Publish and Subscribe to content types
Below are some of the limitations/FAQ about content type hubs: from here
1. Which field types are supported?
Custom fields and external data columns are not supported(you cannot create external data columns in the content type gallery).
2. What happens if a web application is member of two different Content Type Hubs?
The default Managed Metadata Service(MMS) gets the priority and will be your content type hub. However, if you customize the service application associations for the web application, you can select the appropriate MMS application proxy for the content type hub.
3. What happens if a user changing a synchronized Content Type inside the Target Site Collection?
The subscribed content types are marked ‘read only’ in the target site collection. Users are unable to manage/change the synchronized content types inside the target site collection. Changes to the content type should always be made in the content type hub and republihsed to push the changes to the subscribed sites.
4. What happens with content types within the sub-site structure?
Content type subscription is a site collection level feature, so you consume the content types in the top root web and it flows down the sub-sites.
5. Are Workflows supported and if yes what are the limitations?
Unfortunately workflows are not supported. However, once you have your content type published to the target site collection, you can create and associate workflows to the subscribed content types in the target site. But doing so, I have encountered issues such as the workflow association being removed once the content type is republished. A simple woraround is to create list workflows in the target site collection and not associate with the content types.
6. What happens with document templates?
Document templates associated with the content type are also published along with the subscribed content type.
7. What happens with Document Set content Types?
Yes, you can subscribe to document set content types. In this case, all the dependent content types with the document set & the document set itself will be published to the target site. However, you should have the Document set feature activated in the target site.
8. What about feature dependencies?
Feature dependencies are not activated automatically in the target site collection. Thus, they need to be activated manually before the subscription process, else the content type publishing job will fail in the target site collection for that subscribed content type. Best example is when you subscribe to document set content types. See 7.
9. Why cannot I publilsh my content type created in a (deployed) solution package (.wsp)?
Content types created via object model should use the new SPContentType constructor to create content types which allows you to specify the SPContentTypeId for the new content type. Visit Nick’s blog post for more info on this. You can also script the creation of content types using PowerShell, which is another option.
Apologies for the confusion. You are able to publish content types deployed from a solution package (.wsp) – whether you use CAML or server object model or client object model. You can also download a sample VS2010 solution to try the same – http://db.tt/syK0C1a
Please do leave a comment if you want to add more to the list. I am sure I haven’t covered everything, so will update this post regularly.