SharePoint

SharePoint Upgrade - Completed - Final Thoughts

Scott Lock — Mon, 20 Oct 2008 15:29:09 GMT

After many long hours working on upgrading our clients intranet from SPS 2003 to MOSS, we completed the rollout over a very long weekend. Ed Buhain, the client and I spent a fair bit of time babysitting the process, tackling last minute gotchas as they came up.

One of the final issues we had was after all of the time testing, debugging, prepping, etc we had not run through the upgrade process with the infrastructure update applied. I was fully prepared to do my workarounds in order to get all the content moved. However, during upgrade process we learned that many of the issues that we had hit previously were now no longer issues. I must assume that these bugs were addressed in either SP1 or the infrastructure update. For example:

We fully expected that the WSUS_ database would not be sized correctly, therefore large content DB's would cause it to autogrow when copying the document related tables. The temp database did size correctly or adequately during the upgrade.
Timeouts were an issue due to the tempdb and wsus_ databases thrashing SQL Server. This also did not seem to be an issue during the upgrade. SQL Server stayed relatively quiet during the process.

We did run into an issue with creating advanced search pages and a search center. Still working those bugs out. All in all I think it was a success. We also managed to squeeze in a new master page with a fresh new look and branding which ultimately was the "sizzle" the new site needed.

Good times...good times.

Timeout Error When Upgrading SPS 2003 Content Database

Scott Lock — Fri, 25 Jul 2008 05:34:10 GMT

Man, this issue has been kicking my butt all day. We've been working on a SharePoint 2003 upgrade (testing) and got to the final content database. Life was good up to this point. 110GB of content had upgraded and there were just a few hiccups, mostly related to size. Then, it came. The nasty, evil, dispicable:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Over and Over...

Basically what's happening from what we can tell is SQL Server is choking on the large document library table copy (dbo.doc) and (dbo.docversion). The temporary database (WSSUS_) log file timesout during autogrowth. It just can't keep up with the upgrade.

I'm trying again...this time I've set the autogrowth to grow by MB instead of percentage. This is a tricky to get set simply because this database isn't created until the process starts.

UPDATE

The solution turned out to be relatively simple. I grew the transaction log for the WSSUS_ database to 70GB which effectively stoped the autogrow thrashing. After doing this, the process completed as expected. The trick is that you have to run the script:

The catch is that you have to run it after the WSSUS database has been created. I simply watched in Managment Studio until I saw the database in the list and ran the script. It took 13 minutes for my hardward to execute the query.

ALTER

DATABASE [WSSUP_Temp_675cfeec-6d15-414a-aae2-a3deabbbf01b] MODIFY FILE ( NAME = N'WSSUP_Temp_675cfeec-6d15-414a-aae2-a3deabbbf01b_log', SIZE = 73400320KB , FILEGROWTH = 10240KB )

We also changed the default file location to a local disk rather than a SAN connected volume. This may have had some impact, but did not solve the problem.

Database gotchas when upgrading SPS 2003 to MOSS

Scott Lock — Tue, 22 Jul 2008 23:10:12 GMT

Again, maybe old news but I thought I would post something interesting that happened during a recent upgrade from SPS 2003 to MOSS. SharePoint is very finicky when it comes to database transactions and sizing during the gradual upgrade process. Here are a couple of things to note:

1. Make sure you have enough size - When upgrading a site that had about 150GB in content, we needed about 500GB in space to complete the migration.

2. Make sure you know where your _Pair DB's Are - SharePoint for some reason didn't put the _Pair db's on the default data and log file locations (C:\) and had to be moved to a larger volume. This caused the upgrade to fail with space issues.

3. Make sure to set the _Pair data and log files to AutoGrow - Now that you have the right amount of space, make sure that you configure the new databases to grow correctly. Large content databases will have large transactions when copying the sitecollections. This can also lead to things like timeouts and space issues. You should also consider setting the recovery model to "Simple" during the migration to keep things tight.

Just some things to think about.

SharePoint gradual upgrade disabled when using a SQL instance named SharePoint

Scott Lock — Tue, 22 Jul 2008 23:03:55 GMT

This may be old news, but we just hit this issue the other day. If you try to upgrade an instance of SharePoint Portal Server 2003 or WSS 2.0 that is running on a named instance of SQL Server called "SharePoint", the gradual upgrade option is greyed out. It turns out that this is because the installer thinks that you are trying to upgrade an instance of MSDE. Changing the instance name to something other than "SharePoint" does the trick. Talk about hardcoding something...

Setting up an SPS 2003 VM to test a MOSS Upgrade

Scott Lock — Sat, 19 Apr 2008 03:44:13 GMT

I finally got a Virtual Server 2005 VM running with my clients entire intranet SPS 2003 portal running. It took a bit of time to restore all 70GB of content data. What I have now is a 120 GB VM that is a great way to test the upgrade.

Here are some lessons learned:

1. VPC 2007 to Virtual Sever 2005 Does not always work as advertised - I started off this project with a baseline Windows 2003 VPC built on my laptop. The trick is that the VPC used specific IDE controller drivers based on the hardware configuration of my Dell Latitude 820. I tried to move this over as is but got the BSOD during reboot. After several failed attempts to fix the image, I ultimately had to rebuild the image on VS 2005.

2. Size Matters - When you build a new image, make sure you size it appropriately. Dynamic disks are great, but when you need to restore a 52GB database, you need to make sure you have at least that much space to do the restore. Fixed disks do the trick here, but how do you convert a disk that was already fixed at 64 GB? Easy...you download VM Resizer, epand the disk then use DiskPart to extend the partition. Worked like champ. One thing to note, if you are extending a VHD that you plan to keep as an IDE drive, make sure to keep it under the 127GB max size.

3. It makes a "Difference" - Use Differencing disks. Repeat. Use Differencing Disks. It's not easy to use undo disks on a VHD that is 120GB in size. Even on a SAN that's a lot of disk space. By building that baseline and using VS 2005 differencing disks, you can keep that baseline pristine and make changes to a seperate vhd.

4. Know Thy Version - If you follow Jeff Holliday's Blog Entry on Restoring SharePoint Production Servers to Test Servers it is very easy to actually restore the portal. What's the catch? You ABSOLUTELY need to make sure that WSS 2.0 and SPS 2003 are up to the same version. There were a few posts and comments from folks who got this error:

'SvrAdminPortalCreate_SecurityConfigurationSection_Text' is not a valid value for attribute 'TitleLocID'. It must be of enum type 'Microsoft.SharePoint.Portal.WebControls.LocStringId'

This was because there was a mismatch in version between the production source server and the test target servers. You can verify versions against this chart and install the appropriate hotfixes, patches, and service packs.

Hope that this helps someone along the way.