The managed metadata service in SharePoint 2010 makes it simple to realize an enterprise taxonomy across all site-collections in a farm, or even across farms. In addition, the managed metadata service (MMS) application can be syndicated, that is, you can have multiple instances of the MMS and they can all be consumed in combination as one by web-applications. You can have multiple instances of the other service application types, but only one of them can be the active default association in a consuming web-application.
The Managed metadata service application overview on Technet used to have a nice example scenario of managed metadata term store and content type syndication across multiple departments in a company, in the page published on April 16th. As the example scenario has been removed in the page published on May 12th, the following figure shows the MMS syndication example:
For those of you who speak Spanish, or want to run it through Google translate, the managed metadata syndication example is still available here: http://technet.microsoft.com/es-es/library/ee424403.aspx
The salient point of the example is that the HR, IT, Products and Legal departments all share a common base term store and content type hub, allowing for the Products department to extend the base with its own term store and content types, and allowing the Legal department to have its own private term store while syndicating both the Global and Products managed metadata services.
An important detail in the example is that the Legal department uses term sets to represent confidential information. Therefore, it requires its own term store that prohibits other departments from seeing the confidential terms, even as new terms and term sets are added. Thus, the Legal department requires its own default term set location to prevent new confidential terms being added to the Global and Products managed metadata services.
This scenario is quite possible to realize as the two managed metadata service connection setting Default keyword location and Default term set location allows for specifying per MMS connection if this is the MMS term store where new keywords and column specific term sets will be added. However, as these options are set on the "Managed Metadata Service Connection" proxy itself rather than on the web-application "Service Application Associations" settings, there is a problem for the example scenario.
All web-applications in a farm share all service applications, connection proxies and proxy groups defined in the farm. The example scenario requires the IT, HR, Products and Legal web-applications to all be connected to the "Global Managed Metadata" service. As indicated by the red markup in the above figure, the web-apps require a different setting for default term set location - Legal requires "no", the others "yes". Thus, they cannot use the same MMS connection, a second connection is needed. However, you cannot add another local service application connection from Manage Service Applications, only cross-farm connections can be created from Central Admin .
The solution is to use PowerShell to add a new Managed Metadata Service Connection with the command New-SPMetadataServiceApplicationProxy using the -ServiceApplication parameter, rather than the -Uri parameter used for cross-farm connections.
New-SPMetadataServiceApplicationProxy -Name "MMS_PX001" -ServiceApplication "MMS2"
Some other parameters are:
-DefaultKeywordTaxonomy: This service application is the default storage location for keywords.
-DefaultSiteCollectionTaxonomy: This service application is the default storage location for column specific term sets.
-ContentTypeSyndicationEnabled: Publish content types from the content type hub.
-ContentTypePushdownEnabled: Push-down updates from the content type hub to subscribers.
-DefaultProxyGroup: Add this connection to the service application associations [default] proxy group.
Don't add your custom MMS syndication connections to the default proxy group as you will need to configure the service application associations per web-application that subscribes to a syndicated set of managed metadata services, typically using the [custom] proxy group. Additional custom proxy groups can be created in the farm using the New-SPServiceApplicationProxyGroup PowerShell cmdlet.
Note that as there are two term set "default" settings, there are four possible combination of MMS connection configurations for terms. Thus, four MMS connection variants must be created to cover all possible scenarios per managed metadata service instance. Then, each web-application can use its own service application associations [custom] proxy group to pick the applicable set of MMS connections.
Make sure that each proxy group has only zero or one default keyword location and default term set location. Having zero for either will prevent users from adding new keywords or new term sets. Having multiple defaults for either will cause an error as SharePoint cannot know in which of the locations to add new keywords and new term sets.
A final note about term store permissions: Access to the term store is granted per web-application using the app-pool account, not per user or group. In addition, you can control permissions on each term group using the "contribute" and "manage" settings for granting rights to users and groups. If users are not granted contribute rights, they will be restricted to read even if the web-application's MMS connection permissions allows for more than just read.
[UPDATE] This scenario will make incremental crawl of friendly URLs (FURL) fail in SP2013; and if you contact Microsoft Support you will get help from people who don't understand proxy groups, default proxy/MMS connection, default keyword location and default column-specific term set location settings, who will tell you that the product group confirms that the documented scenario on Technet is in fact not supported. Stay away from using SharePoint for anything else than a single department collaboration scenario, SP2013 is not built for real-life enterprise usage.