I am having a really strange issue with Managed Metadata. I get the classic Error “The Managed Metadata Service or Connection is currently not available” which is usually a permission issue.
However, all the good accounts have permission. In the ULS Logs this is what I found :
Failed to get term store for proxy ‘Managed Metadata Service’. Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at Microsoft.SharePoint.Taxonomy.Internal.XmlDataReader.GetDateTime(String name)
at Microsoft.SharePoint.Taxonomy.Internal.SharedTermStore.Initialize(IDataReader dataReader, Guid termStoreIdValue, Boolean fromPersistedData)
at Microsoft.SharePoint.Taxonomy.Internal.SharedTermStore..ctor(IDataReader dataReader, Guid termStoreId, Boolean fromPersistedData)
at Microsoft.SharePoint.Taxonomy.Internal.DataAccessManager.GetTermStoreData(MetadataWebServiceApplicationProxy sharedServiceProxy, Boolean& partitionCreated)
I only found 1 blog post on the issue: http://sharepointbabe.blogspot.ca/2013/04/upgrade-managed-metadata-service.html however I was maybe trying to fix before recreating. And for me it’s pure 2013.. no 2010 in there!
This error occurs when the [dbo].[ECMChangeLog] table is empty. As a result, the ChangeTime returned by [dbo].[proc_ECM_GetSessionData] is null. This stored proc is invoked while initiating a session. Since mine was in a non-prod environment, I managed to resolve this with the following steps:
1. Modify the stored procedure: [dbo].[proc_ECM_GetSessionData] so that a non-null value is returned for ChangeTime
ISNULL(max(ChangeTime),GETDATE()) AS ChangeTime
2. Now you should be able to see the TermStore. Make a change say add a term store administrator, save and then remove. With this, the ECMChangeLog table is populated.
3. Revert the change made to the stored procedure.
max(ChangeTime) AS ChangeTime
I was facing the same error. In my case I was using and existing application pool account to create the MMS. Using a new application pool account solved the problem
I noticed this same issue in our farm recently.
What is the impact of recreating the service application? I’d prefer to do this during business hours if possible.
Today i saw this error in my environment. After reading many posts started troubleshooting from simple commands to more complex. At least restore of the service application from yesterday’s farm backup solved the problem for me 🙂
I had the same trouble where I was unable to get the service back working with the existing database. Found a way around this that worked out without having to restore the data. I did a quick post on it: