Does a extended web app/zone with an AAM fully mirror the original web app/zone?

Question

(I'm new to zones and AAMs so apologies if this question comes across a bit incoherent... I haven't really grasped how it all works yet.)

I have a Publishing site in SharePoint, running in a web app configured to use port 4444. When it was initially created it was only configured with the Default zone, which was using an internal URL only recognisable by the SharePoint server the web app is running on. (say http://localhost:4444)

Subsequently, to make the Publishing site publicly viewable, we set up a public URL to access the server. (say http://publicurl.com:4444). It seemed OK at first but then I realised that some URLs were still pointing to the internal server address, which obviously couldn't be resolved when accessing the site publicly. So I extended the web application to a new IIS web site on port 6666, and set this as the Internet zone.

So now we can access the site via http://publicurl.com:6666, and this seems to have solved the problem of the incorrect internal URLs. But I'm uncertain as to whether this extended web application, on the new zone, fully mirrors the original web app on the default zone. For example, I am using the MossMenu component with the CSS Friendly Adapters for my navigation. However I had to re-add the MossMenu to the SafeControls for the new web app (6666) in its web.config. And as of yet I still haven't got the CSS Friendly Adapters working for the new app/Internet zone, even though they work when using the Default zone and the internal URL.

So I guess my question is... does the extended web app/new zone fully mirror the original app/original zone, or are there usually a bunch of things I need to manually mirror? For example, say I deploy a new web part, would I need to deploy it to both the original web app and the extended web app?

Answer 1

The easiest way to think of it is this:

An extended web application is merley an additional IIS web site pointing to the same content. This web site will have a new folder under inetpub\wss\virtualdirectories with the default files within (including web.config)

This means that the extended web application will share the majority of settings with the source web application, but the IIS settings and contents of the default files are configurable (via the SharePoint tools - stsadm, powershell, central admin etc)

That explains why you had to add additional content into your web.config.

Answer 2

hmm it shouldnt be necessary to extend the web app. Normally you can define what you want by adding a new AAM. Extending zones is usually if you need seperate security context (extranet) or specific authentication (eg for indexing).

What exactly isnt working with the correct urls?

I can recommend the following ressources on AAM:

http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx http://blogs.msdn.com/sharepoint/archive/2007/04/18/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-3-of-3.aspx

Answer 3

What I´ve heard and read is that all new zones pointing to a new URL need a separate backing IIS site. If you don´t you could get all sorts of strange problems.

So if you want to access the same site on different URLs ( ie microsoft.com and ibm.com) then you must extend your application to a different zone with a separate backing IIS site for each URL or you will run into trouble.

I´ve never understood exactly what will break but document management issues will arise...

Anyone who can explain what will break?

From technet:

Note: We recommend extending a Web application to a new IIS Web site for each zone you want to use. This provides a backing IIS Web site. We do not recommend reusing the same IIS Web site for multiple zones, unless you are specifically told to do so by Microsoft.

http://technet.microsoft.com/en-us/library/cc288609(office.12).aspx