When configuring the windows services search or the office search service from the Operations page in Central Admin make sure you use full account names eg DOMAIN\Username not just Username otherwise it will return an error message like ‘Error Osearch’ in the browser. In the ULS log, you will see:-

The call to SearchServiceInstance.Provision (server ‘Server’) failed. Setting back to previous status ‘Disabled’. System.ComponentModel.Win32Exception: OSearch (username)     at Microsoft.SharePoint.Win32.SPAdvApi32.ChangeServiceConfiguration(String strServiceName, String strAccountName, SecureString sstrPassword, IdentityType identityType, Boolean bDontRestartService)     at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionProcessIdentity(String strUserName, SecureString secStrPassword, IdentityType identityType, Boolean isAdminProcess, Boolean isWindowsService, String strServiceName, Boolean dontRestartService)     at Microsoft.SharePoint.Administration.SPProcessIdentity.ProvisionInternal(SecureString sstrPassword, Boolean isRunningInTimer)     at Microsoft.SharePoin…     …t.Administration.SPProcessIdentity.Provision()     at Microsoft.SharePoint.Administration.SPWindowsServiceInstance.ProvisionCredentials()     at Microsoft.SharePoint.Administration.SPWindowsServiceInstance.Provision(Boolean start)     at Microsoft.SharePoint.Administration.SPWindowsServiceInstance.Provision()     at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Provision()     at Microsoft.Office.Server.Search.Administration.SearchAdminUtils.DeployCredentials(SearchServiceInstance localSearchServiceInstance, Boolean deployOnlyLocalInstance)   

Hopefully since I’ve done this wrong once I won’t do it again!

Here is my recent post on what is in the recent SharePoint infrastructure update.

http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=9

Please take time to read it.

Thanks,
Gavin

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.

The Sharepoint 2007 permissions matrix is a great reference of the out of box permissions and how they map to the default groups.

I’ve printed this one in colour and “it’s going straight to the pool room!”

The other great reference is on the sharepoint solutions page. This is a collection of visio diagrams on all sorts of sharepoint topics. Search for the diagram on application security.

The first is the “SharePoint Templates: Preformatted document libraries for Windows SharePoint Services 3.0 and SharePoint Server 2007“

This download includes stp files for document libraries with sample docx templates. There are 5 examples:-

• Invoices
• Specifications
• Press releases
• Customer site visit reports
• Meeting notes

The second download is for the “Office SharePoint Server 2007 DoD 5015.2 Resource Kit“.  From what I’ve read about this one it looks quite complex and has caveats that you should engage a partner for an actual records management implementation.

Adobe Labs have a pre-release of how to support Adobe Reader v8.1 ifilter on 64bit sharepoint.

I’ll admit that I haven’t tested this yet and it involves a 64bit ‘thunking’ layer. In the past I have seen some instructions on to use this technique to ‘hack’ together a custom 32bit ifilter handler onto a 64bit system.

The main significance of this is that currently the only cleanest way of supporting pdf indexing on sharepoint 64bit platforms is to use foxit pdf ifilter. However this is commercial software that is priced based on the number of CPU cores. (As at 25JAN2008 this was “License cost for each server with up to two CPU cores is $329.99. Each additional CPU core costs $129.99.”) Now with most production servers these days being dual quad core processors (ie 8 processing cores) This would be US$1109.93 for each production server. Congrats does go to foxit for seeing a large hole left in the market by Adobe being so slow to support the 64bit platform and providing a solution.

The other comment worth making is that the foxit 64bit ifilter may be coded natively in 64bit but I’m not sure of this. Whereas the Adobe solution is taking the existing 32bit ifilter in wrapping it into 64bit which does involve a processing cost overhead. If you had a large index with lots pdf documents then going for a native pdf ifilter could bring a significant performance difference.

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)

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

I spotted another bizarre default behaviour in sharepoint yesterday.

If you have a publishing site and you apply individual permissions to pages (also known as fine grained permissions), which is not beyond the realm of possibility on an intranet or similar website by default these pages will not be included in the search results.

Go to the site settings for the site and from the ‘Site Administration’ column select ‘Search Visibility’. You will notice that aspx pages by default are not indexed if they have fine grained permissions.

This just seems to be a bizarre default setting. Given that search results are security trimmed why is the default behaviour not to index all aspx pages?

Anyhow change the setting to ‘Always index all aspx pages on this site’ and they will be indexed.

The nice thing on the screen above is that the sentence above the radio buttons will indicate if your site has fine grained permissions.