Don't be afraid of Prescan - Part 1
Prescan is your friend. Without prescan you *WILL* fail your upgrade from WSS 2.0 or SPS 2003 upgrade attempts, even if you plan to simply run setup to perform an upgrade.
One of the most common mistakes in fact is people that take an environment and think... ok I'll try this once and if I have problems, then I'll pull out the manual. DO NOT ATTEMPT THIS.
I don't like technical manuals either. I don't like reading step by step material, but I do love to see screenshots and technical details when I get stuck or stumped. My suggestion is this. If this describes you. Then make an exception. Upgrade is complex. After you understand it, you may say, WOW that was easy, but if you said that it's likely because you first read the upgrade steps and a few blogs and attempted it on a virtual machine or on a test environment or went to one of the classes on upgrade to first get your feet wet.
I know some customers were freaked out by the idea of running a pre upgrade scanner that would "make changes" to the database. These changes are *required* changes and will not harm an environment that still may not be upgraded for a year or two. You can run prescan as many times as you'd like and even if you're not planning to upgrade I recommend it.
Let me repeat... Best Practice: Run Prescan on your WSS 2.0 environment to discover problems with it. Run Prescan with the special PortalSchema.xml file on your SPS 2003 environment... even if you don't plan on upgrading.
Here's an example of Good output from prescan, and will give you a glimpse of how to quantify your upgrade experience.
Example of good PreScan results:
07/19/2006 17:17:01 Scan finished without failure.
07/19/2006 17:17:01 Number of sites skipped (already scanned): 0
07/19/2006 17:17:01 Number of sites scanned: 100
07/19/2006 17:17:01 Number of broken sites: 0
07/19/2006 17:17:01 Number of webs scanned: 138
07/19/2006 17:17:01 Number of broken webs: 0
07/19/2006 17:17:01 Number of webs using custom template: 0
07/19/2006 17:17:01 Number of pages scanned: 0
07/19/2006 17:17:01 Number of unghosted pages: 63
When I say quantify, I mean quantify. The number of unghosted pages will tell you exactly how much of your environment was customized with FrontPage or modified. It's not necessarily a bad thing, but does help you understand how much someone will need to look at... post upgrade. It may even assist you in your decision around your upgrade method and whether or not you want to force the "revert to site definition."
How do I reghost during upgrade?
i.e. psconfig.exe -cmd upgrade -sidebyside -reghostonupgrade
This offers the flexibility of doing your gradual upgrade and at the same time avoid the pain of going in afterward to revert. If you know you want to overwrite the frontpage customizations, this is the way to do it, and still have the ability to do it in a gradual or side by side method.
As was said on one of the blogs, sorry can't locate the reference. "Sites are not unghosted, pages are unghosted." If you've decided you want to reset a page to the site definition, you do have the ability to reset the entire site back to the site definition by checking the box... "Reset all pages in this site." If you've got a large environment, this is one of the most important strategic questions is how to deal with site customizations.
After upgrade, it's common for a page to fail to render due to ornery controls/web parts. Error messages are not actionable by the user. Your options are to revert to site definition for the site (reghost), or open the page in SharePoint Designer and delete the offending web parts or remove references. Using SharePoint Designer to reghost pages offers the flexibility of changing your mind. I do recommend using SharePoint Designer if you're unsure you want to take that route.
One untrue myth came out at a customer meeting I had. They had heard that you couldn't create new sites while you were in the process of a side by side aka gradual upgrade. This is not true. You can create WSS 2.0 or WSS 3.0 sites during the gradual upgrade process. In fact they are on two separate web applications. It's a unique time where a single server is essential part of two different farms.
Check out Bill Baer's blog's on prescan. He's got the most verbose error list for understanding your prescan logs:
prescan errors what they mean.
More later.
