Be Wary of Powershell Tab Complete!!

  • Article

This post is just a quick warning to be wary – or at least aware of – the tab complete functionality in Powershell. I had a customer contact me today and tell me that they had inadvertently hosed their SharePoint 2010 Claims enabled site. The email went something like this…

We were trying to modify the name property of an SPClaimProvider object and after doing so all claims authentication to our SharePoint site began failing. (I will hopefully be able to show some error messages and additional symptoms in a future post, but I don’t have those details at the moment). The sample Powershell that they showed me was as follows:

 $ap= Get-SPClaimProviderManager  
$ap.Name=”Custom Text” 
$ap.Update()

Now I actually didn’t have to do much work to figure out where the problem was as they were kind enough to tell me. They had accidentally called Get-SPClaimProviderManager instead of Get-SPClaimProvider. After doing this, all of their claims authentication stopped working.

Our first attempt at repairing this was the obvious “Let’s try to revert the Name property with the same code and set it back to the default Name of ClaimProviderManager”. However at this point when they called Get-SPClaimProviderManager they were met with the following error from Powershell:

Get-SPClaimProviderManager : The claim provider manager is not available in the farm.

At line:1 char:27

+ get-spclaimprovidermanager <<<<

+ CategoryInfo : InvalidData: (Microsoft.Share...ProviderManager:

SPCmdletGetClaimProviderManager) [Get-SPClaimProviderManager], InvalidOperationException

+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletGetClaimProviderManager

After some cursory research into this (not full testing), it appeared that SharePoint Server 2010 can only have a single SPClaimProviderManager and that it *must* have the default name of ClaimProviderManager.

Resolution:

***WARNING***

The following TSQL query is *NOT* to be executed against a live production configuration database. You should make a backup copy of this database and restore it to a non-production SQL instance in order to run this query.

***WARNING***

In order to resolve this we had to do a simple SELECT into the SharePoint 2010 ConfigDb to find the guid of the ClaimProviderManager:

 SELECT [Id] 
   FROM [ConfigDb].[dbo].[Objects] WITH (NOLOCK)
     WHERE [Properties] LIKE ‘%SPClaimProviderManager%’
             AND [Name] LIKE ‘%Custom Text%’

Note that if you get more than one result from the above query, then you may need to do some more research to get the correct Id. After you find the guid of the ClaimProviderManager, then you can use the following Powershell to reset the Name property:

 $farm = Get-SPFarm
 $guid = New-Object –TypeName System.Guid–Argumentlist (,”<guid from SQL>”)
 $claimprovidermanager = $farm.GetObject($guid)
 $claimprovidermanager.Name = “ClaimProviderManager”
 $claimprovidermanager.Update()