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!

Sharepoint 2007 - Server Farm Configuration Not Complete

Along with many others my MOSS 2007 Farm has been running for some time saying that it's configuration is not complete.

This was starting to get annoying so I decided to investigate. I deleted all the Administrator Tasks and ensured all the services were running where they should be. I even went to the extent of ensuring everything that could be configured was configured. The only thing remaining was to switch on farm features that I did not want, so I switched on Excel Calculation Services and started the service on one WFE server. The message went away! I was then able to stop the service and switch off the feature and the message did not come back.

Sharepoint 2007 - Problem with Profile synchronisation and My Sharepoint Sites

We have another issue with Sharepoint 2007 in which one site collection and all of its subsites are not appearing in our My Sharepoint Sites list. I have run through all the basic tests and ensured that the right people are in the Site Members list and have even recreated the Site groups and added the members back in, but nothing works. More than this though, it seems that none of the profile synchonisation (a Sharepoint timer job) is being run against this site collection as any changes to users profiles from MySites/Profiles/directly on the SSP are not reflected in the people and groups pages on the problem site collection. For example if I delete my profile picture i.e.















This change is reflected everywhere but this site collection where it still attempts to reference it:


I used Quest Recovery Manager to restore this site collection so currently have an open call with them and depending on how things go will also open a call with Microsoft to see if they can offer a fix for this.


Any ideas or feedback greatly appreciated. As always I will update this post when I have a fix/workaround.

Office 2007 and Vista, persistent cookies do not work

I have run into another issue with SharePoint 2007 which specifically only affects Office 2007 running on Windows Vista.

We have SharePoint setup using ISA 2006 for forms based authentication. This works perfectly for XP/2003 with Office 2003/2007 and Vista with Office 2003. However when we open a document from SharePoint 2007 using Office 2007 on Vista, we are prompted for a password. This is rather annoying. I have opened a call with Microsoft to see if I can get to the bottom of this.

There are numerous articles out there saying that this is to do with IE Protected mode, but we have this switched off for the Intranet zone (hence it works fine in Office 2003 on Vista).

Even more worrying than the simple inconvenience of the prompt is that fact that WebDAV caches the users' credentials. Imagine the scenario that you go to a public access machine and log onto SharePoint using ISA FBA. You then open a document and enter your credentials. You then finish working and log off Sharepoint and close the browser. You would think you were now logged off, but you are not as WebDAV is still caching your credentials. Whoops!

04/01/2008

Following my call being escalated by the good guys at ESK UK to Microsoft, it has now been escalated within Microsoft. I've just been on a call with a very helpful escalation engineer at Microsoft who has confirmed that this issue is related to Office 2007 on Vista trying to use WebDAV and WebDAV trying to authenticate using Windows Auth, rather than using the persistent cookies. As our server is connected via ISA using FBA, Windows auth falls back to basic auth and then WebDAV caches the credentials (until the webclient service is restarted or the user logs off).

The engineer has provided a useful workaround: install the Web Client update for Vista (http://support.microsoft.com/default.aspx?scid=kb;EN-US;907306) and then set all Office Apps to run in compatibility mode. This has a couple of drawbacks other than the work involved. Firstly it loses the enhanced ability that WebDav has to be able to browse up and down SharePoint web applications and secondly it does not resolve the password prompt you get when when you try to use Explorer view (I don't know of a way of telling Explorer to run in compatibility mode). Nevertheless we will use this workaround on the few Vista machines we have, but will certainly have to think twice before rolling Outlook Vista and Office 2007 to our 12,000 desktops.

The following registry keys can be set to tell Office Apps to run in XP SP2 compatibility mode. Remember you can really mess up your machine by changing the wrong registry settings so back it up and go careful:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"winword.exe"="WINXPSP2"