A customer recently reported that they were not able to create any new Site Collections within any Web Application in their SharePoint 2013 UAT environment. Instead of being able to create a new Site Collection they repeatedly received the error shown in the image below.
I in order to troubleshoot this issue I tried creating a Site Collection myself while monitoring the ULS logs. An event with an ID of 8307 was appearing in the logs each time I tried to create a new Site Collection. This event had a message of “An exception occurred in Forms claim provider when calling SPClaimProvider.FillResolve(): Provider must implement the class ‘System.Web.Security.MembershipProvider’. (C:\inetpub\wwwroot\wss\VirtualDirectories\34596\web.config line 606)”.
This suggested a problem with the web.config for the Central Administration Web Application and an error with a Membership provider. Forms Based Authentication (FBA) has been used to configure FBA in this environment so I continued exploring this avenue further.
I reviewed the web.config at the line indicated from the event and noticed that there were multiple entries for FBA membership and role providers. I removed these duplicate entries and was able to create Site Collections without any problems then.
As the Forms Based Authentication in this environment was configured using the FBA Configuration Manager I can only think that this was at fault somehow – the odd thing is that the same tool was also used on to configure the production environment which I also confirmed was not also having the same issue.
I would suggest that after using the FBA Configuration Manager to configure FBA that you ensure you can create new Site Collections. It’s certainly something I am going to be including to my deployment checklist!
A customer asked me if I could help troubleshoot their SharePoint environment – they had extended a web application and configured it to use Forms Based Authentication (FBA) with SSL however they were getting errors when accessing the new site.
I started troubleshooting the configuration across all the servers in their SharePoint 2013 farm. I stepped through the configuration for the web application in Central Administration – reviewing the authentication provider settings and alternate access mappings. I then reviewed the web.config and made sure that the FBA settings were present and correct along with the IIS website bindings. This is when I noticed that there was no hostname against the https/443 binding – the option to add one was also disabled.
After a little research, I found an article from ArmgaSys. It turns out that my customer’s wildcard SSL certificate was issued without an * in the name, therefore, the hostname cannot be specified once the SSL certificate is selected. I followed the steps in this article from and the customer was able to access their SharePoint site without any errors this time.
A summary of these instructions are included below: –
To resolve this and make the hostname field editable launch Microsoft Management Console (MMC) and open the Certificates snap-in.
Locate the wildcard certificate, right click on it and select properties.
If the Friend Name property doesn’t start with a * then add one and apply any changes you make.
Now go back to IIS and select the SSL certificate in the bindings of the SharePoint website with the issue.
The hostname field should now be editable where you should then enter the hostname for your SharePoint site.
I’ve been there at least once or twice and I’m sure others have as well – where we’re happily modifying the web.config on half-a-dozen or more servers and as Steve so elegantly describes it, we “fat finger some random part of a web.config change” causing complete devastation to the running of SharePoint and to your progress. Well not any more my sysadmin friends, not any more not with this tool. It allows you to edit the connection string, people picker wildcard, membership provider, role provider details within the web.config for a specific web application. It then creates a backup copy and updates the web.config across all the servers in your farm through a timer job which is a really neat trick.
Having done this now on several occasions I thought I was pretty confident flying through the steps necessary within an hour or so…the occasional error would sneak in and then I would spend as long again troubleshooting the configuration. Steve’s Forms Based Authentication Configuration Manager has now completely removed the chances of any errors sneaking in and will make me even quicker configuring FBA in SharePoint. Thank you, Steve!