Fresh Content on SharePointJoel.com SharePoint Ads
Subscribe in a reader
2003 and Before
In SharePoint Portal Server 2003 or WSS v2 if you had problems after an upgrade of a service pack it was always smart to run on the command prompt
stsadm -o upgrade
There are other switches to specify specific IIS virtual servers/Web Apps, so you could run (Also works on STS v1)
stsadm -o upgrade -p all
Future WSSv3 and SharePoint Server 2007
In SharePoint Server 2007 on a recent case we found that due to a SQL time out, network connectivity, etc if the error that the schema expected X and got Y as in different version numbers, then you've got problems... it's going to block access to that content database to avoid data loss or such and such. DON'T change the schema number in the database to fix the problem.
Go to the command prompt to the \bin directory and type the following replacing web app for the applicable web app having schema problem with the database.
stsadm -o upgrade -inplace -url http://webapp
It's great for resuming upgrade if your upgrade was interrupted. Don't forget, your upgrade logs will be helpful as well for troubleshooting. Start | Run | then type %temp% and refer to the upgrade.log. If you're going to reboot, move the logs somewhere safe like your my documents folder as this is a temp location that will be cleaned up upon reboot.
An upgrade breaks down into Binary upgrade as well as Content then schema upgrade or those changes going on in the SQL databases. Your binaries may have been upgraded and when you look at the Properties | versions tab on stsadm.exe it may have the new version, but the schema on your content or config database may not have been updated. Running the command above will update the second half of the upgrade which is the database or schema upgrade. When it's complete, it will update the schema version number in the database.
Other Tips1. Make sure when you run the upgrade vs. log in after to verify you are running the same account. Running the upgrade with the service account may be less problematic than under a different user account.
2. Post upgrade check your topology and server/services. If you had to reconnect to your configuration database, check the roles of the servers to ensure the index and search server assignments are correct.
3. Check your event logs. Things may look like they are correct, but you may have undiscovered issues that should come through in your system and app event logs.
4. When you attempt to browse to the SSP search settings after resetting the index—it will specifically tell you that there is no indexer associated with the SSP. It provides you with a link directly to the index settings of the properties of the SSP so that you can properly select it. You could do this manually by editing the SSP properties yourself. Regardless, it is a necessary step.
Thankyou
You're tip on using stsadm -o upgrade -inplace -url http://webapp
ended a long and frustrating time upgrading from the Beta 2 to Sharepoint 2007