SharePoint Portal Server 2003 SP2, or How Not to Design a Service Pack

Microsoft released SharePoint Portal Server 2003 Service Pack 2 (SP2) in October 2005, following the weeks-earlier release of Windows SharePoint Services Service Pack 2 (SP2).  I was hoping to get .NET Framework 2.0 installed on our SPS Web server for other purposes, so I was hoping that Microsoft addressed the .NET Framework 2.0 incompatibilities with SP2.  It looked promising because WSS SP2 specifically mentioned ASP.NET 2.0 support.

After reviewing the release notes and backing up the portals and sites with the SharePoint Portal Server Data Backup and Restore tool, I installed WSS SP2.  It installed cleanly with no issues, so I was off to a good start.

Next was the SPS SP2 install.  Microsoft’s Office team has produced a lot of complicated service packs in the past.  They should know how to do it right.  Clearly this is a different team, because the folks that signed off on QA and user experience for this one deserve to be fired.  Running this service pack produces the familiar Windows Installer progress dialog, which runs for a while and then disappears.  There is no confirmation when it finishes — no matter whether it succeeds, fails, or falls somewhere in between.

It turns out there are two phases to the SPS 2003 SP2 installer.  The first phase upgrades SharePoint Portal Server’s program installation with SP2 files.  The second phase goes through each of your portal sites and attempts a database upgrade on each one.  This is where my four hour struggle began.

The only way you can tell if your SP2 install succeeded, or to what degree, is to read the event log.  You MUST do this.  Search the Application event log for an event that contains text similar to this:

Attempted to apply update to SharePoint Portal Server 2003 portal sites.
Number of portal sites: value
Number of portal sites attempted: value
Number of portal sites successfully updated: value
Not run: value

In my case, this is what I found:

Attempted to apply update to SharePoint Portal Server 2003 portal sites.
Number of portal sites: 1
Number of portal sites attempted: 1
Number of portal sites successfully updated: 0
Not run: 0
Consult the ReadMe file included with this patch, or *_spsadmin.log for more details.

Once again, looking for this “successfully updated” mismatch with “attempted” in the Event Log is the only way you will know the result of your SP2 install.

Next stop was \Program Files\SharePoint Portal Server\Logs, where I found logs that contained the same text and some unhelpful .NET exceptions.  In order to make SPS retry the database upgrade, you have to edit the registry.  [WHAT?!?  Yes, it’s true.]  Here’s a KB article that describes the registry modification.  I probably made this change 30 times over the next 3-4 hours.

I eventually found an obscure WSS/SPS KB article or two (unrelated to SP2) while grasping at straws, ended up restoring my sites and portal from the backup, and eventually managed to get it to upgrade the database successfully.  It was not a pleasant experience.  After all that work, it looks like SP2 may have added or modified one app.exe.config file for Framework 2.0 compatibility.  It’s possible that there were other changes, but SPS portals remain incompatible with ASP.NET 2.0.  Do not run your portal sites under ASP.NET 2.0 (I tried for a while).

Please do not skip your backups before these upgrades, and be ready for possible troubles.

%d bloggers like this: