Master Site Directory in Sharepoint 2007 Error

I ran into an error when trying to assign a master site directory in MOSS 2007 Central Admin:

This not a valid site directory. Specify a URL to a site that is using the site directory template.

I checked that the URL was valid and that it was pointing to a Directory Site. I even created a new directory site and tried that with no luck.

I worked out that if I set the default public URL to be a simple name like site, instead of site.domain.co.uk, the master site directory page accepts the entry and it all works. However this is no good as we need a proper FQDN as the default public URL (and changing it back after setting the MSD breaks the MSD functionality).

I have a call open with Microsoft through ESCUK about this. This call has been dragging on for a long time and somehow Microsoft have not been able to reproduce the problem.

I'll keep this post updated as and when I hear something back from Microsoft. I would be very interested to hear if anyone else is seeing this problem so I can feed back to Microsoft. Thanks!

07/01/08

Microsoft have finally reproduced this problem and have acknowledged it as a 'possible bug', as such it has been escalated. No news as to a fix yet.

23/01/08

Today I had a call from a developer at Microsoft who has been looking through the code used by the Master Site Functionality and established that it first checks for the existance of the site in the configuration database. This is interesting because apparently if it does not find the exact URL in the config database it will reject it. This means that if you use a different default AAM to the URL you used when creating the web application that hosts your MSD, the lookup will fail. The only way I know of to fix this is to extend your web application and use the URL of your default AAM as the URL for your new IIS site and set this extended web app to use a different zone (i.e. Intranet). The default AAM URL will end up the default AAM for two different zones and will now appear in the configuration database (as it is added by Central Admin when you use it to extend the web app). This is not pretty and I don't advise you go ahead with it in the production environment without taking advice from Microsoft.

Fortunately our default AAM was also the URL that was used to create the original web application used to host the MSD. Therefore the work around above is not appropriate. Back to the drawing board......

Quick thought...... if using NetBios names fixes the problem, what could be happening differently for FQDNs. Perhaps a proxy issue. However I have made sure that our proxy is configured to be disabled for the application pool and service accounts. However each web application's web.config file by default sets the proxy to auto=true. The developer at Microsoft suggested changing this to false for the Central Administration web application. That did the trick! We now have a full functional master site directory. It was a very long time coming for a simple solution, but a good learning experience.

To make this change go to C:\Inetpub\wwwroot\wss\VirtualDirectories\****, where **** is the port number of your Central Admin site. If you are not sure which is the right virtual directory open IIS Admin, right click on the Central Admin site and choose Explore. Right click in the white space to the right and select properties to get the folder and path. Open the web.config and locate the following:

(system.net)
(defaultProxy)
(proxy autoDetect="true")
(/defaultProxy)
(/system.net)

Change to:

(system.net)
(defaultProxy)
(proxy autoDetect="false")
(/defaultProxy)
(/system.net)

You will also need to do this for any web applications that you want to create Site Collections from within a Site Directory page (and make use of the Master Site Directory feature). Hhowever if you do this you may want to use something more like below so that web parts like RSS readers can connect to external feeds.



This adds exceptions for *.domain.local.com and 198.168.*.*

I hope this saves someone a lot of time!