Microknowledge

Sharepoint 64 bit support for Adobe PDF Indexing

For several years, Sharepoint 64 bit installations have faced a challenge in dealing with Adobe Acrobat PDF files.  [Apart from having to manually tweak the XML files to add the icon...]  Microsoft's search technologies, out of the box, understand the structure of their own Office documents.  This means they can index the contents of these documents to provide full text searching.  However, for third party products, especially Adobe Acrobat, they rely on third party providers to provide "iFilters".

 

What are iFilters?  They are simple extensions that allow a search indexer to crawl the contents of a file.  Although Adobe has always bundled the 32 bit version of its PDF iFilter with Acrobat and Acrobat Reader, they didn't provide a 64 bit version.  Without this, indexing had to be relegated to 32 bit platforms.

 

Enter FoxIT Software. Fox (along with other companies) sells a 64 bit iFilter for Acrobat PDF files.  As a result, FoxIT became a dominant iFilter for companies needing 64 bit Sharepoint indexing.

 

After several years in development, Adobe has finally released the 64 bit version of their iFilter for Acrobat PDF files:

 

http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025

 

iFilters provide support for full text indexing based on the contents of the file.  At this time, the iFilter is not bundled with Reader (as it is for the 32 bit platforms), nor is it available for Itanium 64 bit (IA64) systems.

 

So why pay for what Adobe gives away?  In short, performance.  Adobe's 32 bit filters ran more slowly than FoxIT, and that performance gap has extended to the 64 bit architecture.  It's also telling that Microsoft uses the Fox tools to index PDFs for its hosted Exchange solutions. 

 

My sense is that for users with small volumes (<500) of PDF files, the difference in index speed will be immaterial.  However, for other users -- especially medium to large Sharepoint farms with dedicated indexing servers -- the performance gains from the third party tools will be significant.

 

Microsoft SharePoint 2007 Service Pack 2 Bugs and Release Recommendations

In late April 2009, Microsoft released Service Pack 2 for Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007. 

What’s included

Service Pack 2 integrates a number of hot fixes released since Service Pack 1.  In addition, it includes stability and performance enhancements to the following SharePoint related systems:

· Enterprise Content Management (MOSS Publishing)

· Forms Server

· Groove Server

· Excel Server

· Project Server

· Search Server

Service Pack 2 also adds supports for Internet Explorer 8, Firefox 2/3, and Windows Server 2008.

In addition, Service Pack 2 provides some forward-looking functions that allow you to scan your installation for compatibility with upgrades to the next version of the SharePoint platform.  Specifically, the stsadm command line administrative utility adds a “-preupgradecheck” switch that reports on what needs to be done to prepare your server farm for the 2010 upgrade.

Since Service Pack 2 rolls up a number of interim releases since Service Pack 1, it includes the Infrastructure Update from July 2008.  This update added Federated Search (a feature introduced with Search Server 2008).   Federated search allows you to expand your search scope to cover external sources (such as Google) not directly covered by your own server’s crawling activities, and gives you more control in how you present those results.

What’s also included, unfortunately

However, Service Pack 2 also includes a bug that makes SharePoint servers revert to 180-day trial mode.  Microsoft has documented a workaround for this issue  -- specifically, reentering the product license key in SharePoint Central Administration (http://support.microsoft.com/kb/971620).  They also have a hotfix that will automatically undo the trialware bug (http://support.microsoft.com/kb/971620).  Microsoft has committed to releasing a "clean" SP2 by August 2009.

Microsoft will also shortly release an automatic, permanent fix for this bug.

We recognize that this is a relatively low impact workaround.  Many organizations may be comfortable accepting this as a necessary step in the process.   Although Microsoft performs extensive regression testing on its major service packs, these kinds of issues are rare.  Nonetheless, at this point, we recommend deferring any further general deployments of this Service Pack until at least several weeks after the Microsoft releases a permanent solution to the bugs identified, unless you have a specific need addressed by the Service Pack.  If you don’t need the updates, give Microsoft a few more weeks to stabilize them.

But wait, there’s more…

Two days after Microsoft issued Service Pack 2, they released the April 2009 Cumulative Update (“CU”) for the Office 2007 platform.  The Cumulative Update isn’t just one file – it’s actually a large group of patches for both the Office 2007 clients and the servers.   For example, there are separate patches for MOSS, WSS, Search Server, Excel Server, Forms Server, Info Path, Project Server, etc.  Not every patch is necessary for every system.  However, in many cases, the CU updates will fix a much larger set of issues than the service pack.  And the CU requires SP2 as a prerequisite for installation.  Selecting the right mix of updates to solve a specific problem requires some planning and research.

Service Packs and Hot Fixes

In general, Service Packs go through a much higher level of regression testing and development at Microsoft.  As a result, it’s usually appropriate to test and deploy Service Packs upon release.  On the other hand, single hot fixes are not extensively cross checked, and are usually developed only to address a specific issue.  Unless you have been advised to use a hot fix to address a discrete problem, users should not plan on general deployment of hot fixes.  

Cumulative Updates and Infrastructure Updates are handled somewhat differently from Service Packs and Hot Fixes.  In our experience, Microsoft Support is recommending wide deployment of these as an initial step in resolving most system issues.

Finally, Microsoft’s anticipated revised Service Pack 2 (with the fix for the trialware bug) can be expected to undergo significant testing before its release.  As a result, users can place even higher confidence in the stability of the future SP2 than in the current SP2 plus the workaround.

Figure 1 - Deployment Decisions

For users with specific issues addressed by fixes contained in this release:

Since SP2 integrates many post-SP1 hot fixes, we recommend the cautious deployment of Service Pack 2 (and the CU as warranted) for these specific situations.  However, users should be fully aware that they will need to perform the manual workarounds noted in Microsoft KB article 971620. In addition, these updates should first be installed and tested in non-production environments, and only deployed in conjunction with full system backups.

General usage

We recommend standard deployment of Service Packs when issued by Microsoft.  However, as noted above, we recommend that clients defer Service Pack 2 installations until Microsoft deploys its official automated fix for the trialware bug in the original release.   Unlike hot fixes for specific problems, Microsoft performs extensive regression testing for Service Packs.  However, even Microsoft’s testing can only approximate the wide range of field conditions.  As always, service packs should first be applied in a non-production environment, and full backups should be maintained prior to deployment.

In general, once Microsoft issues their update to the Service Pack, SP2 contains a wide range of enhancements that hold benefit for almost all environments. 

Please contact your lead consultant or partner to discuss how we can help you plan for and execute this SP application.  Also, KMA would be pleased to offer additional advice for your specific configuration if you have more detailed questions.

For additional information on Microsoft SharePoint Service Pack 2: http://blogs.msdn.com/sharepoint/archive/2009/04/28/announcing-service-pack-2-for-office-sharepoint-server-2007-and-windows-sharepoint-services-3-0.aspx

For additional information on the SP2 bug: http://blogs.msdn.com/sharepoint/archive/2009/05/21/attention-important-information-on-service-pack-2.aspx

For additional information on the April 2009 Cumulative Updates:
http://support.microsoft.com/default.aspx/kb/968765

Sharepoint 2010 IT Implications

At last week's TechEd conference, Microsoft announced system requirements for the Office 2010 servers, which will include Sharepoint 2010 (and Project Server 2010.)  [often called Sharepoint 14 or SharePoint vNext]

 

Highlights include:

• SharePoint 2010 will be 64-bit only
• SharePoint 2010 will require 64-bit Windows Server 2008 or
  64-bit Windows Server 2008 R2
• SharePoint 2010 will require 64-bit SQL 2005 or 2008
• SharePoint 2010 will only support Internet Explorer 7 or 8 (IE 6 will not be supported nor other browsers)

This holds two key implications for IT teams currently supporting the 2007 platforms:

 

Server/Databases

All server builds need to be 64 bit, which will eliminate in place upgrades for 32 bit servers.  In addition, SQL 2000 is no longer supported.  Although most server hardware platrorms will support 64 bit servers, they can not be upgraded "in place" from Windows 32 bit architectures (http://technet.microsoft.com/en-us/library/cc733167.aspx).  Nor can SQL be upgraded directly to a true 64 bit installation.  (http://msdn.microsoft.com/en-us/library/ms143393.aspx) 

 

The good news is that the recently released Sharepoint Service Pack 2 includes a new command line option that will check your Sharepoint installation for upgrade readiness: stsadm –o preupgradecheck.  This option generates XML and test logs that detail necessary prerequisites for a future upgrade.

 

Desktop

Many IT organizations are continuing to hang on to IE6 becuase of application compatibility issues with internal applications.  Although "publishing" sites will continue to support multiple browsers to view content, internal collaboration sites will not support IE6.  IT teams should identify any web applications that will require upgrades or mitigiation in advance of future Sharepoint upgrades. 

 

For more details, see the URL below.

http://blogs.msdn.com/sharepoint/archive/2009/05/07/announcing-sharepoint-server-2010-preliminary-system-requirements.aspx