This project has moved and is read-only. For the latest updates, please go here.

Post install, "The Security Token Service is not available" on non-WFE servers

Mar 1, 2014 at 8:34 PM
I've been able to get the provider successfully installed, but after installing I soon see...

"The Security Token Service is not issuing tokens. The service could be malfunctioning or in a bad state.

Administrator should try to restart the Security Token Service on the boxes where it is not issuing tokens. If problem persists, further troubleshooting may be available in the KB article. For more information about this rule, see ""."

I've tried restarting the Security Token Service, but the error prevails. Is this expected?

Mar 5, 2014 at 6:11 PM
Edited Mar 5, 2014 at 6:12 PM
I never had this error and it's very strange: LDAPCP is not involved in authentication process, so "Security Token Service" component that should even not call it, so I have no explanation why you get this error message.
You should check SharePoint logs, and you can monitor LDAPCP activity if you filter on category "LDAPCP"
Marked as answer by isujason on 3/5/2014 at 4:39 PM
Mar 6, 2014 at 12:38 AM
Turned out to be even simpler than I thought. I watched the logs like you suggested and the error was because it couldn't find the dll. I'm assuming if all my servers were running the web application service the wsp would have pushed the dlls everywhere? Further assuming that because not all my servers are running the web app service that's why only my front-end had the necessary dlls.

Once I copied the appropriate dlls to my assembly\GAC_MSIL directory on my non-FEs, did iisreset, all was well in the world!

Thanks for the suggestion! That got me going in the right direction.
May 13, 2014 at 8:34 AM

(I also thank you for the solution)

I also have this issue in that the solution is only deployed on WFE servers and the central admin server but not on the other servers in the farm. Once deployed all the remaining servers fail to issue security tokens thus causing any services on them to fail. This is a major issue for us as all our search servers in our search topology do not install the solution causing search to fail farm wide on all sites.

The issue is immediately fixed by manually copying the files into the GAC. Should the solution be modified so it is deployed on all servers or is there something else I am missing?
May 13, 2014 at 4:01 PM
this is because solution "Deployment Server Type" is set to "WebFrontEnd".
I could set it to "ApplicationServer" instead, but as far as I remember in my old tests, this setting copies the assembly in GAC of all SharePoint servers (which is great), but it does not activate the features.
Note that I may be wrong as I didn't test this for a long time, but that is essentially a choice between 2 imperfect solutions.
May 13, 2014 at 11:56 PM

When you say it does not activate the features do you mean on all servers or it does not activate on Application servers? When I test it the feature only needs to be activated on the WeFrontEnd servers but the files present on the other application servers.

I am yet to figure out why the security token service needs LDAPCP for server to server communication could this be due to the attributes I associated with the claims provider (I added SID)
May 14, 2014 at 12:45 PM
a feature activation applies changes in databases, not in servers (except some special cases like web app features that change web.config files), which get the files when solution is deployed.
The STS doesn't actually need LDAPCP, but it calls it to check if it supports claims augmentation (SupportsEntityInformation property, that is set to false in LDAPCP), this is one of the reason why the assembly must be present on every server.
I will test again the ApplicationServer "Deployment Server Type" and use it for future releases if it works fine.
May 19, 2014 at 1:08 PM

here are the results of my tests with solution "Deployment Server Type" set to "ApplicationServer":
When solution is deployed:
  • Assembly is copied in the GAC of every server
  • Features are NOT installed, and require to run Install-SPFeature cmdlet for each feature in the solution:
    Install-SPFeature "LDAPCP"
    Install-SPFeature "LDAPCP.Administration"
    After cmdlets are run, they activate immediately, so Enable-SPFeature is not required.
But the big problems start when you want to uninstall the solution:
Retracting the solution deletes the files in features folder and removes the assembly from the GAC, but it does NOT actually remove features from SharePoint:
  • Feature "LDAPCP" is deactivated but not removed. Still it can be removed easily with Uninstall-SPFeature cmdlet
  • Feature "LDAPCP.Administration" is not deactivated, nor it is removed, and Disable-SPFeature cmdlet fails because SharePoint does not find corresponding files in features folder (of course, they were removed when solution was retracted). From this point it's quite a pain to fix as files must be recreated manually in features folder, to be able to deactivate and uninstall this feature.
Considering the pain it is, I made the choice to leave "Deployment Server Type" of the solution set to "WebFrontEnd", and clearly document that assembly requires to be manually added in the GAC of servers that don't run "SharePoint Foundation Web Application" service

Marked as answer by Yvand on 5/20/2014 at 4:27 AM
May 20, 2014 at 1:07 AM
Hello Yvand,

Thanks for that. Yes it looks like it is an easier way to go to avoid people touching production databases or having to use some sort of custom installer.
Jan 6, 2015 at 10:49 PM
Edited Jan 6, 2015 at 11:23 PM
Hi Yvand,

Thanks for the wonderful tool and continuous support.
I am also working in the same environment as the original poster.
When i installed the solution, it got deployed to only the APP server and the Dll was also copied to the App server GAC. The features LDAPCP and LDAPCP.Administration were also installed on APP. I was able to see the pages added to the Security tab of the Central administration. But, nothing was there on the FE servers. I copied the DLL and the Feature folders to the respective locations on both FEs. But the user names are not still getting resolved in the people-picker.

The claim types and are showing GREEN in the claims table page. The claim types,,, are RED.

I haven't added any LDAP connection in the LdapcpSettings page yet.

Below are the relevant Log entries,
[LDAPCP] Connect to AD this server is member of, with application pool credentials
[LDAPCP] This LDAP query did not return any result: "(| (&(objectclass=user)(*)) (&(objectclass=group)(*)) (&(objectclass=user)(*)) (&(objectclass=user)(*)(!(objectClass=computer))) (&(objectclass=user)(*)) )"
Please let me know what else i am supposed to add or remove.