Partager via

Central Administration and Alternate Access Mapping (AAM) (issues with Content Deployment and SP1)

  • Article

A few months ago, I had to debug an issue where Content Deployment was not functioning correctly.  As soon as the Import process was starting, we were either experimenting an HTTP 400 error (Bad Request) or a "...this file type is blocked..." error.  We couldn't figure out what was going on as everything was functioning correctly across the farm.

 

The "blocked file type" error simply happens when you try to contact the web service on a different web site than the Central Administration while an Http 400 error occurs (usually) when IIS cannot determine which web site should respond to the request.

 

I was able to figure out when I looked at the Alternate Access Mapping (AAM) configuration.  While everything looked right at first, the only thing I could see that was different than my test environments were that the Central Administration web site's default zone was configured with a load-balanced URL.  What that does is set the IIS configuration so that the Central Administration responds to the Fully Qualified Domain Name that you specified.  Unfortunately, Content Deployment works with the server name and no IIS web site was responding to this name.  You can "guess" this when you set Content Deployment general parameters and specify which server should receive incoming requests (only server names appear).

 

So it's all good, we added an intranet zone with the server name + port number and that was the end of the story.  Then came along SP1 ...  While installing the WSS SP1 Language Pack (at least, the WSS & MOSS SP1 worked), we got the following error :

 

Exception: System.ArgumentException: The IncomingUrl is already present in the collection in a different zone.  A url may only map to one zone at a time.  Use a different url for requests from this zone.

at Microsoft.SharePoint.Administration.SPAlternateUrlCollection.Add(SPAlternateUrl alternateUrl, Boolean fUpdate, Boolean throwIfExists)
   at Microsoft.SharePoint.Administration.SPAdministrationWebApplication.Provision()
   at Microsoft.SharePoint.Administration.SPWebServiceInstance.Provision()
   at Microsoft.SharePoint.PostSetupConfiguration.CentralAdministrationSiteTask.ProvisionAdminVs()
   at Microsoft.SharePoint.PostSetupConfiguration.CentralAdministrationSiteTask.Run()
   at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

 

At least, the error was leading me to the AAM configurations again.  It turns out that the default zone has to be the "server name + port" or else the SP1 Language Pack process will fail.  As soon as you modify the default zone, the process will pick up and you'll be fine.

 

Maxime

Comments

  • Anonymous
    February 13, 2008
    As you probably have read, I ran into a couple issues lately with Content Deployment ( Slow with SP1?

  • Anonymous
    February 13, 2008
    As you probably have read, I ran into a couple issues lately with Content Deployment ( Slow with SP1

  • Anonymous
    February 18, 2008
    SharePoint's Content Deployment feature is a very complex functionality that, unfortunately, does not

  • Anonymous
    February 18, 2008
    SharePoint's Content Deployment feature is a very complex functionality that, unfortunately, does