Chapter 5: 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, flashier 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 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 functional 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 recommended. 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.

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 running 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.

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.

In-Place 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, customizations 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 software 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 accessible. 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 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 understand 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 5-1: 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, preferably as a Solution package and Feature
Custom site definition	Create UDF file for upgrade	Migrate to an out-of-the-box site template and deploy customizations as a Solution package and Feature
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, custom 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.

For better or for worse, there isn’t much to configure with in-place upgrades. The one important decision to make is whether upgraded content should be rendered as it was in SharePoint 2007 or with the new SharePoint 2010 interface. Figure 5-7 shows the dialog of options and explanations. The facility SharePoint 2010 uses to render content with the SharePoint 2007 interface is called Visual Upgrade. It is covered in more detail later in this chapter, as it pertains to both in-place upgrades and database attach upgrades. The default option is to preserve the SharePoint 2007 look and feel. You’ll learn more about it later, but for most in-place upgrades, preserving the SharePoint 2007 look and feel is the best option. After you’ve selected which interface the content should use, SharePoint gets to the business of upgrading your content.

The steps it takes are in a very deliberate order. The most important objects are upgraded first, to give SharePoint a more solid footing should the upgrade fail and need to be restarted. The first step is to upgrade your configuration database. Once that is successfully done, the installer moves on to the Central Administration web application and upgrades it, including its content database. It then moves on to upgrading any settings that are specific to the server on which it’s running. For instance, when you’re running the upgrade on the server that is running search, the search components are upgraded at this stage.

Once all that is done, SharePoint continues diligently down the road of upgrading your farm. The next stop on its trek is your web applications. Now that all the important groundwork is upgraded, it can move on to the fun stuff. The installer starts walking through the web applications in your farm. For each web application, it walks through and upgrades your site collections one at a time. If for some reason a site collection cannot be upgraded — for example, because it’s based on a custom site definition that hasn’t been dealt with — the installer will skip that site collection and move on to the rest. If that should happen, you can fix the issue and use the Windows PowerShell cmdlet Upgrade-SPContentDatabase to upgrade any objects in the content database that were not upgraded the first time around. This is just one way the in-place upgrade has improved since its last incarnation for upgrading SharePoint 2003 to SharePoint 2007. In the next section, you’ll learn about the improvements in more detail.

Once all of your site collections are upgraded, or SharePoint has at least given it the old college try, the upgrade process finishes. If you have multiple servers in your farm, it’s now time to run the installer and PS Config on the rest of your servers. Because the back end is fully upgraded at this point, the other members should upgrade quickly and smoothly.

If your current SharePoint 2007 farm is WSS, the preceding upgrade steps probably looked complete. If you are using MOSS, you probably wondered where your Shared Service Providers (SSPs) fit in. Because SSPs are gone in SharePoint 2010, their upgrade process is a little more involved. SSPs had two main components: databases and services. Each is upgraded a bit differently. After Central Admin has been upgraded but before your web applications are upgraded, the installer looks at its upgrade roadmap to see if there are any exit ramps for SSPs. If there are, the installer takes a quick detour over there and upgrades the SSPs and wires everything up for them. For each SSP that exists, the install cracks it open and creates the corresponding service applications. For each SSP in your SharePoint 2007 farm, your upgraded SharePoint 2010 farm will have the following service applications:

• Search Administration Web Service
• Search Service
• Application Registry
• Business Data Connectivity
• Excel Calculation Services
• State Service App
• Taxonomy
• User Profile

A picture is worth 1,000 words, so Figure 5-8 shows a MOSS Enterprise farm upgraded to SharePoint 2010. It is a list of the service applications that were created from the very cleverly named SSPs, SharedServices1 and SharedServices2.

You can see how the SSP was broken up and how each old SSP was reborn as eight service applications. When the installer moves to the next step, where it upgrades the web applications, it will wire each web application up with the service applications that match the SSP it was using in SharePoint 2007. After the upgrade is finished, you can associate web applications to service applications from whichever legacy SSP you would like. You can also delete unnecessary service applications that were created during the upgrade process. For instance, you may not need two search service applications in SharePoint 2010. You can associate all of your web applications with one and delete the other. Figure 5-9 shows the service application associations for a web application associated with SharedService1 in SharePoint 2007.

You can see that the default associations are for the service applications that were created from SharedService1, but there are two other options. You can also associate that web application with the service applications from SharedService2, or you could choose the custom option and pick and choose which service applications this web application should be associated with. For more information, see Chapter 7, which is all about service applications. Among other topics, it covers how you can create your own service application proxy groups and edit the existing ones. These are valuable when you have done an upgrade with multiple SSPs and you want to clean up your service applications.

That covers how the SSP services are upgraded from SharePoint 2007 to SharePoint 2010, but we still have the matter of those pesky SSP databases to attend to. The good news is that these are straightforward, because not much upgrades. One of the problems with SharePoint 2007 was that most of the SSP content was stored in one database. With service applications in SharePoint 2010, that is no longer the case, so there is no direct upgrade path for the SSP database. The notable exception to that is the Search property storage database, which SharePoint 2010 can upgrade for its Search to use. This also means you can do searches in SharePoint 2010 before the Search service application has crawled your content. For farms with a lot of content, this is very convenient. Figure 5-10 shows the databases for the Search service application that was created from SharedService1.

In the list of databases, you can see that one of them differs from the others. The administration database and the crawl database have GUIDs at the end of their names and include “Search Service.” The property database is different, though: Its name is ShareServices1_Search_DB. The first two databases were created by the installer when it upgraded the SSP. The property store database is the SharePoint 2007 search database, so it has its old name. Chapter 14 covers Search inside and out, and explains the role each of these databases plays.

To manage SSPs in SharePoint 2007, each SSP had its own Admin site. Because service applications are managed in Central Administration now, these SSP Admin sites are unnecessary. The installer does not upgrade them because there is no corresponding SSP Admin site to upgrade them to. If you browse to one of your SharePoint 2007 SSP Admin sites after you upgrade to SharePoint 2010, you will be greeted by the friendly page shown in Figure 5-11.

Once you have made the BDC changes that the page suggests, it is safe to delete the legacy SSP Admin site. If it was on its own web application, then you can delete that as well.

In-Place Upgrade Improvements

If you have made it this far reading about in-place upgrades, one of two things is probably true: Either you never tried an in-place upgrade from SharePoint 2003 to SharePoint 2007 or you did and you are so shocked that someone is actually suggesting an in-place upgrade to SharePoint 2010 that you just had to read the rest so that you could mock it appropriately. Rest assured, the authors of this book did battle with in-place upgrades to SharePoint 2007 and there are very few marks in the “win” column. It was a pretty tough course, and for the most part it was one to be avoided. In most cases, users did gradual upgrades instead. As you learned earlier, that is no longer an option in SharePoint 2010. It’s time to go back to the drawing board and give in-place upgrade another look.

The list of problems with the SharePoint 2007 in-place upgrade is long and well known. Fortunately, Microsoft took that list of problems, scratched out “Why SharePoint 2007 in-place upgrade is for the birds” at the top, and replaced it with “Things to do correctly in SharePoint 2010 in-place upgrade.” There were two main issues with SharePoint 2007 in-place upgrades. One, it didn’t take much to make it fail. Any number of timeouts could affect it on the SharePoint side or the SQL Server side. In addition, SQL servers ran out of drive space. One time, an office window was left open and a cool breeze crashed an in-place upgrade. It was very fragile; your environment had to be just right for the in-place upgrade to succeed. The other issue made the first one worse. If for any reason your upgrade failed (and there were many reasons it could), there was no way to salvage the upgrade. You couldn’t free up drive space on your server, or close that office window and pick up where you left off. Although that made the decision about what to do next very easy, the bad news is that the answer was to recover everything from backups and start all over — not a very appealing option.

The in-place upgrade in SharePoint 2010 addresses both of those issues, in spades. To address the issue of failures, Microsoft has removed most of the timeouts that caused failures upgrading to SharePoint 2007. Long operations will no longer cause an upgrade to fail. Can we get an “Amen!”? Other common failure points have also been addressed, and no longer cause upgrades to fail. Leave all your office windows open; SharePoint doesn’t care.

Of course, that was only part of the problem; the other part was what to do after a failure. To address that, Microsoft has made the upgrade process restartable. If something does prevent your upgrade from completing successfully, it can be continued after you address the problem. Figure 5-12 shows an upgrade failing because the SQL Server does not meet SharePoint 2010’s minimum requirements.

This error appeared after the SharePoint 2010 bits were installed and the configuration wizard had started to run (after everything was configured as shown earlier in Figure 5-7). After all that, the installer tries to start upgrading the configuration database but errors out because SQL Server doesn’t support it. If this error had happened during an upgrade to SharePoint 2007, it would have been followed immediately by the thump of a head hitting a desk, followed by whimpering and later, loud sobbing. In this case, however, the fix was easy. First, the SQL Server instance was upgraded to a suitable version. Then the configuration wizard was run again. It just picked up where it left off, happily upgrading to SharePoint 2010 like nothing ever happened.

Because the failure occurred before the configuration wizard was able to complete, rerunning it was the obvious way to restart the upgrade process. If the upgrade fails after the configuration wizard finishes, or the configuration wizard finishes with errors, you can use the Windows PowerShell cmdlet Upgrade-SPContentDatabase to restart the upgrade on a content database. While you should certainly do everything you can to ensure a successful upgrade if something goes wrong, rest assured you have options to salvage all your work without resorting to backup tapes or begging deities for help.

Note also in Figure 5-12 a link to a log file to help you troubleshoot the error. The upgrade walks through every step the configuration wizard went through as it upgraded your farm, right up to the point it failed. To make troubleshooting easy, a new upgrade log is created for each upgrade session. This keeps the upgrade log files from becoming any more cumbersome than necessary. In addition, when an upgrade fails, a special upgrade log is created, with -error appended to it. This error log contains only things that went wrong during that specific upgrade session, enabling you to zero in on the information you need to find the problem. If for some reason the upgrade process is unable to write out the upgrade log (due to a drive being full or a permissions issue), then the upgrade won’t start. This prevents any upgrading from happening without it being properly logged.

Database Attach

The second method for upgrading content to SharePoint 2010 is the database attach method. In this method you already have a SharePoint 2010 farm installed and configured. To upgrade your content, you attach a SharePoint 2007 (service pack 2 or later) content database, which SharePoint 2010 will upgrade. Sounds easy, doesn’t it?

The database attach method requires that you have separate hardware for your SharePoint 2010 farm; you cannot use your SharePoint 2007 hardware unless you remove SharePoint 2007 from all of the machines and install SharePoint 2010 on them. The database attach method also usually results in different URLs for your web applications, as the corresponding SharePoint 2007 farm is typically online at the same time.

The main advantage of the database attach method is control. When you do an in-place upgrade, you don’t have much control. You cannot control the order in which the web applications or site collections are upgraded, and you can only upgrade one database at a time, which can be a waste of resources if your SharePoint boxes and SQL Server box can handle more. With the database attach method, you can attach multiple databases at the same time and upgrade them in tandem. The limiting factor is disk I/O on the SQL Server box. Before doing this in production, test your SQL Server box by testing database attach upgrading. Start by doing two databases at once and time the upgrade. Then redo the upgrades and add a third database. Once your SQL Server is saturated, you’ll notice that your upgrade times will dramatically increase. Also keep an eye on the disk queue length on the SQL Server. That will let you know how well the disk subsystem is keeping up.

Because you are starting the database upgrades manually with this method, you also have control over the order in which databases are upgraded. With an in-place upgrade, you can’t control which web applications are upgraded first, and they’re all offline until the upgrade is finished. Conversely, using the database attach method, SharePoint 2010 is already online and rendering content. You have control over which databases you attach, and their content is available as soon as the database is attached. (Our recommendation is to always upgrade the content database that contains your resume first. You can never be too careful.)

There are some considerations when doing database attach upgrades. Because you are attaching content databases only, none of your customizations will be included. Any customizations will have to be manually moved to your new farm. For instance, if the sites stored in the content database require any third-party software to function, that software will have to be installed on the new SharePoint 2010 farm to which the database is attached.

The database attach method also means more work for the administrator and may require access to the SQL Servers if the backups are being moved from one SQL Server to another. You may also need to factor in time and network bandwidth if you have to shuffle databases around.

Another benefit of the database attach method is that it enables you to combine the content databases from multiple farms and consolidate your environment. You may have had multiple SharePoint 2007 farms for a variety of reasons: scale, isolation, hardware, and so on. SharePoint 2010 fixes a lot of those issues, so it might make sense to combine those separate SharePoint 2007 farms into one massive SharePoint 2010 farm. You can use the database attach method to do this before you upgrade all of your SharePoint 2007 farms to SharePoint 2010. Create the additional web applications on your SharePoint 2010 farm and attach the content databases to the appropriate web application.

If you can live with those considerations, then maybe a database attach upgrade will work for your environment. You can use either STSADM or Windows PowerShell to attach content databases to SharePoint 2010. This chapter focuses on Windows PowerShell.

The Windows PowerShell cmdlet you will use to attach to attach the database is Mount-SPContentDatabase. In your perusal of Windows PowerShell cmdlets, you may stumble across the Upgrade-SPContentDatabase cmdlet, but that cmdlet is not necessary when doing a database attach unless part of the database attach upgrade fails. The Upgrade-SPContentDatabase cmdlet retries or resumes a failed upgrade. To prevent that, you should check your content database for potential problems. There’s a Windows PowerShell cmdlet for that, too: Test-SPContentDatabase. While it’s not necessary to test a content database before you mount it, it is a good idea. When you run Test-SPContentDatabase you need to provide it with a database name and the URL of the web application to which you want to attach it. You need to supply the web application because solutions and features can be scoped at the web application level. A site collection in an attached database may work fine with one web application but not work at all with another. Figure 5-13 shows running Test-SPContentDatbase against a SharePoint 2007 database.

Note that you run Test-SPContentDatabase against a database that is in SQL but has not yet been attached to SharePoint. It’s easy to fall into the trap of assuming that SharePoint can only deal with databases that it knows about. That’s not the case here. As shown in Figure 5-13, Test-SPContentDatabase has found a couple of problems with the database. A couple of Web Parts that it references do not exist in the http://upgrade web application. Notice, though, that neither issue is enough to block the upgrade, as the UpgradeBlocking property for both errors is False. Both of those errors are something that we can live with and fix later if the need arises. We will use the Mount-SPContentDatabase cmdlet to add it to our farm, which will upgrade it automatically if it is from SharePoint 2007. Figure 5-14 shows the command to use to attach your SharePoint 2007 database to your SharePoint 2010 farm. Note the percentage, indicating the progress of the upgrade process. You can also watch the upgrade progress in Central Administration. Click Upgrade and Migration in the left navigation pane and check Upgrade Status in the Upgrade and Migration page.

We mentioned earlier that this can also be done with STSADM. STSADM is old and kind of dusty, and we don’t recommend using it; but if you lose a dare and need to attach a SharePoint 2007 database to a SharePoint 2010 farm with STSADM, you can use the command STSADM –o addcontentdb to do it. If you wanted to use STSADM to replace the Windows PowerShell command in Figure 5-14, you would use this:

Figure 5-15 shows the finished product. Even though Test-SPContentDatabase indicated that errors would occur with the upgrade, SharePoint 2010 upgraded it anyway, enabling you to browse the site collection in that content database.

You can use the Get-SPSite cmdlet, as shown in Figure 5-16, to see what site collections you have just added to your farm with your upgraded database.

As mentioned before, one of the big benefits of the database attach method is that you can attach multiple databases at one time. To do this, open multiple SharePoint Management Shell windows and run the Mount-SPContentDatabase command in them.

When you use Mount-SPContentDatabase to upgrade databases, you will notice that the content looks like it did in SharePoint 2007. This is by design. It demonstrates Visual Upgrade, functionality that Microsoft created to ease the transition to SharePoint 2010. It is covered in more detail later in this chapter. If you want your content rendered with the SharePoint 2010 interface, add the -UpdateUserExperience parameter to your Mount-SPContentDatabase command.

This section has spent a lot of time covering attaching content databases because we think that is what the majority of people will do, but content databases are not the only SharePoint 2007 databases that can be attached to SharePoint 2010. Project Server 2007 databases can also be attached to a SharePoint 2010 farm that is running Project Server 2010. Project Server 2007 did not support customizations, so attaching those databases is pretty straightforward.

A SharePoint 2007 SSP can also be attached to a SharePoint 2010 farm. Not all of it can be used by SharePoint 2010 because of the change in architecture, but SharePoint 2010 can take a SharePoint 2007 SSP database and use it as a Profile Services database.

Hybrid Upgrades

In this chapter we have covered the two official upgrade methods: in-place and database attach. Both work well, but they each have some drawbacks that might be deal breakers in your environment. The in-place upgrade maintains all of your customizations and configuration, but it doesn’t leverage your hardware by doing multiple databases at a time, and your entire farm is unavailable during the duration of the upgrade. The database attach addresses those issues but requires you to redo all of your customizations and settings, and will likely require extra hardware to get SharePoint 2010 up and running on before you move your SharePoint 2007 databases over. It would seem that SharePoint administrators just can’t win … .

What if we told you that you can have your cake and eat it too? Using a combination of the in-place upgrade and the database attach, you can get the best of both worlds. To use the hybrid method, simply detach all of the content web application content databases from your SharePoint 2007 farm. Don’t get carried away and detach your central admin content database — leave that one attached. Now you have a SharePoint 2007 farm with all the configuration and customizations, but none of the big databases. The next step is to do an in-place upgrade of that SharePoint 2007 farm. The in-place upgrade should go quickly, as there is very little to upgrade. The infrastructure will be upgraded and Central Administration will be upgraded, but that’s it. After the in-place upgrade has completed successfully, you finish it up by attaching your SharePoint 2007 content databases to your new SharePoint 2010 farm. This is where you get to leverage the flexibility of the database attach method. You can attach the databases in the order in which you want the content to come back online. In addition, because the farm was upgraded in-place, it is accessible. As soon as the database is attached and upgraded, the content can be browsed. If your hardware can support it, you also have the option to attach multiple databases. In other words, the hybrid method has all the benefits of the in-place upgrade with the flexibility of the database attach method. Looks like this book just paid for itself.

As if that were not enough, the hybrid method offers yet another option. If you have another SharePoint 2010 farm already standing, it could upgrade your SharePoint 2007 databases while the in-place upgrade is running. Content databases are portable, so while your production farm is doing the in-place upgrade, or even while it is attaching your content databases, you could have another SharePoint 2010 farm upgrading your databases in tandem. When they are upgraded in the test SharePoint 2010 farm, simply detach them and reattach them to your production farm. Because they have already been upgraded, the hard work is finished and they will be online in a matter of seconds. The hybrid approach has great potential; I think it’s going to go places.

Database Attach with AAM Redirect

If your SharePoint 2007 farm has a lot of content and a lot of customizations, none of the options talked about already may work for you. An in-place won’t work because it will take too long. A database attach won’t work because it would be too much work and too costly to rebuild all of your customizations and get extra hardware. Even the hybrid won’t work because of the amount of time it will take to upgrade all of your databases. What’s a large SharePoint 2007 farm to do?

There is one final tool in the SharePoint 2010 upgrade toolbox, the database attach with Alternate Access Mapping (AAM) redirect upgrade method. Like it sounds, this is basically the database attach method, but with a twist. You start the same way, with a SharePoint 2010 installation in tandem with your SharePoint 2007 farm. You end the same way, by detaching your SharePoint 2007 content databases and attaching them to your SharePoint 2010 farm. There’s an extra step in the middle, though, and that’s where all the magic occurs. For our example, our SharePoint 2007 farm has a web application at http://portal.contoso.com, where all of our content resides. We give that web application a second AAM for http://oldportal.contoso.com. When we create our SharePoint 2010 farm, we also give it a web application at http://portal.contoso.com. However, when we create that web application, we don’t do it in Central Administration, we do it with STSADM and add an extra parameter, redirectionurl. It would look like this:

That’s the magic. Now, when SharePoint 2010 gets a request for a page on a site collection that it can’t find on the http://portal.contoso.com web application, it sends the browser an HTTP 302 redirect to the same site collection but at http://oldportal.contoso.com. This sends requests to the SharePoint 2007 farm where the content exists. Then when you move a SharePoint 2007 content database to SharePoint 2010, SharePoint 2010 no longer redirects the site collections in that content database to SharePoint 2007. This enables you to upgrade your SharePoint 2007 farm over the course of days or weeks, as your content is always online in either SharePoint 2007 or SharePoint 2010. Once all of your SharePoint 2007 content databases have been attached to your shiny new SharePoint 2010 farm, you can retire your SharePoint 2007 farm.

The redirect works well for web browsers, as they understand HTTP 302 redirects. Office applications, however, aren’t quite so understanding. It’s unlikely that users will have shortcuts directly to a document, but it is possible. Also keep in mind that this is scoped at the site collection level. When a request comes in to a SharePoint 2010 web application with a redirection URL, SharePoint 2010 checks its list of site collections for that web application to see if there is a match. If there is, SharePoint 2010 attempts to render the content. If not, SharePoint 2010 sends the browser the HTTP 302 redirect. If SharePoint 2010 has the site collection but not the specific web or page in the request, the user will get a much less friendly HTTP 404 error.

Other Upgrade Options

So far, this chapter has covered how to get your SharePoint 2007 content into SharePoint 2010. There are a couple of other techniques that can be used in conjunction with your upgrade to make things smoother for your end users. In the remainder of the chapter, we cover how to use Visual Upgrade to slowly introduce SharePoint 2010 to your users. We also cover some techniques you can use to minimize the downtime your users experience while you are upgrading.

Visual Upgrade

To help ease the upgrade to SharePoint 2010, Microsoft added a new feature, Visual Upgrade. Visual Upgrade enables the rendering of content using the SharePoint 2007 master pages and CSS files in SharePoint 2010. This enables you to separate the binary upgrade to SharePoint 2010 from the interface. You can upgrade your back end to SharePoint 2010 without having all of your SharePoint 2007 customizations ready for SharePoint 2010. While your content is in SharePoint 2010 it will look like SharePoint 2007 and it will be able to take advantage of your SharePoint 2007 master pages and CSS. This is important, as SharePoint 2007 master pages and CSS files will not upgrade to SharePoint 2010. They aren’t upgraded if you do an in-place upgrade, and they aren’t upgraded if you do a database attach. The interfaces of the two versions of SharePoint are different enough that the elements of the master pages and CSS don’t map easily. Instead of doing the upgrade poorly, SharePoint doesn’t do it at all.

When doing any of the upgrade methods described earlier, the default is always to render the content in the SharePoint 2007 style. This demonstrates one of the philosophies Microsoft followed when designing the upgrade experience, “Do no harm.” If you don’t understand what Visual Upgrade is and you choose the default options, your content will upgrade and render the way that it always has. No harm has been done. After the upgrade is finished, you can choose the SharePoint 2010 interface when you’re ready for it. Earlier, in the discussion of in-place upgrades, you saw in Figure 5-7 where you are offered the choice. The default value is to preserve the look and feel of SharePoint 2007. When upgrading with a database attach, the site collections will maintain the SharePoint 2007 interface unless you specify an interface upgrade with the -UpdateUserExperience parameter. No matter how you get content into SharePoint 2010, you need to deliberately choose the new interface.

Since SharePoint has done everything in its power to keep you from having the SharePoint 2010 interface, how do you get it? You have a few choices. The easiest way is with your browser, in the site itself. Figure 5-17 shows a portal site that was upgraded. It has the SharePoint 2007 interface. In the Site Actions drop-down menu is a new entry, Visual Upgrade. This will be available to site collection administrators.

If you click this option, you’ll be taken to the Title, Description and Icon page in Site Settings. At the bottom of the page are the Visual Upgrade settings, as shown in Figure 5-18.

There are three options. The first, Use the previous user interface, is the SharePoint 2007 UI. The second option, Preview the updated user interface, uses the SharePoint 2010 interface, but it leaves the Visual Upgrade option in Site Actions in case you want to switch back. It’s for site collection administrators with commitment issues. The final option, Update the user interface, uses the SharePoint 2010 interface and removes the Visual Upgrade setting from Site Actions. This is the option to use if you are sure you will no longer need the SharePoint 2007 interface. You can switch back afterward using Windows PowerShell if necessary.

Figure 5-19 shows the same site in SharePoint 2010 Preview mode. The Visual Upgrade option is still present in the Site Actions menu so you can switch back to SharePoint 2007 UI, or commit to the SharePoint 2010 UI.

Once you choose Update the user interface from the Visual Upgrade page, that option is removed from Site Actions. Again, this is scoped at the web level, so that setting must be changed for each web that is upgraded.

Changing the Visual Upgrade setting for all the webs could be cumbersome if there are a lot of them. Fortunately, you can use Windows PowerShell to do this more efficiently. Each web has two settings that need to be changed: which version of the UI to use, and whether the Visual Upgrade setting is enabled in the UI. The following code updates the web from Figure 5-17 to the SharePoint 2010 interface and removes the configuration option:

Code file Chapter05_code.txt

That works well for one or two webs, but it could be slow going for a few hundred webs. One of the benefits of Windows PowerShell is its ability to loop through objects. The following code will loop through all of the site collections in a content database, then loop through all of the webs in those site collections, and set them all to the SharePoint 2010 interface and turn off the Visual Upgrade setting:

If you want a quick report showing which interface each web in a site collection is using, you can use the following code:

The output should look something like Figure 5-20.

This makes it easy to discover which webs need to be upgraded. It could be expanded to run across the entire farm if a larger report were needed. Be sure to test out Visual Upgrade when planning your farm upgrade; it provides tremendous flexibility and eases the upgrade for the end users.

Mitigating Downtime with Read-Only Databases

No one likes downtime, and SharePoint users are no different. Sadly, there is no such thing as a “no downtime upgrade.” However, using some of the techniques in this chapter, you can control and minimize the downtime you have to experience.

Earlier in this chapter we covered the database attach with AAM redirect upgrade option. This is a great way to control downtime, as you have both farms (SharePoint 2007 and SharePoint 2010) online at the same time. When we discussed the hybrid method, we mentioned another downtime mitigation technique: upgrading your databases on multiple farms at the same time, and then attaching them quickly to your production SharePoint 2010 farm. These both work well, but your SharePoint 2007 content has to be offline during the duration of the upgrade. You don’t want users changing content in SharePoint 2007 while you’re upgrading the database.

We have one more trick up our sleeves to help minimize downtime. Behold, the read-only database! Beginning with service pack 2 for SharePoint 2007, SharePoint can now gracefully handle a content database being set to read-only in SQL Server. If the database is read-only, SharePoint will render its content, but not allow any changes. If you couple that with the other techniques, you shorten the amount of time SharePoint 2007 content is unavailable while upgrades are happening. In the database attach with AAM redirect method, you would set the content database to read-only and copy it over to SharePoint 2010 to be upgraded. Once it’s upgraded in SharePoint 2010, simply detach it in SharePoint 2007.

This technique could even be used with an in-place upgrade. In that case, you would need to stand up a temporary SharePoint 2007 farm to host the read-only content while the production farm is being upgraded. It’s a little extra work, but if your environment needs uptime it’s worth considering.

Patching SharePoint 2010

It seems almost anticlimactic to cover patching after covering all the great improvements that have been made to upgrade, but since we promised it in the Introduction it only seems fair to follow through.

Patching SharePoint 2007 wasn’t a bad experience, as long as your farm was exactly one server and didn’t have much content. As soon as you added that second machine, or started getting a few GBs of content, things got scary in a hurry. Patching, at its most basic level is simply an in-place upgrade. The upgrading that was covered earlier in the chapter is referred to as a version-to-version or a v2v upgrade, since we are upgrading from the SharePoint 2007 version to the SharePoint 2010 version. Patching is referred to as a build-to-build or b2b upgrade, as it is only upgrading to a newer build of the same version. Under the covers though, they’re very similar. Not identical twins, but maybe fraternal twins.

We’ve already covered the shortcomings of the 2007 in-place upgrade, and two of those were of particular concern when patching. The patching process ran serially and could take a long time with large content databases. There was no way around that. Second, if the patch failed there was no way to resume. It was time to dust off those backup tapes and order some pizza. Both of those problems and a whole lot more get addressed in the SharePoint 2010 patching story.

One of the most liberating improvements in patching with SharePoint 2010 is that the binaries on your farm can be at a newer version than the databases those binaries are using, if both builds are in the same compatibility range. The compatibility ranges should be between service packs, meaning that any database that is SharePoint 2010 SP1 or higher should be able to be rendered by binaries that are at the same build or later, but before SP2. This gives you the freedom to upgrade your binaries without immediately upgrading your databases at the same time. Walking through all your databases and upgrading them is the most time intensive part of patching, so being able to postpone that is a huge advantage. You’ll be able patch the binaries running on your servers quickly and take advantage of any fixes or security updates without having to incur the downtime penalty of upgrading your databases too. You can postpone the lengthy database upgrade part to a more convenient time, like over the weekend. Also, since the binary upgrade isn’t coupled to the database upgrade, you can do the database upgrades in waves instead of all at once. This is especially handy if you have user bases in different time zones. While you shouldn’t plan on leaving your farm in this condition for weeks or months, you can safely do it for a few days.

If you do decide to upgrade your content databases, you can do it manually with Windows PowerShell using the Upgrade-SPContentDatabase cmdlet. Provide Upgrade-SPContentDatabase with the name of the content database you want upgraded and it’s off. Like Mount-SPContentDatabase, you can run multiple copies of this at once to make the upgrades go more quickly if your hardware can handle it. When you get around to finalizing your patch installation with the configuration wizard, any content databases that are not already upgraded will get upgraded, along with any service application databases that need to be upgraded.

Not only can your databases be out of sync with the binaries installed on your server, but the servers themselves can be at different build levels as well. This is truly an advanced move, however, and should only be used when necessary by trained professionals. If you do choose to patch your servers individually it’s recommended that you do tiers of them at a time. For example, if you have several servers running the Search component, try to keep their patch level in sync. If you have multiple web front ends (WFEs), keep them in sync. If you want to improve uptime by patching your WFEs in waves, then make sure all the WFEs that are accepting end user traffic are at the same patch level. This means you can’t stagger them in and out of your load balancer as you patch. For instance, if you have four WFEs you can pull two of them out and patch them while two stay in. Before you add the two patched WFEs back into rotation, pull out the two unpatched WFEs. That way all the WFEs serving pages to end users are at the same patch level at all times. It won’t be the end of the world if they’re mismatched, dogs and cats won’t be living together or anything, but it will likely result in an inconsistent or confusing experience for the end users. That will mean angry phone calls to you, and none of us wants that.

After all the servers in your farm have a patch installed, you need to run the configuration wizard on them all to finalize it. If you try to be sneaky and run the configuration wizard before all of the servers in your farm are at the same patch level, you’ll get a very stern talking to from it while it glowers at you over its glasses. It will tell you which servers are out of sync and wait patiently for you to get your act together and install the patch on them before it proceeds. As with SharePoint 2007, you do have to run the configuration wizard on each and every server in your farm. Unlike SharePoint 2007, the steps are very fluid. It doesn’t matter in what order you run it on the servers and there is no coordination needed. In SharePoint 2007, the configuration wizard would stop at various stages while it was running, and advise you to go to other servers in your farm and complete steps. In SharePoint 2010, the configuration wizard handles that all itself by writing entries in the Config DB file as different machines complete different tasks. After the configuration wizard is running on all of your servers, you can feel free to go out and have a nice dinner, followed by a very fattening dessert. The configuration wizard will finish the farm upgrade all on its own and start serving out pages without any human intervention. It will upgrade any content databases you have not already upgraded with Upgrade-SPContentDatabase and it will upgrade any other databases that need to be upgraded. When you get back from dinner, click OK a couple of times and your farm is officially patched.

Summary

The road from SharePoint 2007 to SharePoint 2010 is not a complicated one. There are several paths you can take, depending on what’s best for your environment. If you have customizations you want to keep, you can do an in-place upgrade. If you want more control over your upgrade, the database attach method might be appropriate for you. If you have complex needs, or the desire to flex your SharePoint muscle, you can choose one of the advanced methods. Once you figure out which method you’re going to use, you have other options to help guide your SharePoint 2007 farm easily toward SharePoint 2010 without upsetting your users too much. Upgrading to SharePoint 2010 will be an adventure, for sure, but it will be a good one, and well worth it.