There is an official fix from Microsoft regarding the SharePoint 2007 Service Pack 2 expiration date issue. This fix can be applied either before or after the installation of Service Pack 2.

For all the details and the download the fix, visit http://support.microsoft.com/kb/971620

SharePoint Blog Posts and Searching

Yet again, this was something that I found out the hard way.  I created a simple, out of the box site based using the blog site template.  The site created successfully, and myself and my colleagues started posting.  After having generated several blog entries, I started a full crawl to get the blog posts included in the Search indexes. 

Once the crawl was completed, I performed a search against the contents of the blog posts.  Search was unable to index the contents of the blog posts.  It had crawled the titles of the posts, and linked to the page containing the list of posts.  Search would neither crawl posts nor display links to the actual blog post items themselves.  it always returned me to the entire list.

This just didn’t make any sense at all.  How could SharePoint offer Search, but not be able to crawl or index any of it’s own content? 

I thought that it might have something to do with the fact that blog post items are created as “enhanced rich text” instead of just “rich text” or “plain text”.

As a test, I went into the properties of the ‘body’ column of the post item and changed it from “enhanced rich text” to just “rich text”.  I initiated another full crawl (it’s a small MOSS site) and I got the same results (or rather, lack of results).  I also tried as plain text.  No luck.  So, there is something inherently different about blog posts in SharePoint that make it difficult for SharePoint Search to index.  I’m still investigating why this is.

As an alternative, I discovered the Community Kit for SharePoint (CKS) which has an Enhanced Blog Edition.  This SharePoint Solution Package is pretty straightforward to install.  The blog posts created when using it are searchable and the search results list directly to the post item itself, not back to the list of posts.  Beyond that, it has many themes to choose from and offers a few more features than the out of the box SharePoint Blog site.  You can find it on CodePlex.

App Offline File

A colleague pointed out this extremely useful tip for a quick and easy way to provide a friendly message to users when a SharePoint site is being upgraded or changes are  occurring behind the scenes.  This applies not just to SharePoint 2007 sites, but any .NET 2.0 application.

By simply placing an HTML file named app_offline.htm in the root of your web application (not necessarily the root of your web server), your users will get your custom HTML message instead of a nasty ASP.NET error message.   One caveat to this is to be sure that the file is at least 512 bytes in size.  If you don’t have enough text in your custom app_offline.htm page, just add a series of hidden comments. 

The beauty of this is that you can have this file ready and waiting, and it only takes a few seconds to copy it to the right folder before performing any maintenance. 

If you have a lot of SharePoint web applications and you were not consistent in your naming of their virtual directories (like I did), right click on your SharePoint web site in IIS 7, and select Explore.  This will open the root of your web application on the file system.  Drag and drop your app_offline.htm file to this folder.  When your maintenance is complete, drag this file out the folder.

A great resource and a simple example of this can be found at ScottGu's blog site.

SharePoint 2007 Service Pack 2 Expiration

Just saw on the Microsoft SharePoint Team blog that SharePoint 2007 Service Pack 2 contains a bug that activates a 'trial-mode' counter that will cause your SharePoint sites to expire after 180 days, just like an evaluation copy would.

There is no risk to data or system configuration or to any custom code, but your SharePoint servers will become inaccessible after the 180 day mark.

The products that this affects include Office SharePoint Server 2007, Form Server 2007, Search Server 2008 and Search Server 2008 Express. Windows SharePoint Services 3.0 in not affected.

Microsoft is working on a hotfix, which will be identified by KB article 971620. It is not currently available.

Create Your Own SharePoint SP2 SlipStream

1. Copy the original media to a folder on the local drive of the server. For example, c:\sharepoint_install.
2. Download WSS Service Pack 2 (wssv3sp2-kb953338-x86-fullfile-en-us.exe) KB Article 953338
3. Download Office SharePoint Server 2007 Service Pack 2 (officeserver2007sp2-kb953334-x86-fullfile-en-us.exe) KB Article 953334
4. Create the updates folder c:\sharepoint_install\updates
5. Extract both the WSS and the MOSS Service Pack files to the \updates folder of the original installation media. For example – c:\sharepoint_install\updates
   

For WSS 3.0 SP1

• Run the following command as an administrator:

c:\wssv3sp1-kb936988-x86-fullfile-en-us.exe /extract:c:\sharepoint_install\updates

• You will see a dialog box asking you to accept the license terms. Check the box and click continue. To suppress the dialog box add the /quiet switch when extracting the Service Pack files.
• The files will extract to the \updates folder.
  

For MOSS SP1

• Run the following command as an administrator

c:\officeserver2007sp1-kb936984-x86-fullfile-en-us.exe /extract:c:\sharepoint_install\updates

• You will see a dialog box asking you to accept the license terms. Check the box and click continue. To suppress the dialog box add the /quiet switch when extracting the Service Pack files.
• The files will extract to the \updates folder.

You now have an up-to-date installation package for installing SharePoint.

SharePoint 2007 and SQL Server 2005 - SharePoint SSP SQL Jobs not Deleted

The Windows Application Event Logs were filling up with login failures for the account that is used to access the SQL Server databases located on a separate server.

There were thousands of entries on the SQL server with:

Login failed for user 'DOMAIN\service.account'. [CLIENT:local machine]

I then looked at the SQL logs that were generated and stored at:

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG
Again, the error logs were filled with login failures such as:
Logon Error: 18456, Severity: 14, State: 16.
Logon Login failed for user DOMAIN\service.account'. [CLIENT:local machine]

The error messages did not reference a specific database, which made finding the cause of the problem difficult. The frustrating part was that SharePoint 2007 was working just fine. There were no errors and no failures from the SharePoint server itself. Users were creating lists, libraries and storing documents.

The SQL Server is using Windows Authentication. The account service.account had all the correct rights and permissions for accessing all of the SharePoint databases. It was set to use ‘master’ as the default database. To be certain, I added the account to the local administrator group, as well as the domain administrators group (overkill). I double-checked SharePoint and the configuration to be sure the correct account was being used.

Then I went back to the SQL server and started looking at the SQL Server Agent logs, and I found my first clue.

My SQL Agent logs were filled with the following error messages:

SQLServer Error: 18456, Login failed for user 'DOMAIN\service.account’ [SQLSTATE 28000]
SQLServer Error: 4060, Cannot open database "DBNAME_SSP_DB" requested by the login. The login failed. [SQLSTATE 42000]

It identified the DBNAME_SSP_DB as the database that was trying to be accessed. So now I had both the database name and I knew it was the SQL Server Agent service. Unfortunately – the DBNAME_SSP_DB database did not exist on my server.

The database DBNAME_SSP_DB was created during an initial installation of SharePoint, and later the SSP was deleted, along with the corresponding database.

I went back to SQL Server Management Studio to look for references to DBNAME_SSP_DB and found a SQL Server Agent Job named DBNAME_SSP_Job_DeleteExpiredSessions
This jobs task is to run every minute to clean up ‘expired sessions from the session state database’.

When the SSP and corresponding database had been deleted, this job had failed to be deleted along with them.

Once this job was deleted, the errors stopped occurring.

Resetting the SQL Service Account Password for SharePoint (MOSS) 2007

Symptoms
Cannot connect to the SharePoint Central Admin Site (Error 503 Service Unavailable).

This may at first manifest itself as a generic SharePoint “Error” with a “return to site” link that does not work. This is indicative that the SharePoint site is up and running but the SharePoint site cannot connect to the SharePoint Content Database with the current credentials.

Update the following SQL services with the new account password. This assumes that all SQL services use the same account and password.

• SQL Server (instance name)
• SQL Server Agent (instance name)
• SQL Server Browser
• SQL Server FullText Search (instance name)

Restart each service.

The SQL logs will have errors that a specific account from a specific IP address cannot connect.

Login failed for user 'DOMAIN\your.sql.server.service.account'. [CLIENT: 192.XXX.XXX.XXX]

To Correct This

Change the password on a domain controller or via ADUC to comply with any policies that may be in place. This post came about because of a GPO that was being applied to service accounts and admin accounts.

• Log on the server running the Central Administration web site.
• Navigate to the following location:
  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin
  

• Run the following command to change the Farm Credentials account used to access SQL Server
  Stsadm –o updatefarmcredentials –userlogin DomainName\UserName -password NewPassword
  

• When completed, run the IIS Reset command
  iisreset /noforce
  

Verify success by logging on to the SharePoint Site with Internet Explorer.

More help on this can be found at http://support.microsoft.com/kb/934838