Partager via

Beware of Default Solution Deployments for Custom Claims Providers in SharePoint 2010

  • Article

Hey folks, one of my good friends Tom W (who authored the magnificent SharePoint 2010 Kerberos whitepaper at https://go.microsoft.com/fwlink/?LinkID=196600) brought up a good point the other day about limitations with solution deployment and the impact on custom claims providers the other day.  It's important to remember that when you develop a custom claims provider, it can be used in a number of places besides just the end user web applications.  For example, when you are trying to create web application policies in central admin, it will be used there.  When you are trying to configure user rights in My Sites it will be invoked there.  If you using the Secure Store Service it is called in there. 

The problem manifests itself as you build out bigger farms.  Since those services are calling into the custom claims provider framework, each custom claims provider needs to have its assembly put in the global assembly cache (GAC) on each of those servers.  However, by default the SharePoint solution deployment framework only deploys solutions to web front end servers.  When you look at the schema in fact for solution deployment, your only options for the DeploymentServerType is ApplicationServer or WebFrontEnd; what you really need is both.  That's because in these bigger farms you may not be running the web application service on  your app servers.  If you aren't, then your custom claims providers will  be missing from the GAC on those servers and if you try to use any of those features that call into the custom claims provider framework you will end up generating a whole bunch of errors since the assembly is missing.

Unfortunately the only work-arounds right now are to a) run the web app service on all servers in the farm, b) write a custom deployment job or event receiver or timer job or whatever to get it out to all the app servers or c) do it manually.  None of those options are particularly appealing, although I suppose I would pick a) if I had to pick one and just keep those servers out of the end user load balancing pool.

For now we just wanted to raise the issue so you are aware of it and can plan accordingly when needed for your farm.  Thanks again to Tom for pointing this out.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    April 15, 2011
    Hey Steve I wanted to see where you might store connection information.  Because the claims provider can be called from various applications as you mention, any connection or configuration information doesn't lend itself to be stored in the web.config.  Is there a better area to store this type of information that you could recommend?

  • Anonymous
    June 06, 2012
    Hello I solved the deployment problem using an isolated WSP that carries only the assembly where I defined the claimsProvider. I setted properties to allow GacDeployment and so assembly will go on each king of server. For parameters, I managed to put them in machine.config so that they can be used by several web apps, jobs and services. Hope that helps.

  • Anonymous
    July 03, 2014
    Microsoft SharePoint Foundation Web Application Role issue
    An alternative solution, can be to Start the service in Central Admin, and to avoid unnecessary resources consumption, Delete the IIS sites that are not required.