Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Recently one of our SharePoint 2010 development servers died (OS related we think). I managed to get into the file system and grab all the SP databases (mdf's and ldf's). I rebuilt a new SP2010 machine from scratch and attached site collection databases and one MMS database to SQL. Then, for every content database restored I created a new web application, entering the name of that content database. No dramas there. I could browse the sites and all content looked to be intact.

I then went into the connections property of the Manage Metadata services and changed the database name from the newly created one to my old MMS database that I'd just previously attached. That seemed OK too. IISReset and I could then browse the old Term store. Good! But, since I previously had a content type syndication set up I needed to reproduce that. I entered the SC in the MMS connections properties. However, upon browsing to the "Manage Publishing for this Content Type" I received the following error in ULS:

"System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: index at Microsoft.SharePoint.Taxonomy.Generic.IndexedCollection`1.get_Item(Guid index)"

Also, interesting and expectedly enough, in the subscriber site collections, under Site Collection Admin -> Content Type publication, there is a reference to the old server and content type hub. So I tried creating a new MMS with the old database, and entering the new URL to the content type hub, forcing the hub and subscriber jobs, all to no avail.

Apart from trashing my source Content Types and building a new MMS from scratch, what are my options to get this working with the original MMS database. Any help would be appreciated.

share|improve this question
add comment

4 Answers 4

up vote 2 down vote accepted

I eventually figure this out.

The reason I was getting the error message above was I had only enabled MMS service application. (trying to be too memory thrifty). Not sure which service did the trick because I enabled all of them (default). The "Manage Publishing for this Content Type" screen didn't through an error now, ...well not until I click Publish. I then got a new error message, something about "No proxy set". OK, so there is still an issue with the connection. Of course this is because my Managed Metadata Service still has it's Content Type Hub value pointing to the old server. Come in PowerShell. Entered the command Set-SPMetadataServiceApplication. This takes a MMS Name or GUID and a HubURI. Once that was set to the new servers URL, I re-ran the Content Type Hub and Subscriber jobs and all was good.

share|improve this answer
    
@Anthony: Please mark this as the answer to your question. Thanks for coming back and providing it! –  Alex Angas Aug 17 '10 at 7:25
1  
I have that URI update as a step in all my Metadata Database restores, I also restore that DB after my Content DB so when the Content is updated and reset it pulls everything in sync. Though the huburi needs to be done separately, then it all works. –  MichaelF Jun 13 '11 at 12:35
add comment

Yes, Its a thumb rule that during the Content Type Hub migration, CT Hub site and its associated subscriber sites should be validated against its site column mappings(esoecially Managed Metadata columns) are linked with its MMS properly or not.

THanks Kandasamy

share|improve this answer
add comment

is your Managed Metadata Service set as Default to store column specific term sets?

you can check this in the Managed Metadata Service Proxy properties and ensure the check box is CHECKED for "This service application is the default storage location for column specific term sets.".

Praveen

share|improve this answer
add comment

I know got this has been answered already, but I had the same error with a different solution. My error was due to the fact that we were backup/restoring the content type hub but not the MMS. As a result, the managed metadata site columns needed to be re-associated with the new termstore. Once the new terms were associated with the site column, the error went away. Anyways, hope this helps somebody else out in the future.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.