Thủ thuật Sharepoint 2010 part 20 pps

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 53 120  CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 Click Install Now to continue the upgrade process. 2. Next, if you’re upgrading MOSS to SharePoint Server, you’ll need to enter your license key. Your SharePoint 2010 license key must match your SharePoint 2007 key. For instance, if your SharePoint 2007 farm is running a trial key, you will need to enter a trial key for SharePoint 2010. If your licenses don’t match, you’ll get an error like the one in Figure 5-4. After you enter a license key that satisfies the installer, it starts installing the SharePoint 2010 bits. Figure 5-5 shows the installation progress bar. FIGURE 54 FIGURE 55 In-Place Upgrade  121 3. Just like a non-upgrade install, the first stage only lays down the SharePoint bits. After that part is finished, the SharePoint Products and Technologies Wizard, or PS Config for us lovers of brevity, will be started automatically to do the actual upgrade. Figure 5-6 shows the wel- come screen when PS Config starts after the install. FIGURE 56 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. 122  CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 FIGURE 57 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 In-Place Upgrade  123 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. FIGURE 58 124  CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 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 ser- vice application associations for a web application associated w ith SharedService1 in SharePoint 2007. FIGURE 59 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 infor- mation, 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 In-Place Upgrade  125 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 conve- nient. Figure 5-10 shows the databases for the Search service application that was created from SharedService1. FIGURE 510 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. 126  CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 FIGURE 511 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!”? In-Place Upgrade  127 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. FIGURE 512 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. 128  CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010 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 con- tent, 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. [...]... to a SharePoint 201 0 farm that is running Project Server 201 0 Project Server 200 7 did not support customizations, so attaching those databases is pretty straightforward 132  ❘  Chapter 5   Upgrading from SharePoint 200 7 to SharePoint 201 0 A SharePoint 200 7 SSP can also be attached to a SharePoint 201 0 farm Not all of it can be used by SharePoint 201 0 because of the change in architecture, but SharePoint 201 0. .. to SharePoint 201 0, Microsoft added a new feature, Visual Upgrade Visual Upgrade enables the rendering of content using the SharePoint 200 7 master pages and CSS files in SharePoint 201 0 This enables you to separate the binary upgrade to SharePoint 201 0 from the interface You can upgrade your back end to SharePoint 201 0 without having all of your SharePoint 200 7 customizations ready for SharePoint 201 0. .. collections in that content database to SharePoint 200 7 This enables you to upgrade your SharePoint 200 7 farm over the course of days or weeks, as your content is always online in either SharePoint 200 7 or SharePoint 201 0 Once all of your SharePoint 200 7 content databases have been attached to your shiny new SharePoint 201 0 farm, you can retire your SharePoint 200 7 farm The redirect works well for web... site collection level When a request comes in to a SharePoint 201 0 web application with a redirection URL, SharePoint 201 0 checks its list of site collections for that web application to see if there is a match If there is, SharePoint 201 0 attempts to render the content If not, SharePoint 201 0 sends the browser the HTTP 302 redirect If SharePoint 201 0 has the site collection but not the specific web... may have had multiple SharePoint 200 7 farms for a variety of reasons: scale, isolation, hardware, and so on SharePoint 201 0 fi xes a lot of those issues, so it might make sense to combine those separate SharePoint 200 7 farms into one massive SharePoint 201 0 farm You can use the database attach method to do this before you upgrade all of your SharePoint 200 7 farms to SharePoint 201 0 Create the additional... the SharePoint 200 7 interface You can switch back afterward using Windows PowerShell if necessary Figure 5-19 shows the same site in SharePoint 201 0 Preview mode The Visual Upgrade option is still present in the Site Actions menu so you can switch back to SharePoint 200 7 UI, or commit to the SharePoint 201 0 UI Figure 5-17 Figure 5-18 136  ❘  Chapter 5   Upgrading from SharePoint 200 7 to SharePoint 201 0. .. farms (SharePoint 200 7 and SharePoint 201 0) online at the same time When we discussed the hybrid method, we mentioned another downtime 138  ❘  Chapter 5   Upgrading from SharePoint 200 7 to SharePoint 201 0 mitigation technique: upgrading your databases on multiple farms at the same time, and then attaching them quickly to your production SharePoint 201 0 farm These both work well, but your SharePoint 200 7... content is in SharePoint 201 0 it will look like SharePoint 200 7 and it will be able to take advantage of your SharePoint 200 7 master pages and CSS This is important, as SharePoint 200 7 master pages and CSS files will not upgrade to SharePoint 201 0 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... Upgrading from SharePoint 200 7 to SharePoint 201 0 Other Upgrade Options So far, this chapter has covered how to get your SharePoint 200 7 content into SharePoint 201 0 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 201 0 to your... when SharePoint 201 0 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 200 7 farm where the content exists Then when you move a SharePoint 200 7 content database to SharePoint 201 0, SharePoint 201 0 . box with SharePoint 201 0 Test on sample server, plan to rewrite for SharePoint 201 0 If your SharePoint 200 7 servers meet muster, and if your SQL Servers are compliant with SharePoint 201 0, what. the only SharePoint 200 7 data- bases that can be attached to SharePoint 201 0. Project Server 200 7 databases can also be attached to a SharePoint 201 0 farm that is running Project Server 201 0. Project. also be attached to a SharePoint 201 0 farm. Not all of it can be used by SharePoint 201 0 because of the change in architecture, but SharePoint 201 0 can take a SharePoint 200 7 SSP database and