Are local term sets still problematic in Back and Restore scenarios


  • Sometime back I had read this article for SP2010 Local Term Sets

    Beware Local Term Store!

    Is this the case in SP2013? or is there a solution to the site backup/restore and local term stores?

    For very large farms ... global term stores are a big pain because the Central admin has to be involved. But admins like me are busy guys.

    there was a powershell script workaround published here

    Beware Local Term Store - Continued (with good news, too!)

    Is this workaround still required? or sp2013 is intelligent enough to handle backup and restore on its own? without requiring recreation of the connection?

    val it: unit=()

    Thursday, April 25, 2013 11:46 PM

All replies

  • bump!

    val it: unit=()

    Wednesday, May 1, 2013 5:29 PM
  • The article with the script is gone! Help anyone?
    Wednesday, December 18, 2013 10:18 AM
  • is your friend!

    Here is the whole text from there:

    Beware Local Term Store - Continued (with good news, too!)
    Sergey Zelenov

    ​Following up on my post on May 6th - it turns out it is perfectly possible to restore a link between a site collection and a local term store group!!

    Just run the function below against an affected site collection, and it should put it right again (this will only work for site collections restored to the same web application, of course - or one associated with the same instance of Metadata Service Application).

    function Restore-SPSiteLocalTermSetAccess
        param (
            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";        
            if ($site -isnot [Microsoft.SharePoint.SPSite])
                $site = Get-SPSite -Identity $site;
                Write-Verbose -Message ("Bound to site collection {0} at {1}" -f $site.Id, $site.Url);
            $ts = Get-SPTaxonomySession -Site $site;
            ## Obtain the ID of the term set group from the root site property bag
            [guid]$sgroupid = $site.RootWeb.AllProperties.Keys | 
                Where-Object `
                    $_ -like "SiteCollectionGroupId*"
                } | 
                    Select-Object -Property @{n="GroupID";e={$site.RootWeb.AllProperties[$_]}} |
                        Select-Object -ExpandProperty GroupID;
            $sgroup = $ts.DefaultSiteCollectionTermStore.Groups[$sgroupid];
            if ($sgroup -eq $null)
                throw "Target term store group could not be found!"
            Write-Verbose -Message ("Found term set group: '{0}'" -f $sgroup.Name)
            ## Remove the 'old' (prior to backup/delete/restore) site collection ID from the group access list
            $sgroup.SiteCollectionAccessIds | 
                Foreach-Object `
                    Write-Verbose -Message ("Removed ID '{0}' from the Site Collection Access List" -f $_);
            ## Add the current site collection ID to the group access list
            Write-Verbose -Message ("Added current site ID ('{0}') to the Site Collection Access List" -f $site.Id);
            ## Persist the changes in the database - very important!!
            Write-Verbose -Message ("Commited all changes to term store '{0}'" -f $sgroup.TermStore.Name);
            Write-Output -InputObject ("Site collection's access to term store group '{0}' restored successfully" -f $sgroup.Name);

    Friday, March 13, 2015 9:00 AM