According to the MSDN article 'Managing Metadata in SharePoint Server 2010', "Local term sets are created within the context of a site collection. For example, if you add a column to a list in a document library, and create a new term set to bind the column to, the new term set is local to the site collection that contains the document library."
This definition is slightly confusing, as in reality, of course, a local terms set is 'local' in scope, but not in actual location - it is still stored in the central data repository of the Manged Metadata service application. In other words, every time you create a custom column of type 'Managed Metadata' and choose the 'Customize your term set' option, the associated Managed Metadata service application creates a new term store group, accessible only to the current site collection.
So, this is what I see in my library column settings:
And here is how it's stored by the Managed Metadata service application:
So far, so good - so why am I even writing about this? Well, the biggest problem is that using a local term store means the site collection cannot be easily backed up and restored - even to the same farm! So, if I were to take a backup of my site collection, delete it, and then restore it from backup, this would severe its connection with the term store group, the currently assigned values would get 'orphaned' (i.e. greyed out and unchangeable), and the next time I would try and access the properties of my 'Document Class' column, I would get a warning message:
You may ask why I would ever want to do such a thing as delete a site collection and then restore it from a backup - but in fact the need for such an operation is a lot more common than it may seem. Probably the most common scenario (and one that my customer actually got caught out by) is moving a site collection from one content database to another - but not on the same instance of SQL Server (in which case Move-SPSite cmdlet could be used).
A solution? Unfortunately, at this stage I cannot offer one - I've tried to restore the connection between a term store group and a site collection with a new id, but was not successful. All I can offer is this word of caution, and PowerShell function that will at least allow you to easily check whether a particular site collection has a local term store group associated with it, before you choose to delete it:
function Get-SPSiteLocalTermStore
{
[CmdletBinding()]
param (
[parameter(Mandatory=$true,
ValueFromPipeline=$true)]
$site
)
begin
{
if (-not (Get-PSSnapin | Where-Object {$_.Name -eq "Microsoft.SharePoint.PowerShell"}))
{
Add-PSSnapin Microsoft.SharePoint.PowerShell;
}
## Force the script to terminate on erros that would by default be treated as non-terminating
$ErrorActionPreference = "Stop";
New-Variable -Name tsgroups;
}
process
{
if ($site -isnot [Microsoft.SharePoint.SPSite])
{
$site = Get-SPSite -Identity $site;
}
if (-not $tsgroups)
{
$ts = Get-SPTaxonomySession -Site $site;
$tsgroups = $ts.TermStores[0].Groups |
Where-Object `
{
$_.IsSiteCollectionGroup;
}
}
$sitegroups = @();
$tsgroups |
Foreach-Object `
{
if ($_.SiteCollectionAccessIDs -contains $site.Id)
{
$sitegroups += $_.Id;
}
}
$site | Select-Object Url, @{Name="HasLocalTermSets";Expression={[bool]($sitegroups.Count)}}, @{Name="TermStoreGroupIDs";Expression={$sitegroups}};
}
end
{}
}
And here's what I get from running it against a set of site collections via the pipeline:
Take care!