MOSS February 2009 Cumulative Updates Break 64bit Adobe iFilter v9

After updating a customers MOSS farm with the February 2009 Cumulative Updates and performing a full crawl of my default content source I found that PDF files were no longer being indexed. I discovered that the updates had overwritten a registry key that the Adobe iFilter 64bit deployment guide asks you to change and therefore had changed it back to the default key.

To fix this issue perform the following on your Index Server:

Run Regedit by browsing to c:\Windows\system32\regedt32.exe and double-clicking it.

• While still in RegEdit, within the left-side tree, browse to: \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
  


• Ensure that the values match the following as shown.
  Default = {E8978DA6-047F-4E3D-9C78-CDBE46041603}

Backup Exec Remote Agent stops when restoring a site

Had an issue when using the Symantec Backup Exec Agent 12.5 for SharePoint 2007. The remote agent was installed on the SQL Server and the SharePoint server. When we backed up the farm using the agent everything was fine. When we tried to restore a single item everything was fine. When we tried to restore a site the Backup Exec Remote Agent would stop on the SQL Server and the following errors would appear in the event log:



Event Type: ErrorEvent Source: Application ErrorEvent Category: (100)Event ID: 1000 Date: 11/03/2009Time: 13:59:47User: N/AComputer: UKOSPSQLTEST01Description:Faulting application beremote.exe, version 12.5.2213.0, faulting module bedssps3.dll, version 12.5.2213.0, fault address 0x00000000000483df.

This issue was finally resolved by going into Central Administration > Application Management > Policy for Web Application and then adding the Backup Exec Service account with Full control permissions to the Web Application containing the site you are trying to restore.

Going into Search Settings in SSP is very slow

When accessing Search Settings in the SSP Admin it was taking around 40 seconds to a minute to access the settings page. The same was true when accesssing things like Content Sources, in other words search related stuff. Now i'm not sure whether this is related to the .Net Framework 3.5 SP1 issue I blogged about previously here:
http://mrvsharepoint.blogspot.com/2009/02/when-you-to-search-settings-you-get.html

I eventually found an article on the web that alluded to a similar problem in a .Net application where in there case the application was trying to download a certificate revocation list from Microsoft. You can read about it here http://www.dotnetscraps.com/dotnetscraps/post/ASPNET-Response-time-is-very-slow-for-the-first-request-to-application-(452b-seconds).aspx

I then realised that the account I was using to log in to my servers was not permitted access to download files from Microsoft as I was on a customer site and this was part of their security policy. Once access to the internet was negotiated for the account the Search Settings issue resolved itself. As to what exactly it was trying to download is still a mystery.

When you to Search settings you get "Authentication failed because the remote party has closed the transport stream." and you get Event 6482 errors

Came across an interesting problem that I had not seen before. After implementing a MOSS farm (2 x WFE/Search, 1 Index) and trying to get to Search settings in the SSP I was presented with the error

"Authentication failed because the remote party has closed the transport stream."

Looking in Event Viewer I was getting an Event 6482 error every minute as follows:


Event Type: ErrorEvent Source: Office SharePoint ServerEvent Category: Office Server Shared Services Event ID: 6482Date: 19/02/2009Time: 09:39:43User: N/AComputer: UKOSPWFE01Description:Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (7eb931e4-0269-447d-acec-dabe2f151f33).
Reason: The underlying connection was closed: An unexpected error occurred on a send.
Techinal Support Details:System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream. at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- 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.SearchServiceInstance.Synchronize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)


I had never seen this before so at first I thought it was something to do with the December cumulative updates but googling it I found this http://support.microsoft.com/kb/962928 which goes on to explain that you get this problem when the following conditions are true:

• The server that is running Office SharePoint Server 2007 has the query role in a server farm. (yep, two of them do)
  
• The roles of the query server and the index server are not on the same server in the server farm. (yep, 1 index server and the query roles are on the two front ends)


• The server farm was updated with Microsoft .NET Framework 3.5 Service Pack 1 (SP1). (yep, did this and this was the likely cause of the problem according to the MS article)

According to the article this causes the self-issued certificate that is used by the Office Server Web Services to become corrupted.

The solution involved downloading the IIS 6 Resource Kit and also applying an update for the .NT Framework 3.5 SP1. Full details taken from the article are as follows:

• Stop the Windows SharePoint Services Search service. To do this, follow these steps:
  Click Start, click Run, type cmd , and then click OK.
  
• At the command prompt, type net stop osearch, and then press ENTER.
  Type exit to exit the command prompt.
  
• Download and install the IIS 6.0 Resource Kit Tools. To obtain the IIS 6.0 Resource Kit Tools, visit the following Microsoft Web site:
  http://www.microsoft.com/downloads/details.aspx?familyid=56FC92EE-A71A-4C73-B628-ADE629C89499 (http://www.microsoft.com/downloads/details.aspx?familyid=56FC92EE-A71A-4C73-B628-ADE629C89499)
  

On each server in the farm that has Office SharePoint 2007 installed, follow these steps:

• Click Start, click Run, type cmd , and then click OK.
  At the command prompt, type selfssl /s:951338967 /v:1000, and then press ENTER. Where 951338967 is the default ID of the Office Server Web Services certificate and
  1000 is the number of days that the certification will be valid.
  
• Start the Windows SharePoint Services Search service. To do this, follow these steps:
  At the command prompt, type net start osearch, and then press ENTER.
  Type exit to exit the command prompt.
  
• Download and install the following update to the .NET Framework 3.5 SP1. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
  959209 (http://support.microsoft.com/kb/959209/ ) An update for the .NET Framework 3.5 Service Pack 1 is available

Now I did all of this but still had the same problem so stopped and started the Search Service from within Central Administration, Services on Server and this eventually fixed it.

SharePoint 2007 Disaster Recovery Resources

I'm currently prepping for a MOSS Disaster Recovery session with a customer and came across the following material on Technet: http://technet.microsoft.com/en-gb/events/bb530366.aspx



Whilst the training material goes through the basics of the Recycle Bin etc what I found particlularly useful was the PowerPoint slide deck as it lists Pro's and Con's of the different approaches - SharePoint Native backup vs SQL Backup.



The PowerPoint also depicts failover methods like SQL Clustering and Log shipping also listing Pro's and Con's of each one. The only downside is that it does not mention SQL mirroring.

Get the PowerPoint from here http://download.microsoft.com/download/a/b/1/ab13fe7e-2b58-4173-9a7e-f3140e215181/DSK-106_PPT_and_Transcript.exe

Error changing SMTP settings in IIS Manager after configuring incoming email in the farm

Came across one of those bizarre scenarios where you apply a hotfix to resolve an issue and it causes a separate issue.



After configuring incoming mail settings on a MOSS farm I started to get an unspecified SMTP error when I tried changing SMTP settings from within IIS Manager. Further investigation revealed that the issue was caused by my applying the hotfix (KB946517) to resolve Event ID 6398, 7076 and 6432 errors.

The problem is described in detail here on the MSDN blog http://blogs.msdn.com/vijaysk/archive/2008/04/14/issue-smtp-configuration-unspecified-error.aspx



and the subsequent Microsoft Knowledgebase article is here http://support.microsoft.com/default.aspx/KB/950426



A hotfix is now available from Microsoft which resolves this issue.

Clicking on a user clickable link does not redirect to the Person.aspx page but stays on the Userdisp.aspx page instead

I came across this problem recently where clicking on a user's clickable link, for example in the column "Modified By" took you to the userdisp.aspx page but instead of redirecting you to your MOSS profile page (person.aspx) which should happen if you are using MOSS as opposed to WSS 3.0 you are left at the userdisp.aspx page.

There are a number of thoughts on why this happens and each of these are published around the web ranging from the redirect getting confused by AAM settings to a bug where your portal FQDN and your MySites FQDN do not share the same root URL (e.g http://intranet/ and http://mysite/). I have tested this and found this problem does not occur if for example you have the following URL's http://intranet/ and http://intranet:8088/ being the MySite URL. This would seem to support the "Same Root URL" theory.



They way this was resolved by myself and my colleague Ajay Chauhan (http://sharepointetcetera.blogspot.com/) who was working on this particular project with me was to set up a Portal Site Connection on the Site Collection(s) that have this problem and the MySite host. Now this isn't ideal but we specified the name of the connection as a full stop to make it as inconspicuous as possible to users (as shown below). This full stop does appear in the breadcrumb trail on the top left hand of pages though.













Update:

Looking around I believe this may be resolved in SP2.

More details can be found in this blog by Larry Kuhn http://sharepoint.microsoft.com/blogs/LKuhn/Lists/Posts/Post.aspx?ID=47