setup on an https site

Sep 15, 2011 at 8:35 PM

I've noticed a few people with references to problems on SSL secured sites. One person commented, " I found that if you setup SSL on an extended web application vs. just an AAM and perform the configuration against the extended web application then it appears to work fine."

Has anybody been able to make this codeplex solution work without this workaround?

If so, did you have to do anything in addition to the standard setup instructions?

If so, what?


Dec 7, 2011 at 10:00 PM

From experience, AAM should never be used on their own to map/enable new zones in SharePoint (such as when you want to add an https URL or an additional URL to an existing WebApp). I know there are tons of blogs out there showing you how to do this using AAM. It seems to work fine but doing it this way will eventually get you into trouble. One of those cases is when playing with authentication providers, but there are other cases, trust me. You should always extend WebApps to add URLs.

The reason is the SharePoint object model in many case, but not all cases, expects to find a WebApp objet behind a Zone, such as when assigning custom login pages (it’s assign to the WebApp, not the zone) or adding a new provider (same thing here). If you just add a new AAM URL to a zone to have an additionnal https URL it won’t create that necessary WebApp objet. I have read that Extending WebApp eats up unnecessary resources. Wrong! It’s a simple IIS binding to the same instances of the SharePoint code (same AppPool) so it’s negligible.

Use AAM (Internal and/or Public) only to tweak URLs when doing URL rewrite with devices such as Load-Balancers, proxy servers and firewalls. It’s why MS invented AAMs.

So if you want to use this solution and possibly prevent future issues (if you have used AAM to create new zones) extend your WebApp with the new URL so that you have a WebApp for every single one of them.