I've been working with Michael Herman from Parallelspace on an upgrade/migration workshop for upgrades of SPS 2003/WSSv2 to SharePoint 2007 among other scenarios such as PF, File Shares, etc... John Nisi, Mitch Prince, as well have acted as experts on the Portal and CMS side as well. We had a beta workshop last week in NYC. It was a great opportunity to gather feedback on the effort. It's incredible how this project is really coming together. As challenging as any major web based product is at upgrade. I'm impressed that from an IT perspective, they (now we), have put together some good flexible options around upgrade.
1. In place upgrade - of course for hardware reasons you're going to want to have an option like this, so for small environments you're not needing additional hardware or additional expenses. Be sure to get a good backup if you take this route. You'll pretty much be down while the upgrade takes place, the options are few, but this is the quickest route to getting the job done.
2. Side by side upgrade - running V2 and v3 or 2003 and 2007 side by side on 2 different IIS web applications (IIS virtual servers) in the same farm may sound strange, but this gives best of both worlds options... the ability to preserve on hardware costs... minimize user impact, and the ability to quickly roll forward or rollback and with customizations or no customizations, you'll find this ability very useful.
3. Database attach/content database migration - having 2 different farms on different hardware, given it's the right time of the year to invest in hardware... this option is great for really seeing your farm have a clean v3/2007 experience. I really like the idea of taking a content db and simply taking a good backup, making a copy of the db, and attaching it to the v3 FE's. Automatically Microsoft Office SharePoint Server (MOSS) 2007 will know to upgrade the content in the database. There is planning of course on disk space on the SQL side and IIS/DNS namespace for something like this, but as well this gives you options for a quicker upgrade than the side by side, but methodical and easy to roll back.
I'm not including all the pro's and con's here in this post, and I'm not including an option that I think will really help ITPros be successful in their upgrades...
Imagine there are 3 buckets of customization in a farm.
1. Those sites that are not unghosted (uncustomized)
2. Sites that have been customized to add functionality included in the next version (breadcrumbs, custom nav, remove site settings (security trimmed UI), etc..) or slight modifications (dataview web parts, images outside of zones)
3. More than light customization.... More dominant look and feel change, possibly via custom site definitions or site templates (doesn't look like the out of the box SharePoint site)
If all your sites fall into bucket 1, such as blocking FrontPage modification, or a bit of #2, then upgrade will be straightfoward and possibly an enjoyable? experience.
On the other hand if you have modified the out of the box site definition (against PG's recommendation) or have made some heavy look and feel changes that fall into #3. There are options for you. There are abilities to map 2003 site defitions to 2007 site definitions and site features. Partners are doing work in this area as well. The product group knows that these customizations which have created a conscious branching of the out of the box templates are "ok." They will give you the ability to upgrade all the #1 sites, and keep the others with the 2003 look and feel and features, giving site administrators the ability to "reghost" their sites. A scan tool which will ship with the product will give you the ability to "see" what pages have been customized and fall outside of bucket #1. Note this is not an option with the upgrade in place with the current plan of record.
The reason I put this out there, is to encourage people to follow some best practices with current environments...
1. When adding custom web parts or dataview web parts, add them to a dummy site, export then import onto your real site... (giving credit to Dustin Miller for this best practice)
2. Storage and Database sizes -managing your databases to a decent size such as 25-50GB will make upgrade easier to manage in all 3 upgrade/migration scenarios. If you're planning hardware now, you may want to consider the option you'll use and think about some additional disk space for side by side databases during and post upgrade, maybe an extra space for the database backup pre-upgrade
3. Bin vs. GAC - I haven't talked about custom web parts, but you'll find that when the assembly is in the GAC it will work post upgrade. That's not to say that's best practice. My saying is... Make sure you know that what you add, you can remove. That's as well to say, that what you add, you can re-add. Re-deploying or re-registering the assemblies or webparts should be a familiar task for admins. Deployment does become soooooo much better in farms with multiple FEs.
4. Namespace & Consolidation - I totally recommend keeping a tight ship. Keep the number of IIS Web Applications/IIS Virtual Servers and namespaces to a minimum. Avoid IIS Vservers with multiple names as well. That becomes very difficult to deal with during upgrades/redirects, etc... Having a few databases is ok, it's not that much of an incremental, you'll find that having lots of IIS virtual servers is a pain.
5. RAM - yes RAM and FE's play well together, if you're thinking about the side by side, extra RAM will ensure a smoother upgrade 4 GB is recommended to start.
6. There are special considerations for shared services. Search/Profiles are the ones you should consider most. Think about these services in all 3 scenarios. Consider the time it will take to index post upgrade as well.
If you're doing a lot with SPS Alerts, let me know I'd like to understand the scenarios. If you're not, don't invest a lot in the indexing based alerts. Note the alerts on content in the mysite are actually WSS alerts underneath (utilizing the timer service vs. indexing).
Note... these thoughts are my own based on my own understanding, there's no guarantees in what I've said here. Ha ha, I'm already thinking like a product manager.
工具 
說明
