Microsoft have just released a hotfix to search DCOM permission post SP1 problem which I wrote about previously.

The hotfix can be found here. http://support.microsoft.com/kb/953137

I’ve just stumbled across a problem post MOSS 2007 SP1.

After applying SP1 to an existing installation and running a full catastrophic backup it fails on the shared search index item with an error regarding UnauthorizedAccessException.  The environment I am experiencing this in is a single virtual machine that is a domain controller, SQL2005 SP2, and multiple domain service accounts for the farm service account, search service, etc.

The error can be seen in the spbackup.log as:-

[5/8/2008 2:59:48 AM]: Error: Object Shared Search Index failed in event OnPrepareBackup. For more information, see the error log located in the backup directory.
    UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.
[5/8/2008 2:59:48 AM]: Debug:    at Microsoft.Office.Server.Search.Administration.SearchApi.RunOnServer[T](CodeToRun`1 remoteCode, CodeToRun`1 localCode, Boolean useCurrentSecurityContext, Int32 versionIn)
   at Microsoft.Office.Server.Search.Administration.SearchApi..ctor(WellKnownSearchCatalogs catalog, SearchSharedApplication application)
   at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.get_SearchApi()
   at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.Microsoft.SharePoint.Administration.Backup.IBackupRestore.OnPrepareBackup(Object sender, SPBackupInformation args)
   at Microsoft.SharePoint.Administration.Backup.SPBackup.RunPrepareBackup(SPBackupRestoreObject node)

It looks like SP1 is blasting away the permissions on the OSearch DCOM application.

I’d like to thank Jason Medero with his post and /dev/arthur for his post on this issue which lead me to confirm what they had found.

While their posts talk about manually editing the DCOM launch permissions for the OSearch application, Ali Mazaheri on his article has a far simpler solution.

Just run the following command:

stsadm -o osearch -action start

After you run this command you can browse to the permissions of the the OSearch DCOM application and confirm that the sharepoint service accounts and the WSS_ADMIN_WPG and WSS_WPG groups have been granted local launch and local activation permissions.

Note that while I found this error while trying to run a backup, my application event log was full of errors similar to what Ali describes in his article. This just demonstrates that if you have errors in your event log after applying a patch or service pack, something has gone wrong and you need to investigate it.

The bug is that when you edit the model, modify the latency of the site to site connections and then save the model, after you re-open the model the latencies are reset to 10ms.

I posted the bug to the SCCP managed forum and I would like to compliment Jonathan Hardwick from Microsoft on his prompt response. He has confirmed the problem as a bug. So hopefully a patch or release will be available soon to fix the problem.

In the application event log you will see events for 7076, 6398, 6432 and for me I also saw 6482.

I’ll copy and paste the full events from my test server below.

The KB article is here. The anonying thing about this KB article is that it is categorised as only applying to IIS and not sharepoint even though the big driver to fix this seem to have been MOSS related. That means that it would be difficult to find this KB article if you are restricting your KB searches by product.

——————————————–

Event Type:    Error
Event Source:    Windows SharePoint Services 3
Event Category:    Timer
Event ID:    6398
Date:        11/01/2008
Time:        12:10:08 PM
User:        N/A
Computer:    MOSSTEST
Description:
The Execute method of job definition Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (ID 9668b02b-5f13-4963-bf0b-181c81272dea) threw an exception. More information is included below.

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

——————————————–

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category:    Office Server Shared Services
Event ID:    6482
Date:        11/01/2008
Time:        12:14:07 PM
User:        N/A
Computer:    MOSSTEST
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchAdminSharedWebServiceInstance (5e5393a6-039a-4896-a727-04818d85b326).

Reason: Exception from HRESULT: 0×80005006

Techinal Support Details:
System.Runtime.InteropServices.COMException (0×80005006): Exception from HRESULT: 0×80005006
   at System.DirectoryServices.Interop.UnsafeNativeMethods.IAds.PutEx(Int32 lnControlCode, String bstrName, Object vProp)
   at System.DirectoryServices.PropertyValueCollection.OnClearComplete()
   at System.DirectoryServices.PropertyValueCollection.set_Value(Object value)
   at Microsoft.SharePoint.Metabase.ApplicationPool.set_IdentityType(ApplicationPoolIdentityType value)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionIisApplicationPool(String name, ApplicationPoolIdentityType identityType, String userName, SecureString password, TimeSpan idleTimeout, TimeSpan periodicRestartTime)
   at Microsoft.SharePoint.Administration.SPMetabaseManager.ProvisionIisApplicationPool(String name, Int32 identityType, String userName, SecureString password, TimeSpan idleTimeout, TimeSpan periodicRestartTime)
   at Microsoft.Office.Server.Administration.SharedWebServiceInstance.Synchronize()
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

——————————————–

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category:    Office Server Shared Services
Event ID:    7076
Date:        11/01/2008
Time:        12:14:08 PM
User:        N/A
Computer:    MOSSTEST
Description:
An exception occurred while executing the Application Server Administration job.

Message: Exception from HRESULT: 0×80005006

Techinal Support Details:
System.Runtime.InteropServices.COMException (0×80005006): Exception from HRESULT: 0×80005006
   at System.DirectoryServices.Interop.UnsafeNativeMethods.IAds.PutEx(Int32 lnControlCode, String bstrName, Object vProp)
   at System.DirectoryServices.PropertyValueCollection.OnClearComplete()
   at System.DirectoryServices.PropertyValueCollection.set_Value(Object value)
   at Microsoft.SharePoint.Metabase.ApplicationPool.set_UserName(String value)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionIisApplicationPool(String name, ApplicationPoolIdentityType identityType, String userName, SecureString password, TimeSpan idleTimeout, TimeSpan periodicRestartTime)
   at Microsoft.SharePoint.Administration.SPMetabaseManager.ProvisionIisApplicationPool(String name, Int32 identityType, String userName, SecureString password, TimeSpan idleTimeout, TimeSpan periodicRestartTime)
   at Microsoft.Office.Server.Administration.SharedWebServiceInstance.CreateSharedWebServiceApplicationPool(SharedResourceProvider srp)
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

——————————————–

What I want to do is map the sharepoint user profile property ‘assistant’ to active directory (AD). I could map it to 1 of 2 attributes in AD, either ‘assistant’ or ‘msExchAssistantName’. The assistant attribute in AD stores the DN of that user. Much in the same way as the manager attribute in AD. The msExchAssistantName attribute stores the displayname of the user.

Initially I was mapping assistant to assistant however the problem was that the profile page for a user would display the DN of the assistant. Very ugly!

So I change the mapping to msExchAssistantName hoping that might work but no it now shows the assistant displayname on the profile page however it does not fix the click through problem.

In both of these cases the assistant field is a hyperlink to what you would expect to be the user profile page of the assistant but in both cases sharepoint does not translate it correctly and returns an error page with ‘user not found’.

Now I’m pretty sure that the assistant attribute in AD is widely used and I think that this is a bug or a case of a not quite completed component by the sharepoint dev team. And if they can get it to work for the manager attribute why not for the assistant attribute? During my research I found little info related to the issue except for one post from Joris Poelmans on YASQ – AD Assistant field not correctly imported into SharePoint User Profile database. I have to agree with Joris that this is yet another sharepoint quirk.

If any sharepoint microsoft’y is reading this could they pass it along to the product team and have it fixed please.