Upgrading from SharePoint 2007 to SharePoint 2010 WHAT’S IN THIS CHAPTER? Supported upgrade methods Considerations for upgrading your farm and content Patching your SharePoint 2010 farm SharePoint 2007 has been good to us. For many of us, SharePoint 2007 was where SharePoint started getting taken seriously. No more getting sand kicked in its face when it was at the beach; SharePoint was a force to be reckoned with. Because of that, it almost seems disrespectful to talk about abandoning it for its newer, fl ashier sibling SharePoint 2010. Take heart, SharePoint 2007 understands. We sat down and had a long talk with it. “Dear SharePoint 2007, it’s not you, it’s me …” You have a lot of good options for moving your SharePoint 2007 content and farm to SharePoint 2010. In this chapter, we cover those options in detail, as well as discuss some ways to make the upgrade less painful for you, and your end users. At no extra charge, we also talk about upgrade’s cousin, patching, and how that has improved in SharePoint 2010. There is a lot to cover, so let’s dig in. UPGRADE CONSIDERATIONS While this chapter is chock full of great upgrade information, most of you are here for the “how.” A lot of planning goes into upgrading, and there are a lot of gotchas to look out for, which are no fun. Of course, what you want is the nitty gritty about how to actually upgrade 5 114 CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 your SharePoint 2007 farms to SharePoint 2010. Don’t worry, we’ll get to all that later, but first we need to lay down some upgrade ground rules. After covering the basics, we will dig in with more details about each of the topics. What Can You Upgrade? Before we can talk about how to upgrade, you need to be clear about what you can actually upgrade. The only supported platform you can upgrade to SharePoint 2010 is SharePoint 2007 — and not just any old SharePoint 2007, it has to be at least service pack 2 (build 12.0.0.6421 to its friends) or later. (If you try to pull the wool over SharePoint 2010’s eyes and attempt to upgrade an older version, it will stop you, call you bad names, and leave you feeling ashamed.) This is true for both upgrade options: in-place and database attach. Speaking of those upgrade options, let’s talk about those a little. An in-place upgrade takes place when you install SharePoint 2010 on your existing SharePoint 2007 machines. It functions nearly the same as the in-place upgrade from SharePoint 2003 to SharePoint 2007 did, only without all the failures and swearing. An in-place upgrade runs on your existing SharePoint 2007 hardware and maintains all your URLs. This is a good fit if you want to upgrade a small environment and use the same machines and URLs. The ins and outs of in-place upgrades are discussed later in the chapter in great detail. Your other upgrade method is a database attach. With this method, you take databases from a SharePoint 2007 farm (service pack 2 or later, of course) and you attach them to a fully func- tional SharePoint 2010 farm. When a database is attached, SharePoint 2010 will upgrade it and render its content. You are allowed to attach content databases, Microsoft Project databases, and SharePoint profile databases to a SharePoint 2010 farm. This method requires SharePoint 2010 be a new installation on new hardware. Both of these methods require some planning and testing to be successful. The most useful tool you can use to discover any upgrade issues you have in SharePoint 2007, and determine how much trouble they will be to upgrade, is SharePoint 2007. In service pack 2, Microsoft introduced a new STSADM operation, preupgradecheck, that scours your SharePoint 2007 farm looking for problems. While running preupgradecheck is not required when doing either type of upgrade, it is recom- mended. It will do a thorough inventory of your SharePoint 2007 farm and report any problems it finds. Not only can these problems impede your upgrade, it may be beneficial to your existing SharePoint 2007 farm to fix them sooner rather than later. Even if your farm does not have any issues, the report that preupgradecheck creates is a good point-in-time snapshot of your farm that is very easy to create. Figure 5-1 shows how to run the preupgradecheck from a command line, and what the output looks like. This report indicates that the user has an unsupported version of SQL Server, so an in-place upgrade is not possible. The last line of the report directs the user to view an HTM file. This file is where you can get in-depth information about your farm. Figure 5-2 shows the first page of this report. Upgrade Considerations 115 FIGURE 51 FIGURE 52 116 CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 Here you can find more information about the upgrade blocking error found. Note the bottom of the report, which shows some of the components in the farm. This is one of the reasons this report is handy, even before you begin your upgrade. Here is a partial list of the problems preupgradecheck looks for: Farm is at service pack 2 or later Supported operating systems (Windows Server 2008 SP2 64-bit or Windows Server 2008 R2) Database schemas have not been modified Configuration database does not have any site orphans Content database does not have any data orphans Farm is not still in a gradual upgrade from SharePoint 2003 Databases are read only Invalid entries in web.config Custom site definitions Large lists Views and content types that use CAML Knowing what problems there are is great, but it can be a bit overwhelming if you run preupgradecheck and your screen fills up with red errors. Fortunately, the HTML report is full of links, and when it finds a problem it will direct you to a web page that describes the problem further, and offers ways to fix it. In many cases the solution to the problem is in the HTML report itself. Preupgradecheck uses an XML definition file, so the list of issues can be updated with cumulative updates to SharePoint 2007. Third-party vendors can also supply XML to clear up errors caused by their additions to your farm. The report has a time and date stamp in its name, so you can run it as many times as you’d like. Note that running preupgradecheck does not write to your databases in any way. Because it is a read-only operation, it does not change anything. Run it early, and run it often. Unsupported Scenarios Now that you know what you can do, it is important to reiterate some unsupported scenarios. It’s not supported to upgrade SharePoint 2007 to SharePoint 2010 if it doesn’t have service pack 2 or later on it. That includes databases. SharePoint 2010 cannot attach a database that is from a farm earlier than SharePoint 2007 service pack 2. That also means there are no direct upgrades from previous versions of SharePoint, either. If you have a SharePoint 2003 farm, you must upgrade it to SharePoint 2007 service pack 2 before you can upgrade to SharePoint 2010. There is one upgrade option that we had going from SharePoint 2003 to SharePoint 2007 that is missing now: the gradual upgrade, or side-by-side upgrade. This option allowed a farm to be run- ning SharePoint 2003 and SharePoint 2007 at the same time. This allowed a slower, more controlled upgrade. That option has been removed, leaving you with in-place upgrades and database attach options. In-Place Upgrade 117 Upgrade Best Practices Before you get too far down the upgrade road, we should take a short detour to the backup and restore rest stop. Chapter 12 covers backups in SharePoint 2010, but if you’re doing an upgrade, you will need good backups of your SharePoint 2007 environment as well. Nothing makes a grown man scream like a little girl as bad as realizing they don’t have any backups — or even worse, realizing the backups you have cannot be restored. Any upgrades you do should be tested thoroughly in a test environment. Creating that test environment and populating it with data is a great way to test your SharePoint 2007 backups. Not only will this give you a great test environment that approximates your production environment, it also ensures that you have backups that will actually restore. Now that we’ve covered the dos and the don’ts of upgrading, let’s take a closer, more intimate, look at the upgrade methods and how to use them. INPLACE UPGRADE The most obvious path to upgrading SharePoint 2007 to SharePoint 2010 is an in-place upgrade. This method is the simplest, and boils down to clicking Next Next Finished. Tada! Congratulations, you have SharePoint 2010. Well, maybe it’s not quite that easy, but that’s the gist of it. When you do an in-place upgrade, you’re installing SharePoint 2010 on the same hardware as your existing SharePoint 2007 farm, and for the most part everything stays the same. For example, URLs are the same for your users, settings are retained, custom code is still installed, customiza- tions are still there, and application pools run as the same accounts. If you were to envision your “dream” SharePoint upgrade, this would be it. Before you set this book down and try to do an in-place upgrade of your current SharePoint 2007 farm, however, there are also some cons. It’s not all roses and kittens. Your current hardware and software must support SharePoint 2010 before you can do an in-place upgrade. That means all of your SharePoint 2007 servers have to be 64-bit Windows Server 2008 or Windows Server 2008 R2. Your SQL Server must also support SharePoint 2010 for your in-place upgrade to work. These soft- ware requirements are laid out in stunning detail in Chapter 3. Another con to consider is downtime. While you are doing the in-place upgrade, your entire farm will be offline for the duration of the upgrade process. If you have multiple machines in your SharePoint 2007 farm, you need to successfully upgrade them all before any of your content is acces- sible. If the upgrade is not successful, your content will likely not be accessible until the upgrade finishes, depending on where it failed. In addition, when the in-place upgrade runs, it works serially on one machine. If you have multiple web applications and multiple content databases, they will be upgraded one at a time, even if you have multiple machines in your farm. This means that you cannot take advantage of all your hardware during upgrade and the rest of your machines in your farm are just standing around with their hands in their pockets. All of this leads to increased downtime. Planning Your In-Place Upgrade Because of the downtime issues, in-place upgrades are better suited for small environments. In larger environments, the downtime needed to do an in-place upgrade may be too long. In-place upgrades may also not be suited for environments with significant custom code or other customizations. That 118 CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 sounds contradictory. One of the benefits of an in-place upgrade is that the customizations in SharePoint 2007 are maintained. However, in order for your upgrade to be successful, your custom code must run in both SharePoint 2007 and SharePoint 2010. Steps have been taken by Microsoft to increase the possibility of this working, but it is not 100 percent reliable. While the underlying DLL structure has changed dramatically between SharePoint 2007 and SharePoint 2010, Microsoft has put stubs into the DLLs to forward SharePoint 2007 style calls to the new SharePoint 2010 DLLs. This enables most SharePoint 2007 era code to run on a farm upgraded to SharePoint 2010. Of course, the code should be upgraded to use the correct SharePoint 2010 DLLs, but this helps get your environment up and running more quickly, as all of your custom code does not need to be reworked for SharePoint 2010 before you can upgrade. The Feature framework has also been enhanced to ease your transition to SharePoint 2010 (see Chapter 13 for details on Features). It recognizes new settings in the feature.xml file that enable it to run different code for SharePoint 2007 or SharePoint 2010. Since SharePoint 2007 doesn’t under- stand these entries, it happily ignores them. This enables you to update your Features while you’re still running SharePoint 2007 so that when you upgrade to SharePoint 2010, your Feature is ready to go. SharePoint 2010 looks for an UpgradeActions section in the feature.xml file. In this section, you can define versions of your feature, and how to handle upgrading from version to version. When you trigger a Feature upgrade in your farm, SharePoint 2010 checks the feature.xml file to determine the steps necessary to upgrade your Feature, at the four scopes: farm, web application, site collection, and site. While this is more of a topic for our developer friends, it’s good to have a cursory knowledge of it for planning purposes. Table 5-1 provides a list of common customizations in SharePoint 2007 and recommendations on how to deal with them when upgrading to SharePoint 2010. TABLE 51: Common SharePoint 2007 Customizations CUSTOMIZATION GOOD CHOICE BETTER CHOICE Custom Web Parts Probably work out of the box with SharePoint 2010 Test on sample server, plan to rewrite for SharePoint 2010 Custom event handlers Probably work out of the box with SharePoint 2010 Test on sample server, plan to rewrite for SharePoint 2010 Third-party add-ins Contact vender for information on SharePoint 2010 support Contact vender for information on SharePoint 2010 support Custom Site template Create a site with the Custom Site template before upgrade Recreate in SharePoint 2010, pref- erably as a Solution package and Feature Custom site definition Create UDF file for upgrade Migrate to an out-of-the-box site tem- plate and deploy customizations as a Solution package and Feature In-Place Upgrade 119 CUSTOMIZATION GOOD CHOICE BETTER CHOICE Customized ( unghosted) pages Reset to site definition Reset to site definition, and reapply customizations Custom code or pages in /_layouts Probably work out of the box with SharePoint 2010 Test on sample server, plan to rewrite for SharePoint 2010 If your SharePoint 2007 servers meet muster, and if your SQL Servers are compliant with SharePoint 2010, what will your in-place upgrade get you? As mentioned earlier, the appeal of an in- place upgrade is that your environment doesn’t change. All of your users’ bookmarks will continue to work. All of your web applications and site collections are there. If you were running Officer Server or Search Server, then a new SharePoint 2010 search environment will be created with all of your old settings, and you’ll be able to use your SharePoint 2007 index file and property store until you can run your first full crawl. Finally, any customizations you’ve made to your environment in terms of custom master pages, cus- tom themes, and CSS will all be available in your upgraded farm via Visual Upgrade mode. Visual Upgrade is covered later in this chapter, but at a high level it enables SharePoint 2010 to render pages with the SharePoint 2007 master pages and styling. If an in-place upgrade will work in your environment, it does offer a very attractive option. Performing the In-Place Upgrade Executing an in-place upgrade is fairly painless after you have tested your environment and verified that it can be upgraded. You start it just like you would a regular install. First, run the prerequisite installer to get all the software prerequisites installed. Then start the SharePoint 2010 install. 1. On the first screen of the setup, instead of asking if you want to do a Standalone or Server Farm install, you will see a screen like the one in Figure 5-3, indicating that a previous ver- sion of SharePoint has been detected and that if you continue it will be upgraded. FIGURE 53 . dramatically between SharePoint 2007 and SharePoint 2010, Microsoft has put stubs into the DLLs to forward SharePoint 2007 style calls to the new SharePoint 2010 DLLs. This enables most SharePoint 2007. Web Parts Probably work out of the box with SharePoint 2010 Test on sample server, plan to rewrite for SharePoint 2010 Custom event handlers Probably work out of the box with SharePoint 2010 Test. server, plan to rewrite for SharePoint 2010 Third-party add-ins Contact vender for information on SharePoint 2010 support Contact vender for information on SharePoint 2010 support Custom Site