Nick Grattan’s SharePoint Blog

Or am I more likely to be abducted by aliens? Well, if you installed MOSS Service Pack 2 from a download before the 29th July 2009 your production MOSS Farm could stop working in the future. This is explained in Microsoft KB 971620 and in this Microsoft blog post.

In summary, initial releases of SP2 was configured as a trial version, and unless re-installed, MOSS features will stop working 180 days after you installed SP2. The value “180″ is reported in the KB, but this value seems to be different in practice.

To determine if your MOSS Farm is at risk you can:

• Run Central Administration.
• Select Operations.
• Select Convert license type in the “Upgrade and Migration” section.

The description of “Current License” will show if you installed SP2 with the trial version problem:

You can also determine when the trial version will expire:

• Run Central Administration
• Select Application Management.
• Select Check services enabled in this farm in the “Office SharePoint Server Shared Services” section.

A warning will be displayed if you’re running the trial version:

KB 971620 contains a link to a hotfix to correct this issue. This hotfix may require you to reboot the server. Before testing if the fix was applied correctly, issue an IISRESET before running Central Administration.

Thanks to Tim at Cork County Council for pointing out this issue.

In this post I explained how to determine if your SharePoint installation is service packed, and to what level. However, the situation is a little more complex since your MOSS 2007 farm will be running Microsoft SharePoint Services 3.0 and MOSS on top.

When using Central Administration / Operations / Servers In Farm to report the version number you’re seeing the Windows SharePoint Services 3.0 version number. This will be updated when you run the Windows SharePoint Services (WSS) service pack update.

So how do you find which service pack for MOSS you’re running with? One way is to find the version number of the Microsoft.Office.Server assembly from the Windows GAC (Global Assembly Cache). To do this:

• Run the Windows Explorer.
• Navigate to \Windows\Assembly.
• Right-click the file Microsoft.Office.Server and select Properties.
• Click the Version tab.
• Take a note of the “File Version”:

Here are the version numbers for the main MOSS services packs using this technique:

Version numbers from the Microsoft.Office.Server assembly do not follow exactly those for the WSS reported version number, but there is a close correlation.

You can find the current version number for MOSS 2007 through Central Administration:

• Run Central Administration.
• Click the Operations tab.
• Click Servers in farm under the “Topology and Services” section.

This shows the version number for the farm and each individual server in the farm:

Here are the version numbers for various MOSS 2007 service packs:

For a full list of version numbers, including interim builds see here.

Update: 5 Nov 2009: See here for how to find MOSS 2007 and Windows SharePoint Services version numbers.

When new databases are created, SharePoint uses the default SQL Server location. This is typically the “C:\Program Files\MS SQL\Data” folder. Many organisations use RAID or SAN storage which may have different locations, e.g. “D:\Database”.

Within SharePoint you don’t have the option of specifying where the data and log files for the databases are created.

Using the instructions in this blog you can change this default location for new databases. For existing database you need to “DETACH” and “ATTACH” the data and log files.

Documents in SharePoint Document Libraries are stored in the SQL Server database. In most situations this works well – backing up the SQL Server content database backs up all the documents in a consistent way.

However, for storing Binary Large Objects (BLOBs) may be inefficient and costly. It may be more efficient to store such BLOBs in the file system and then link these files to SharePoint Document Libraries.

This can now be done through the ISPExternalBinaryProvider interface. Prior to SharePoint 2007 SP1 this component was available as a hot fix, but is now included mainstream.

The interface is documented here: http://msdn2.microsoft.com/en-us/library/bb802976.aspx.

Question: Can you audit permission changes in a site collection?

Answer: This is possible, but by default security changes are not audited. To enable auditing:

1. Select Site Actions + Site Settings + Modify All Site Settings at the site collection root site.
2. Click the Site collection audit settings link.
3. Select the Editing users and permissions option:

Once turned on, changes to permissions on sites, lists and items will be audited. To view the audit log:

1. Click the Audit log reports link on the “Site Settings” page for the site collection.
2. Click the Security Settings link:

This will open the audit log in an Excel spreadsheet. The following example shows a summary showing a single security change resulting from a breaking of permission inheritance:

More detailed information is available in the “Report Data” sheet in the Excel workbook.

A single server install of MOSS 2007 will install SQL Server 2005 Express Edition and therefore each content database will be limited to 4GB. Therefore, a site collection (if given its own content database) will be limited to 4GB of content.

A SPS 3.0 single server install does not install SQL Server 2005 Express Edition – instead it installs the Windows Integrated Database (WID), which is also known as SQL Server 2005 Embedded Edition. The instance name is “MICROSOFT##SSEE”, and there are several limitations such as external connections are not permitted.

However, most importantly, WID databases do not have the 4GB limitation, and so practically speaking, the content size for a site collection is unlimited.

The database files are installed into “\WINDOWS\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data” which is typically located on drive C. This can cause problems as many servers use another drive for storing data.

The easiest way of moving a content database from the default location to another location is to perform a backup of the web application using Central Administration and then restore to the new location.

SharePoint maintains a list of blocked file types based on the filename extension. The default list is documented here.

You can change this list using Central Administration. Each web application has its own list which will apply to all site collections in the web application.

To maintain the list run Central Administartion and navigate to Operations + Blocked File Types.

SharePoint 2007 does not provide an IFilter for indexing PST files. These files contain email messages and PST files can be generated from Microsoft Exchange using EXMerge.exe or by exporting from Microsoft Outlook.

Here is one technique for indexing the contents of a PST. First, you need to extract messages from the PST into separate MSG files. A tool like Aid4Mail (www.fookes.com) will do this for you. You can then create a content type for indexing the folder in which the MSG files are located.

Looking for an IFilter for a particular file type? Take a look at www.ifilter.org as a starting point. This site has links to IFilters for ZIP, RAR, CHM, RTF, StarOffice, OpenOffice and other files types.

* Thanks to Jackie at Kainos for pointing this out to me.