Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

(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?

share|improve this question
    
Problem is with "Edit this task" link. The url it redirects to is the absolute path with machine name of the production server (default URL) not the "Alternate Access URL" mapping. As this website is available on internet, users are not able to use this link. –  user4836 Sep 16 '11 at 8:46
add comment

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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

share|improve this answer
    
The main issue I was having was when browsing to a site logged in as an administrator, and then selecting 'Manage Content and Structure'. Before having set up the AAM and new Zone, I was getting a SharePoint 'File not found' error. (Same as this forum post: social.technet.microsoft.com/Forums/en-US/sharepointadmin/…). This was resolved after adding the AAM/Zone, but as you say maybe adding the new Zone was overkill in this case? –  ngm Jun 24 '10 at 10:43
add comment

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

share|improve this answer
    
Hi Fredrik, welcome to our site! You should probably start this as your own question :-) –  Anders Rask Jun 24 '10 at 13:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.