PeopleSoft Upgrade Woes

When upgrading a PeopleSoft database from 8.47 to 8.49, we ran into a curious problem, receiving this error:

SQL Error. Error Position: 14 Return: 6550 - ORA-06550: line 1, column 15: PLS-00103: Encountered the symbol "TABLE" when expecting one of the following: := . ( @ % ;

It turns out that it was a simple problem, but it wasn't at all obvious from the error: the DDLORA.DMS script that ran during the initial part of the upgrade was old; for whatever reason, it hadn't gotten updated by the install process. This is what was happening: Datamover was importing the tables, and the first succeeded. Then: it went to compute statistics. That's where things went wrong. Here's why: the ddlora.dms script defines not only default tablespace parameters, but also the method by which DataMover will compute statistics. Pre-8.48 PeopleSoft did it using the 'analyze table' method, while 8.49 uses the dbms stats method. With the old statistics parameters in the PSDDLMODEL table, the compute stats call failed, and so did the upgrade.

To fix this problem, we installed PeopleTools 8.49 again on an empty PS Home, and then we copied the new script over.

404 (Not Found) Error When clicking on MySite "My Profile" tab in SharePoint

This error is vexing, though there's a simple solution documented in MS kb924399. I've summarized the solution below with some assumptions about settings that folks normally use. In short, the problem is that there isn't a site collection set up using the appropriate template in the MySite web application. We'll correct that in a few steps. Note: it's entirely possible--even likely--that you've already got a site collection created at the root of the mysite web application. If this is a single personal site, that's part of your problem. This site will need to be backed up and deleted before you can go further, assuming that all of your other personal sites are using a different path. First, we need to create the managed path that SharePoint will use for this site collection.

This can be anything, but most people will have created their sites with the default root ( / ) site collection. So we'll go with that for our purposes.

To do this, click on Application Mangement -> Define Managed Paths. Make sure, once the defined managed paths screen comes up, that you've got the correct MySite web application selected in the top-right. Go ahead and create the managed path at the desired location.

Next, we'll want to create the site collection using the correct template.

Click on Application Management -> Create Site Collection to bring up the site collection screen. Make sure you've got the correct web application selected on the left, and then select the managed path you created in the step above for the URL.

Give the site collection a title, like 'Personal Sites', and -- here's the money part -- select the "My Site Host" template from the Enterprise template tab.

Fill in the site administrators fields appropriately and click on OK.

After doing these steps, the My Profile tab should work again.

Simplifying SharePoint Structure with Site Collections

Site Collections in SharePoint 2007 are the "pieces" of a web application. Personal sites (my site), for instance, are each a site collection. There are a couple of real benefits, too, for using many site collections--instead of multiple web applications--to form the bulk of your SharePoint implementation. SharePoint Maintenance On the whole, it's simpler to have few IIS web sites (and few web applications) and many site collections. This provides for fewer urls (and thus fewer IIS sites) and fewer ACLs (permissions) to maintain. The permissions piece, in particular, can become a real bear in a large SharePoint installation, as each piece of a web application and all of the pieces of all of its site collections can all have different permissions assigned to them. Using site collections as the primary content-delivery piece can simplify the permissions considerably. Backups/Restore Backups in SharePoint are a tricky business, partly because Microsoft gives you many ways to perform backups and recovery. The simplest solution for backing up your SharePoint installation is to do a farm-level backup, which gives you the option of restoring individual web applications. The downside to using lots of web applications, as most SharePoint administrators quickly discover, is that you end up with a multitude of IIS web sites. To create subdirectories within these sites, administrators create site collections within them, giving a pretty complex structure. Moreover, when you perform a web application backup, you have to restore the web application, which includes all of the site collections contained within it. That complicates the restore process quite a bit. Some implementations (particularly very large SharePoint sites) will benefit from the above scenario, but most people can get all the functionality and simpler administration by using site collections as the primary structural unit. Because you can backup and restore individual site collections, it allows you a lot more flexibility and granularity in your backup and restore strategy. Moreover, it happens from time to time that a web application configuration become corrupt, such that, for instance, the my sites functionality no longer works. If you have backed up the individual site collections from that web application, it is a trivial task to create a new web application and import the component site collections into it. Backing up site collections, however, does bring up a problem: because stsadm (the admin tool used to backup site collections) requires a site collection url as a command line parameter, there's not an out-of-the-box way to backup all site collections in one fell swoop. Happily, this problem has been recognized by many competent scripting folks. The script we use is a modified version of the one posted by Mauro Cardarelli on his blog. It runs through all of the site collections in a given url and backs them all up individually. Note that, should you use this script, it was written for SharePoint 2003, and as a result, the path to the stsadm executable needs to be updated from C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN\stsadm to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.