Thursday, October 2, 2014

Error with timer job, deploying solutions and get-sptrustedtokenissuer

Note: Below recommendation should never be tried in a production environment. Completely unsupported by Microsoft.

My colleague recently ran into an issue with deploying solutions and running Powershell commands related to Trusted token issuer...The error message was very cryptic, "Invalid URI: The URI is empty".

Below is how the Powershell command looked like:



We googled and found lot of articles related to timer job and clearing cache by going into C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\ folder. But none of suggestions worked. Looking at the logs, we found the below:

The SPPersistedObject with Name CustomSTS, Id b98a7f69-5c38-46dd-9be8-4f8aaced5233,
Parent 3e0eff9b-340a-46ce-95ca-6142cea8fe4f failed to initialize with the following error:
System.UriFormatException: Invalid URI: The URI is empty.   
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.DeserializeBasicObject(XmlElement xmlValue, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlNodeList childNodes, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlDocument value, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPPersistedObject.Initialize(ISPPersistedStoreProvider persistedStoreProvider, Guid id, Guid parentId, String name, SPObjectStatus status, Int64 version, XmlDocument state)

System.UriFormatException: Invalid URI: The URI is empty.    
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.DeserializeBasicObject(XmlElement xmlValue, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlNodeList childNodes, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlDocument value, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPPersistedObject.Initialize(ISPPersistedStoreProvider persistedStoreProvider, Guid id, Guid parentId, String name, SPObjectStatus status, Int64 version, XmlDocument state)    
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.GetObject(Guid id, Guid parentId, Guid type, String name, SPObjectStatus status, Byte[] versionBuffer, String xml)    
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.FetchObject(Guid id)   
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.GetObject(Guid id, Boolean checkInMemoryCache, Boolean checkFileSystemCache)   
at  Microsoft.SharePoint.Administration.SPConfigurationDatabase.Microsoft.SharePoint.Administration.ISPPersistedStoreProvider.GetObject(Guid id)    
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.get_Item(Guid objId)    
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.d__0.MoveNext()    
at Microsoft.SharePoint.PowerShell.SPCmdletGetSPIdentityProvider.RetrieveDataObjects()   
 at Microsoft.SharePoint.PowerShell.SPGetCmdletBase`1.InternalProcessRecord()    
at Microsoft.SharePoint.PowerShell.SPCmdlet.ProcessRecord()   



Just before we decided to rebuild the farm, I decided to look at the SharePoint Configuration database as last resort (again strictly not recommended for production database)


I ran the below query:

SELECT [Id]
      ,[ClassId]
      ,[ParentId]
      ,[Name]
      ,[Status]
      ,[Version]
      ,[Properties]
  FROM [dbo].[Objects]
  where properties like '%CustomSTS%'
GO

Replace CustomSTS in the query with whatever you think is appropriate. Sometimes you might not see any rows come back. You will need to re-start your research at this point.

I backed up the database and deleted the entries from the above output. Went back to powershell and ran the command again. Voila ! It ran perfectly with no issues. Same with deployment of wsp files.

Thanks to my colleague who let me debug this for him. His machine will be rebuilt soon as it was completely hosed before this.

Hope you never need to do this !



No comments:

Post a Comment