134 ❘ CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 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 mini- mize 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 col- lection 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 sec- ond 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 adminis- trators 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 Other Upgrade Options ❘ 135 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. FIGURE 517 FIGURE 518 136 ❘ CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 FIGURE 519 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: $site = Get-SPSite http://spdemo/sites/portal $web = $site.RootWeb $web.UIVersion = 4 $web.UIVersionConfigurationEnabled = $false $web.Update() Code file Chapter05_code.txt Other Upgrade Options ❘ 137 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: $db = Get-SPContentDatabase WSS_Content_OOTB_upgrade $db.Sites | Get-SPWeb -limit all | ForEach-Object {$_.UIversion = 4; $_.UIVersionConfigurationEnabled = $false; $_.update()} If you want a quick report showing which interface each web in a site collection is using, you can use the following code: $site = Get-SPSite http://spdemo/sites/portal $site | Get-SPWeb -limit all | sort-object uiversion -desc | select url, uiversion The output should look something like Figure 5-20. FIGURE 520 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 138 ❘ CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 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 data- base 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, mean- ing that any database that is SharePoint 2010 SP1 or higher should be able to be rendered by bina- ries 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 Patching SharePoint 2010 ❘ 139 advantage of any fixes or security updates without having to incur the downtime penalty of upgrad- ing 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 condi- tion 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 appli- cation databases that need to be upgraded. Not only can your databases be out of sync with the binaries installed on your server, but the serv- ers 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 wiz- ard 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. 140 ❘ CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 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. . 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. CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 OTHER UPGRADE OPTIONS So far, this chapter has covered how to get your SharePoint 2007 content into SharePoint 2010. There are a couple. officially patched. 140 ❘ CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 SUMMARY The road from SharePoint 2007 to SharePoint 2010 is not a complicated one. There are several paths