SharePoint 2010 Upgrade Planning

Editor's Notes

• #5: Unfortunately there is often a lack of understanding in how to upgrade the platform to maximize business value whilst ensuring a smooth transition for users and administrators. Upgrading such a critical piece of software such as SharePoint requires much more than simply thinking about the technical issues.In fact Microsoft has done a great job improving the upgrade path from 2007 to 2010.
• #7: Take advantage of new features of SharePoint 2010Managed metadataOnline office applicationsNew look & feelOpportunity to revisit system architectureUpgrade existing infrastructureBuild a stage environmentStay on SharePoint release scheduleGet cumulative updates and hotfixes
• #9: Update existing servers to Service Pack 2 (SP2) of Microsoft Office SharePoint Server 2007 or late. Recommend installing October 2009 Cumulative Update because it includes improvements to the pre-upgrade checker tool.Ensure that the environment is fully functioning before you perform an upgrade. Upgrade will not fix existing issues.Migrate to 64-bit serversAllocate resources to plan for migration and to perform migrationPossible opportunity to add stage environment to test upgrade
• #13: Crawl Server in SP 2010 contains one or more crawl components that can crawl content independently of one anotherIn SharePoint Server 2010, the Search service uses three databases: Search administration database (new): contains Search administration settings that were stored in the SSP database in Office SharePoint Server 2007.Search Service Crawl database (new): contains crawl history information that was stored in the SSP database in SharePoint Server 2007. Search metadata database (reused Search database): contains the metadata for search. You cannot upgrade Search data by using the database attach approach for upgrading. If you are using database attach upgrade, you must configure Search in your new farm separately from (that is, either before or after) upgrading your other content.Needs full crawl after the upgrade to create an index after database-attach upgradeIf you are using the in-place upgrade approach, you should review and adjust your Search topology after upgrade to suit the new recommendations and requirements. For more information, see the Search models.The Search Service Application is one of the more complicated and time-consuming aspects of an upgrade.  An in-place upgrade means that search will be upgraded automatically with little configuration necessary, but a DB Attach upgrade will require search to be re-configured, as no search settings are imported from the SharePoint 2007 farm.  On the upside, however, having to set up search again will allow for existing search settings to be carefully examined to determine if they are still necessary (crawl rules, for example).  In many cases, this may provide a good opportunity to do some Search “house-cleaning.” Some of the steps that will be necessary for configuring the Search Service Application:·         Configuring farm-wide search dashboard and settings, such as search timeout and ignoring SSL warnings·         Defining the default access account·         Specifying the email contact address·         Defining a proxy server (if necessary)·         Adding crawl rules·         Installing necessary IFilters and adding necessary file types·         Adding additional content sources, creating crawl schedules, defining priority, and adding crawl rules for these sources·         Promoting crawled properties to managed properties·         Creating scopes·         Building a Search Center (and defining proper user permission)·         Setting up search federation, server name mappings, result removal·         Enabling search reporting·         Enabling People Search·         Adding user profiles to the People service application (which includes configuring My Sites and crawling the profile store to enable people search)
• #14: In-Place Upgrade:Most of the services will work after the upgrade automaticallyWith an in-place upgrade, all of the services infrastructure and the settings for the services themselves are upgraded as part of the process.Database attach upgrade with servicesMost services settings will need to be reconfigured when you upgrade via database attach. When you move your databases to a new farm and upgrade the content, you must create your services infrastracture in the new farm, and configure the services appropriately for your new farm and new version. You can attach the SSP databases from your old farm, but only the profile information in that database will be upgraded — any search information or other services settings will not be upgraded. You cannot upgrade Search databases by using the database attach upgrade approachBefore database attach upgradeWhen you configure the new farm, you must also configure the new service applications and service application proxies for the farm, and configure the settings for all services that you want to use.If you are using Profile Services, and you have taxonomy data in your database, configure the Managed Metadata service before you upgrade. That way, you can upgrade any taxonomy data from the shared services database when you attach that database.For InfoPath Forms Services, export any administrator-deployed form templates (.xsn files) and data connection files (.udcx files) from your Office SharePoint Server 2007 farm by using the following command: Stsadm.exe -o exportipfsadminobjects -filename<path to export CAB>For InfoPath Forms Services, import any administrator-deployed form templates and data connection files to your new farm before you attach the content databases. Use the Import-SPIPAdministrationFilesWindowsPowerShellcmdlet to import the forms.For more information about how to configure your new environment before you perform a database attach upgrade, see Prepare the new SharePoint Server 2010 environment for a database attach upgrade.During database attach upgradeWhen you attach and upgrade the content databases, you also attach and upgrade the SSP database, which upgrades the profile information in the database.User Profiles – DB Attach Upgrade:Only the profile information in that database will be upgradedUser Profiles – Run PowerShellCmdlet to reconfigure user profilesMy Site Web sitesUpgrade the My Site host at the same time that you upgrade the profile services. You do not need to upgrade the My Site Web sites themselves at the same time. For best results, upgrade My Site Web sites (or at least the My Site host) at the same time as your main intranet site.InfoPath Forms ServicesWhen you upgrade by using the database attach upgrade approach, you must export any administrator-deployed form templates (.xsn files) and data connection files (.udcx files) before you perform the database attach, and then import them to the new farm by using the Export-SPInfoPathAdministrationFilesWindowsPowerShellcmdlet. If the URL of the new server differs from the URL of the previous server, you can run the Update-SPInfoPathAdminFileUrlWindowsPowerShellcmdlet to update links that are used in the upgraded form templates.For more information about how to upgrade forms and form templates, see Plan to upgrade form templates during an upgrade to SharePoint Server 2010.Excel ServicesExcel Services remains a local service for SharePoint Server 2010 — this means that you need to run the service in the same farm that consumes it.For in-place upgrade, any configuration information stored in the SSP database for Excel Services is upgraded and moved into the configuration database. For the database attach upgrade approach, you must reconfigure Excel Services in your new farm.After upgrade (either in-place or database attach), you must provision a new unattended service account that uses the Secure Store Service to interact with Excel Services. Business Data CatalogDuring an in-place upgrade, data that was stored in the SSP database is moved and upgraded to a separate database. New service applications are created for the SharePoint Server 2010 service. A new service, the Application Registry Backwards-compatible service, is used to manage the old Business Data Catalog connections.The Business Data Catalog is not upgraded when you use the database attach upgrade method.Upgrading solutions that depend on the Business Data CatalogIf you used the database attach method to upgrade and you want to continue to use the external data that is accessed through one or more application definitions, you must complete the following tasks:In your previous environment, export the application definitions (models) that are required by your solution from the Office SharePoint Server 2007 Business Data Catalog.Update the solution to use the object model and features of the Microsoft Business Connectivity Services. This includes updating the application definition file to be compatible with Microsoft BCS. In your new environment, after upgrade, import the updated model into the Business Data Connectivity service. For more information, see Manage BDC models (SharePoint Server 2010).For more information, see Plan to upgrade to Business Connectivity Services (SharePoint Server 2010).Single sign-onThe Single Sign-On (SSO) service is being replaced with the Secure Store Service in SharePoint Server 2010. You can use Windows PowerShellcmdlets to upgrade application definitions from SSO to the Secure Store Service. Note that passwords are not upgraded. After you upgrade the application definitions, you can make the Secure Store Service the default SSO provider.New databases are created for each service:BDCTaxonomyProfileApplication RegistrySearch ServicesSession State ServiceMany services that stored data in the SSP database have their own databases — in some cases, several databases. For each new service, new database is created to store the data for that service. (Ex: BDC, Taxanomy, User Profile, Application Registry, Search Services, Session State ServiceWith an in-place upgrade, all of the services infrastructure and the settings for the services themselves are upgraded as part of the process.When you move your databases to a new farm and upgrade the content, you must create your services infrastructure in the new farm, and configure the services appropriately for your new farm and new version.
• #15: APTA made changes to MOSS 2007 schema and therefore PreUpgradeCheck failed. We found out about it when we examined the logs. After removing the tables & stored procs they added to the DB, the PreUpgradeCheck has succeeded.PreUpgradeCheck:Makes no changes to environment or dataRules Files (Partial List)InformationalFarm Servers, DatabasesAAM ConfigurationLists Site Definitions, Features, Web Parts, Event ReceiversInstalled Language packsCAML views/CAML content typesIssuesMissing Site Definitions, Features, AssembliesData orphansModified content databasesTest-SPContentDatabase:Verify all customizations referenced within the content database are also installed in the web application. This cmdlet can be issued against a content database currently attached to the farm, or a content database that is not connected to the farm. It can be used to test content databases from SharePoint 2010 Products and from SharePoint Products and Technologies. This cmdlet can also be used to verify that all the server-side customizations that are needed for that content database are present in the new environmentNote: The Test-SPContentDatabasecmdlet does not change any of the data or structure of the content database, but can cause load on the database while the checks are in progress, which could temporarily block use of the content database. This cmdlet should only be used against a content database that is currently under low or no usage.
• #17: After the server administrator performs all pre-upgrade steps, the administrator runs Setup for SharePoint Server 2010 on the server that runs the SharePoint Central Administration Web site. Because the previous version was installed, an in-place upgrade is automatically selected.1) After Setup runs on the server that hosts the Central Administration Web site, the server administrator runs Setup on the remaining front-end Web servers and application servers in the farm.2) The server administrator runs the SharePoint Products Configuration Wizard on the server that hosts the Central Administration Web site. This server, the configuration database, the services, and the content databases are upgraded sequentially.3) When the configuration wizard finishes, the Central Administration Web site opens. A timer job schedules the upgrade process to run for each site collection. The upgrade process timer job upgrades each site collection. After all sites are upgraded, the upgrade process ends.4) The server administrator runs the SharePoint Products Configuration Wizard on all the other servers in the farm. ------------------------------Before you begin, you should stop the World Wide Web Publishing service on each web frontend to prevent any HTTP requests. Then, perform a full farm backup. This is just a precautionary step in case the upgrade should fail and you need to return to your previous version.You start the upgrade by first installing SharePoint 2010 on each of the SharePoint servers. The install is similar to the previous version, although a useful new option can automatically install all software prerequisites. The installer will detect a previous version and will tell you that you’re about to do an in-place upgrade.Once the install part is done, you need to run the SharePoint Products and Technologies Configuration Wizard on the server that is hosting the Central Administration website. This is where the upgrade actually begins. During the upgrade process, each content database will automatically be upgraded. If you’re running MOSS, each Shared Service Provider (SSP) and its settings will be upgraded and converted into new service applications.
• #18: The server administrator sets up and configures a new SharePoint Server 2010 farm. The administrator transfers all customizations to the new farm and tests the environment.The server administrator detaches the content databases from the old Office SharePoint Server 2007 farm and takes the old farm offline (for example, by changing the load balancer or IIS Web applications to stop service requests, or by turning off all the components and services on each server computer in the farm).The server administrator attaches the content databases to the new farm and upgrades the content.-----------------------------------------------------------------------------------------------------------------------------------------Attach them using PowerShell command Mount-SPContentDatabase / STSADM AddContentDBBy default, this upgrade results in pages that have MOSS 2007 look and feel but can be upgraded to SP 2010 (A flag needs to be set to force the SP 2010 look and feel)The Complete Process:A database-attach upgrade is done on a brand new farm on new servers. Compared to an in-place upgrade, it is safer since you don't disturb your current environment. Keep in mind that this will take more time as you need to manually reapply farm settings and customizations, and upgrade each content database one by one. Despite the extra work, database-attach upgrades are also a great way to test SharePoint 2010 without having to do an in-place upgrade. If you don't meet the system requirements such as Server 2008 or 64-bit, this type of upgrade is your only option.After performing the installation and creating a new SharePoint 2010 farm, you manually create your web applications. I recommend using the same settings as your current farm, including the URLs such as portal.company.com. You might want to add temporary entries into your hosts file (C:\\windows\\system\\drivers\\etc) to bypass DNS name resolution. After creating each web application, you can delete the default content database that is created.At this time, you should apply all the file-system customizations that you had documented, keeping in mind that the SharePoint root now points to the 14 folder (C:\\Program Files\\Common Files\\Microsoft Shared\\web server extensions\\14). This is why it's important to capture all the file-system customizations that have been made. You might be curious what would happen if you miss a few settings? Well, it depends on the kind of setting. If it’s something fundamental, such as a site definition, none of the web sites based on that definition will work. If it’s a web part feature, most likely just that web part won't display. The best way to know is to try it out and see what happens.When you're ready, you attach your old content databases to the new farm. You start by restoring the most recent content database backups from your current farm to your new farm. To attach to SharePoint, you should use the addcontentdb operation from Stsadm. Here is the syntax for a single content database:stsadm –o addcontentdb –url <url> -databasename <dbname> -databaseserver <sqlserver>When running the operation, SharePoint will look at the version of the database, and if it detects an old version, it will start the upgrade on it. An upgrade progress indicator displays to the console, and depending on the size, it could take minutes or hours to upgrade. Depending on your SQL server hardware, you may be able to run several upgrades simultaneously. This is called a parallel database upgrade; you just open another command prompt and run Stsadm again. You can also follow the database upgrade process from Central Administration. Just click the Check upgrade status link from the main page.For each database you upgrade, two log files will be created in your 14\\LOGS folder. One is a detailed log showing each step involved in the upgrade session. Another will show just the warnings and errors that were found in the upgrade. You should find this latter one easy to read, allowing you to focus only on possible problems.When reading the logs, you should know that just because an error occurred, it doesn’t mean the database didn’t upgrade. Similarly, not getting an error doesn’t mean that everything is fine. As with any upgrade, it is essential to test to make sure that existing capabilities still function correctly.For those running MOSS 2007, you should know that a database-attach upgrade won't fully upgrade your SSP into new service applications. When you attach an SSP database, only your user profile store is upgraded. Search settings, Excel Service settings, Business Data Catalog (BDC) application definitions, and other settings must be recreated from scratch.
• #19: 1) The server administrator takes the original farm offline (for example, by changing the load balancer or IIS Web applications to stop service requests, or by turning off all of the components and services on each server computer in the farm).2) The server administrator detaches the content databases from the original farm.3) The server administrator runs an in-place upgrade on the original farm servers, services, and configuration database.4) The server administrator attaches the content databases to the original farm and upgrades the content.--------------------------------------------------------Combination of In-Place and DatabaseRun Inplace upgrade to upgrade the server and infrastructure in place (config databases, services and restore settings in CA)Then run Database upgrade on the content databases, SSO and Search databases
• #24: Ensure that the new ContentPlaceHolder controls exist in order to update your master page to be compatible with SharePoint 2010.Many controls that were previously included with the default master page that have been moved into the new Server ribbon UI. Remove the following controls from your existing master page. These controls will be added when the Server ribbon is incorporated into master page.Publishing Console - <PublishingConsole:Console>Site Actions Menu - <PublishingSiteAction:SiteActionMenu>Sign-in and Log-in ControlNewly added Server ribbon in SharePoint 2010. The SPRibbonPeripheralContent control contains content that renders inside the Server ribbon area. There are a set of controls that are required for SharePoint Foundation to function. These are the SPPageManager, ScriptManager, and ScriptLink controls.Make sure that the server ribbon is positioned appropriately from scrolling with the pagePage layouts need to be upgraded with the new “UIVersion=4” attributes (as they appear in v4.master)All custom master pages need to be upgraded as well
• #25: Classic Mode Authentication: It refers to the integrated windows authentication. You cannot configure the Forms based authentication if your web application is using Classic Mode Authentication. You can convert a web application from Classic Mode Authentication to Claims Based Authentication. However, that can only be done using PowerShell commands and its an irreversible process.Claims Based Authentication: SharePoint 2010 is built on Windows Identity Foundation. It enables authentication from windows as well as non-windows based systems. This also provides the capability to have multiple authentication in a single URLWeb.config files need to be changed in 3 places:FBA web applicationCentral Administration web applicationSTS (Secure Token Service)
• #26: Custom CSS/Images/Branding – Copy over any custom CSS and images used in the SharePoint 2007 site to the new server so they can be referenced later.Web Parts/Solutions/Features/Web Services – Install any solution files, features, web parts, and web services.  If possible, moving any standalone Features into a Solution file will make the migration process smoother.  3rd party web parts and applications may prove problematic during the upgrade, depending on how they are written.  If any problems arise, check with any web part or application authors or vendors to see if they have plans to upgrade their code to be compatible with SharePoint 2010.12 Hive – In an in-place upgrade, a \\14 folder is created alongside the \\12 folder in the C:\\Program Files\\Common Files\\Microsoft Shared\\web server extensions\\ directory.  When using the DB Attach method on a fresh install of SharePoint 2010, no \\12 directory will exist.  If there is a possibility that files may need to be referenced from the \\12 directory, copy it over from the original farm into the \\web server extensions directory, alongside the \\14 directory.  SharePoint 2010 features a failback function in which the \\14 directory is checked first for a file, then the \\12 directory (if it exists) for any code that SharePoint is looking for.  In an in-place upgrade, SharePoint 2007 is not actually uninstalled from the server, but won’t be available after the upgrade.Web.config – the web.config file may need to be updated or changed to match new security requirements (for example, if using the claims-based authentication model offered in SharePoint 2010)Assemblies/References – Any custom code assemblies need to now be assembled in Visual Studio as x64 (64-bit) or “any”, not as x86 (32-bit).  There is no scenario in SharePoint 2010 that would warrant a 32-bit assembly, as SharePoint 2010 is 64-bit only. AssemblyBinding entries in the web.config file will use binding parameters in SharePoint 2010 to redirect references from the 12 hive to the 14 hive.  Small assemblies will act as the 12 binaries and perform redirects to the correct 14 assemblies.  This will use <bindingRedirectoldversion=”12.0.0.0” newversion=”14.0.0.0”> to redirect any assembly IDs from 12 to 14.Custom Site Definition:Custom site definitions will need to be upgraded using a Upgrade Definition File. Most custom site definitions from v3 should continue to work unmodified while in v3 UI mode of Visual Upgrade. However depending on what is in that site definition, a person may still want to do more featurization or other definition refactoring, which is where the upgrade definition file comes in handy.More info about upgrade def file can be found at http://msdn.microsoft.com/en-us/library/ms439232.aspxCustom Site Template:New sites can’t be created using MOSS 2007 site templates and after the upgrade. The site templates need to be created again.There are still Site Template in SharePoint 2010, but they're no longer .STP files.  Instead, they're packaged in .WSP files just like web parts and features. No longer is there a "Site Template Gallery", instead there is a "Solutions Gallery".List Definition:In Microsoft SharePoint Foundation 2010, you should not need to modify a custom list definition that is already a Feature, which is one of the safest customizations to upgrade. However, if a list definition involves, for example, a custom user interface (UI), custom views, or references to uncustomized files, then after upgrade you should verify page rendering in both the UI mode of the previous version, and the UI mode of the current version. You should verify pages whenever you revert pages or site definitions to their original uncustomized status.http://msdn.microsoft.com/en-us/library/aa543357.aspxCustom Field Types:A field type that uses custom Collaborative Application Markup Language (CAML) in its RenderPattern element will not be upgraded as an XSLT-based field type. Fields based on this custom field type will be rendered without any custom formatting in the next release of Windows A field type using custom Collaborative Application Markup Language (CAML) in its RenderPattern element will not be upgraded as an XSLT-based field type. Fields based on this custom field type will be rendered without any custom formatting in Windows SharePoint Services 4.0.” and “It is highly recommended that you manually upgrade all custom field types to the new XSLT-based field types in order to have full rendering and customization supportCustom List Views:The following will not be upgraded to the new XSLT-based list view: A list view that uses custom Collaborative Application Markup Language (CAML)A list view that is not associated with a featureA list view that is associated with a custom featureA list view that is not upgraded will still render properly in Windows SharePoint Services 4.0. However, it will not inherit any benefits of the new XSLT-based list view, such as SharePoint Designer customization support, conditional formatting, and improved developer experience with XSLT standard-based language support. We recommend that you manually upgrade all custom list views to the new XSLT-based list viewsA list view using custom Collaborative Application Markup Language (CAML), a list view not associated with a Feature, or a list view associated with a custom Feature, will not be upgraded to the new XSLT-based list view. A list view that is not upgraded will still render properly in Windows SharePoint Services 4.0, but it will not inherit any benefits of the new XSLT-based list view, such as SharePoint Designer customization support, conditional formatting and improved developer experience with XSLT standard-based language support.” and “It is highly recommended that you manually upgrade all custom list views to the new XSLT-based list views. The new XSLT-based list view is going to be the default view used in Windows SharePoint Services 4.0, replacing the existing list view in Windows SharePoint Services 3.0CustomWorkflowActionsFiles:Custom .ACTIONS files exist in the farm. These files have to be copied to the new front-end computers for Database Attach Upgrade and Gradual Upgrade in order to be visible to declarative workflow designers.ModifiedWorkflowActionsFile:The ModifiedWorkflowActionsFile rule in Pre-Upgrade Checker can warn that the default WSS.ACTIONS file was changed. This file will be upgraded with a new version during the upgrade, and all modifications will be lost. Declarative workflow designers that use this file will not see added actions.Additionally, deleted actions will not be hidden
• #28: 1) Prepare to upgrade Prepare your original farm by running the pre-upgrade scan tool and making an inventory of all of your customizations.Set up a small, temporary farm that is running Office SharePoint Server 2007.Set up your full SharePoint Server 2010 farm, and verify that it is configured and running correctly. 2) First upgrade: Upgrade the content to Office SharePoint Server 2007 Detach the content databases from the old farm, and then take that farm offline.Alternatively, you can leave the databases attached and make a copy of the databases if you want to ensure that your original farm can be restored to use quickly.Attach the content databases to the Office SharePoint Server 2007 farm and upgrade them.Verify that the content has been upgraded and that the Office SharePoint Server 2007 farm is working correctly. 3) Second upgrade: Upgrade the content to SharePoint Server 2010 Detach the content databases from the Office SharePoint Server 2007 farm.Attach the content databases to the SharePoint Server 2010 farm and upgrade them (optionally, you can upgrade them in parallel).Verify that the content has been upgraded and that the SharePoint Server 2010 farm is working correctly.4) Start serving requests on the SharePoint Server 2010 farm.You can use the trial version of Microsoft Office SharePoint Server 2007 in this temporary environment if you do not have a license agreement for the full product. The trial version can be used for 180 days. Download the trial version at one of the following links:x86 version: Download details: SharePoint Server 2007 Trial Version (http://go.microsoft.com/fwlink/?LinkID=120683)x64 version: Download details: SharePoint Server 2007 Trial Version (x64) (http://go.microsoft.com/fwlink/?LinkID=120684)