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.