Thursday, 26 July 2007

Customisations to the Content Query Web Part do not appear for 'normal' users

I customised the Content Query Web Part to show additional columns from Announcements lists, but these columns could only be viewed in the Web Part by Site Collection Administrators - 'conventional' users (even administrators of the root site) could only see the default title column of each announcement.

To resolve this, the ItemStyle.xsl and ContentQueryMain.xsl files that I customised needed to be checked in as major versions. I had initially tried to do this with SharePoint Designer, which appeared to show them as checked in, but it was only when I looked at the Style Library using a browser that I could see what the problem was - a mandatory column called "Title" needed to be completed before they could be checked in.

I edited the properties of each file, gave them a title, and then checked them in as major versions.

Wednesday, 25 July 2007

6482, 7076, 6398, and HRESULT 0x80005006 errors on second front-end server

Intermittently getting the above errors on my second MOSS front-end server after running an MS hotfix. This server is also hosting a second instance of the Central Administration Web application for resilience purposes.

A lot of advice recommends running a .NET 2.0 hotfix to resolve, but as this was only happening on my second front-end server I wasn't convinced that this would solve the issue (also, others on the Web also found that it went away for a few days but came back again).

Followed some advice after extensive searching on the Web to remove the Central Administration Web application using the SharePoint Configuration Wizard and reinstall it back again afterwards. I have done this and so far everything works fine, although the error still may appear again in the future.

Profile import works but get Error 7888 in the event log

Everytime a profile import is run (full or incremental), everything seems to go through successfully, but there is the following error in the event logs:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 24/07/2007
Time: 22:00:34
User: N/A
Computer: EP-SP-INDEX01
Description:
A runtime exception was detected. Details follow. Message: Access Denied! Only site admin can access Data Source object from user profile DB.

Techinal Details: System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB. at Microsoft.Office.Server.UserProfiles.SRPSite.AdminCheck(String message) at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(IDataRecord rec) at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(String strDSName) at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead) at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site) at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.GetDataSource() at Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)

I resolved this by doing the following:
- Go into the Shared Services administration page.
- Click 'Personalization Services Permissions'.
- Add the search service account (in my case this was DOMAIN\sp_search_svc) and give the account 'Manage User Profiles' permissions.

Errors 5555 and 7888 in the event log

We wanted to change the content database location from the SQL netbios name to the SQL FQDN instead (apparently this improves performance of db access) - so we removed reference to the content databases in Central Administration and re-attached them. What we should have done first is used the stsadm preparetomove command before doing so, creating the following messages in the event viewer:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: User Profiles
Event ID: 5555
Date: 24/07/2007
Time: 16:00:01
User: N/A Computer: EP-SP-FE01
Description:
Failure trying to synch web application 43caed9b-30c4-4b56-a5dd-3973ef92e354, ContentDB a5c17eb0-94bf-4362-87b1-be274bb5cc03 Exception message was A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 24/07/2007
Time: 16:00:01
User: N/A
Computer: EP-SP-FE01
Description:
A runtime exception was detected. Details follow. Message: A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

Techinal Details: Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy) at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds() at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

To resolve the situation we ran the following command on one of the front-end servers:
stsadm -o sync -deleteolddatabases 0

This sorted the problem, but it would have probably been better to use the preparetomove command in the first place. As to whether using the SQL FQDN improved performance or not - it didn't seem to make any difference whatsoever!

Tuesday, 24 July 2007

"Failed to configure propagation share" error when configuring search server

I have two front-end servers and a dedicated index server - FE01, FE02 and INDEX01. I configured the index server as an indexer and FE01 as a search/query server with no problems. However, when I tried to configure FE02 as a second search/query server, I got the error message "Failed to configure propagation share".

I couldn't find any resolution on the Web, so this is how I sorted it:

1. Manually configured the Office SharePoint Server Search service as Manual startup and the Search service account credentials (domain\sp_search_svc) on the Log On tab. I did NOT start the service.

2. Navigated to the SharePoint data folder 'E:\Program Files\Microsoft Office Servers\12.0\Data\Office Server' and created a new folder called 'Applications'.

3. Shared the folder with the share name 'searchindexpropagation' and description 'Microsoft Office SharePoint Server Search propagates index files through this share'.

4. Configured Full Control share permissions for the 'sp_search_svc' domain account & 'wss_admin_wpg' local group.

5. Configured folder security by adding Modify permissions to the 'sp_search_svc' domain account.

6. Configured the search/query server as normal through Central Administration, but instead of selecting to auto-create the propagation share, I selected to use STSADM instead.

Tuesday, 10 July 2007

Persistent cookies and Office applications

By default in Vista IE7, persistent cookies are not shared with Office applications due to the “Protected Mode” setting in IE. For a work around, please refer to 932118 Persistent cookies are not shared between Internet Explorer 7 and Office applications in Windows Vista http://support.microsoft.com/default.aspx?scid=kb;EN-US;932118