App Pool for FBA Site

[techiet]

Hello. I inherited two farms with FBA configured already. The PROD farm has the FBA site in the same application pool as the external webapp. The QA farm, has the FBA site in a separate application pool. We’re having some trouble with the PROD farm and this is the only difference. So, I’d like to make PROD match QA. Can you tell me, would be just as simple as creating the additional application pool and then changing the application pool association in IIS? Or is there some other complexity that needs to be considered?
Thank you so much for any thoughts you can offer.

[ccoulson]

What are the problems you are having on the prod farm? Having a single application pool for the internal and external access shouldn't affect it's ability to login with FBA. It's more likely a configuration error of some sort. If you would like to have multiple application pools, you can't just add additional application pools in IIS. You have to use SharePoint Central Admin and 'Extend' the web application - this will create a separate web application in IIS.

[techiet]

Thank you so much for your reply.

The issue we see in Production is that SP 2013 is “acting like” SP2010. We have no issues at all with how FBA is functioning. We have the 2010 codeplex solution deployed but it is a 2010 farm. The solution is deployed to a site collection that still has the 2010 look and feel. (That’s a long story.)

When we create a subsite, we get the “Processing” screen that 2010 used to give instead of the “working on it…” screen that 2013 gives.

We’ve looked at every configuration we can think between the webapps, including compatibility settings.

And, we don’t have the issue in our QA environment which is built identically save for the fact that the FBA site is sharing an application pool in PROD where it has its own in QA.

We’re not looking to extend our web app in PROD as we didn’t need to in QA.

My thought is that is has to do with how FBA was deployed in PROD that it placed it’s inetpub files in the same app pool?

I’ve been reading the FBA configuration article that you posted but am not finding where the pool can be added/modified.

MSFT is requesting that we try to move which pool it is in to make it mirror QA but since that is not the issue we contacted them about and since we have the codeplex solution, it is not something they will support, so I thought I might inquirer here.

Unfortunately the vendor that built the farms did not document the FBA configuration process that they went through so I am trying to backtrack a bit.

Thank you again for your response. If you have any additional thoughts, we’d appreciate them but understand if this is more of “support” thing than just quick question.

Tollie Contento
Business Systems Analyst Lead, IS BI & Collaboration
AmeriHealth Caritas Family of Companies

P: 215.937.8598
E: [email removed]
www.amerihealthcaritas.com

[ccoulson]

I can't say I really understand:

" We have the 2010 codeplex solution deployed but it is a 2010 farm. "

If it's SharePoint 2013, you will need the SharePoint 2013 FBA Pack installed on it - the 2010 version won't work as they use different versions of the .Net runtime. If this really is 2013, the app pools should say they are running .Net 4.0 (2010 app pools will say they are running 2.0).

Maybe i'm also not following you about sharing the app pool - sharing with what? The main thing to get across though is that app pools/sites etc... should all be created by SharePoint itself, and it's not something that you do directly in IIS.

[techiet]

Greetings.

I misstyped. We have a 2013 farm. The FBA solution is deployed to a site that is still in the 2010 look and feel but the backend is 2013.

The team that built the 2013 farm last year (and migrated in all of the previously hosted 2010 content) have the FBA solution files unzipped into a folder labeled SP2010, and since it is deployed to a site with the 2010 look and feel, the assumption has been that they deployed the 2010 solution to the farm. This is further supported by other information that was left behind, like the solutions they received from the prior vendor that hosted the 2010 platform, which again, was the 2010 version. They’re not available for me to ask how this all went down. I know the 2010 solution should not work on the 2013 farm so is there a place I can look to see the version number of what was deployed? If not, then, as you say, it must be the 2013 solution.

As for the application pools, I hope the attached pictures can help clarify. To confirm and clarify, we don’t create app pools in IIS directly.

I am just confused as to how our “FBA site” could have its files sharing an application pool in one farm but not in the other.

I thought it might relate to how the solution was deployed and I have a feeling that the implementation team did not deploy it the way you documented that it should be. I found the powershell below on one of the servers:

install-spsolution -identity visigo.sharepoint.formsbasedauthentication.wsp -compatibility {14,15} -webapplication https://portal-dev.amerihealthcaritas.com –GACdeployment.

Or, I’m completely misunderstanding where the “External FBA Configuration” sites are coming from and it has nothing to do with this solution. Which is possible. J

All that said, the issue we’re having isn’t with the FBA solution in any of our farms. The issue exists only in Production and it is that when we create a subsite or upload a document we get the 2010 “Processing” screen and not the 2013 “Working on it…” screen. MSFT has been looking into it with me and suggested that I try to find out more about why QA differs from PROD in this aspect, which centers around the fact that FBA “shares” an application pool in PROD.

I truly want to thank your time. I know this is an odd one and I don’t want to waste your time on something that isn’t directly related to the successful function of your product, which as I mentioned, works like a charm! I’ll keep working with MSFT and if anything should arise that does relate back to this, I’ll be sure to let you know.

Thanks again.