In this chapter, we will cover:
Checking current installation upgradeability
Upgrading MOSS 2007 to SharePoint 2010
Upgrading with minimal downtime
Creating and associating content databases to a specific web application and site collection
Configuring a content database
Creating an Alternate Access Mapping (AAM)
Patching (compatibility boundaries)
SharePoint 2010 requires 64-bit architecture on the servers, with a minimum of 8 gigabytes of RAM. The result of this requirement is that there will be installations upgrading their 32-bit architecture and then upgrading/migrating their sites.
Upgrading SharePoint 2010 is optimally a one time job. In reality, this is not always the case as there may be business reasons one web application is upgraded and another is left in MOSS 2007. This could be due to software integration with SharePoint, components that are not ready for SharePoint 2010, or a segment of users that need time before upgrading to SharePoint 2007.
SharePoint 2010 has been architected with the capability to migrate sites methodically. With this in mind, every recipe in this chapter approaches the upgrade from the viewpoint of iterative tasks after an upgrade. This means that a majority of the tasks can be performed several times against different web applications.
Every recipe here (except the first one) should be performed and understood by the administrator of the SharePoint 2010 farm. There are many new items in SharePoint 2010 that will become common tasks; some more than others depending on the size of your environment.
One of the best new tools that should be in your arsenal is PowerShell. The recipes in this section outline the commands you will need. However, after reviewing and trying these recipes, look at scripting your tasks with PowerShell. This will enable you to become a more effective and proactive IT Professional.
In order to upgrade to SharePoint 2010 from your current Windows SharePoint Services 3.0 (WSS) or Microsoft Office SharePoint Server 2007 (MOSS) implementation, you need to plan your new infrastructure carefully. When thinking about planning your new architecture, take into account the logical design and the physical design of the new SharePoint 2010 installation.
Issues need to be identified, resolved, and requirements need to be met. Issues can range from addressing 32-bit architecture to custom site definitions. These items need to be resolved before being able to update to SharePoint 2010.
Begin your planning by identifying and documenting your current infrastructure. Review the hardware, WSS/MOSS configurations, and potential customizations.
A typical farm installation will have multiple servers with diverse roles: web front ends, applications servers, database servers, among others. Extrapolating from there, an installation can have multiple content databases, web applications, site collections, Shared Service Providers, to name a few of the components.
In order to manage your infrastructure and plan for the SharePoint 2010 upgrade, Microsoft has provided organizations with a tool called preupgradecheck. This tool is shipped as part of MOSS Service Pack 2. As long as this service pack is applied, the tool is available.
In order to execute this tool, the WSS 3.0/MOSS 2007 installation must have the Office 2007 Service Pack 2 installed. This tool is native to the SharePoint installation and an extension of the
You must be a member of the Farm Administrators SharePoint Group, with administrator permissions on the server.
1. Click Start and Run... on the web front-end server.
2. Type in cmd and press Enter.
3. Navigate to
c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN. This can be achieved with the help of the
CD(Change Directory) command.
4. Type the following in the command prompt:
stsadm -o preupgradecheck
You should see a report that looks similar to the following screenshot:
These files were created in
12\CONFIG\PreUpgradeCheck when the Microsoft Office SharePoint 2007 Service Pack 2 was installed. Refer to the next screenshot:
In the command prompt window shown in step 4 of the previous section, a summary of the operations is shown. The objects marked with the colors yellow and red must be addressed. The farm will not get upgraded until objects in red color are addressed.
As you can see from the preceding screenshot, an HTML file is created in the
12\Logs folder, which contains the information the pre-upgrade application produced. The first part of the report produces important information as shown in the following screenshot:
Other information collected includes the SharePoint version, supported upgrade types, along with information on your servers, including roles, amount of data, number of web applications, site collections, and number of servers.
The rest of the HTML report lists the checks that were done and any issues that were found. If an issue is found, the report will include a description on fixing the issue or a link to a Microsoft Knowledge Base article that corresponds to the issue.
The pre-upgrade application performs read-only operations against the database. No changes are made to your SharePoint installation. This means you can run the application multiple times and there is no adverse effect on your SharePoint installation. As you resolve issues, it is advisable that you rerun the pre-upgrade application.
Database attach upgrade: To perform this type of upgrade, you must have a new SharePoint 2010 farm up and running. You will take the content databases from the MOSS 2007 farm, attach them to the new farm, and upgrade them.
The latter method of upgrading your MOSS 2007 farm is the preferred method and the one that this recipe outlines. It has many advantages over the in-place upgrade method. Some of these advantages are:
It leverages backup and restore through SQL Server Management Studio. SharePoint IT Administrators should already be familiar and comfortable using these tools.
addcontentdb stsadmcommand should already be familiar to many SharePoint Administrators. It creates a new content database or as in the case outlined in this recipe, adds a database that needs to be upgraded. Attaching a database reduces the downtime of your SharePoint installation. This reduces the pain your customers will feel and enhances the success and acceptance of your upgrade.
You can perform the upgrade in an iterative fashion, or even in parallel. The in-place upgrade is a one-way, don't-look-back upgrade.
You can have granular control over the steps of your upgrade. You control what gets upgraded, when, and how. This allows for flexibility, which is the key to a successful upgrade.
SharePoint 2010 has a completely different Services architecture as compared to MOSS 2007 Shared Services. This new architecture must be planned carefully and implemented according to the organization's needs. By doing a database attach, your farm will correctly consume the new architecture as architected.
A new SharePoint Server 2010 farm must be set up and configured using a web application.
You must have access to SQL Management Studio with the ability to create databases.
1. Log in to the WSS 3.0/MOSS 2007 database server.
2. Open Microsoft SQL Server Management Studio and connect to the database server hosting the SharePoint content database.
3. In the Object Explorer, click on the folder named
5. Right-click on the content database and select Tasks | Back Up. A screen similar to the following screenshot appears:
6. Ensure Backup type is set to Full. Also the Name and Destination field should be populated correctly.
7. Click OK. The file should be backed up successfully after a period of time.
8. Ensure the backup is accessible to the SharePoint 2010 database server. If the SQL Server is physically not on the same server as SharePoint, copy the backup to the destination server where it is accessible.
10. In the Object Explorer window, right-click Databases. Navigate and click on Restore Database. The following screenshot appears and must be filled with appropriate values:
Fill in the To Database textbox.
Choose the backup file in the From Device option. Check the Restore option under the Select the backup sets to restore option. Click OK.
12. Open a command window. Make sure to run it as administrator when you open it. If you right-click on the command prompt, there is an option provided to Run as Administrator.
13. Type in the following command:
stsadm -o addcontentdb -url <url> -databasename <database name>
Here is the screenshot I get when I run this command:
14. When the operation finishes successfully, navigate to the SharePoint 2010 Central Administration site.
15. Click the Application Management option. Under Site Collections, click the Change Site Collection Administrators option.
16. Ensure that there is a valid site collection administrator.
Steps 1 through 7 showed how to take a backup of the content database that was being upgraded. Step 8 is copying the physical file that is created from the backup to the new server. Using file storage and rights, the file may not have to be copied. The important part of this process is that the new SQL instance for SharePoint 2010 has access to this file.
Steps 9 through 11 performed a restore to put the backup file into the new SQL database instance.
Steps 12 through 14 ran the command that performs the physical upgrade of the file. An upgrade of the content database is nothing more than schema changes, table changes, and stored procedure changes. It also adds the content database to the specified web application.
In steps 15 and 16, we, as Farm Administrators, ensured that the Site Collection Administrator from MOSS 2007 is still a valid account in the now upgraded SharePoint 2010 farm.
The database attach method is the least intrusive upgrade when it comes to your SharePoint Farms. For SharePoint 2010, upgrading with
addcontentdb can be done only through the
stsadm command; its functionality is not found in the Central Administration User Interface.
Finally, there is a parameter called
preserveolduserexperience in the addcontentdb command. This is an optional parameter and set to
true by default. When the site is upgraded to SharePoint 2010, it will contain the same look as it did in MOSS 2007. If you want the site to use the new SharePoint 2010 look, then ensure that you use this parameter and set it to
Depending on the farm architecture, you may have more than one content database per web application. In a case such as this, it is more efficient to upgrade both simultaneously. This is accomplished by doing multiple attaches in parallel. Instead of using the
addcontentdb command, use PowerShell and the
Before adding the content database to the web application, there is an additional tool that has been added via SharePoint's PowerShell commands. This tool confirms that the new web application has all the necessary components to support the upgrade. It functions by comparing the database you are about to attach/upgrade against the web application you wish to attach.
The command is Test-SPContentDatabase.
1. Click Start | All Programs. Select Microsoft SharePoint 2010 Products and then SharePoint 2010 Management Shell. Refer to the following screenshot:
2. At the command prompt, type in the following command:
test-spcontentdatabase -name <database name> webapplication <url>
This command will produce a report in the window that can be piped to a file through PowerShell. The report will identify issues such as missing site definitions, features, or assemblies. The benefit of this command is that it works read-only against your web application so that it can be run iteratively. As you resolve issues, you can rerun the command.
Keep this command as part of the IT Professional toolkit. It is very useful to scan and identify issues against WSS 3.0/MOSS 2007 and SharePoint 2010 databases.
After the upgrade and migration is complete, you will see a successful or unsuccessful indicator in the command prompt. However, the best place to view the status of your upgrade is in Central Administration. This is especially true if there are parallel upgrades happening.
1. Open the SharePoint 2010 Central Administration site.
2. Click Upgrade and Migration.
3. Click Check Upgrade Status. There will be a screenshot similar to the following:
As can be seen in the preceding screenshot, there were two upgrades that took place. One failed and one succeeded. One of the items on the report is the location of the log file, which shows detailed information about the failures.
There is also a custom error log file created that is necessary to look at when there are errors in the upgrade.
Also, there is a category named Remedy. In here is located a hyperlink to a possible resolution for the issues found.
MOSS 2007 SP2 installed a new capability that allows an administrator to set the content database to read-only. The result of this is that users can only read from the database and cannot perform any write operation.
The advantage of this when doing an upgrade is that users can continue using the MOSS 2007 farm while the data is being upgraded on the SharePoint 2010 farm.
This recipe shows how to set a database as read-only.
1. Open Microsoft SQL Server Management Studio.
2. Log in to the WSS 3.0/MOSS 2007 database server.
3. In the Object Explorer, click the folder named
4. Find the correct content database. By default, this is called
5. Right-click on correct content database, and select Properties.
7. Change the Database Read-Only property to
Truefrom the existing value of
8. Click OK.
Once the content database is read-only, no changes can be saved to the database. The WSS 3.0/MOSS 2007 site is still available to query information to the entire user population. The database can now be backed up with confidence in the integrity of the data state.
The database can be copied to the new SharePoint 2010 SQL Server and upgraded as shown in the previous recipe. When the new environment is ready to go, perform an Alternate Access Mapping (AAM) redirect to route users to the new environment and detach the database in SharePoint 2007.
This is referred to in Microsoft Technet as a Hybrid upgrade.
When upgrading your site to SharePoint 2010 from MOSS 2007, there is a significant difference in the user interface (UI). SharePoint 2010 has a new master page that includes new and changed components that must be taken into account when designing the UI. They are:
Social features such as being able to tag
Disappearance of My Links
These factors may present a challenge when porting the site's look and feel to SharePoint 2010. The business may not have the time and bandwidth to accommodate the changes.
As seen in the upgrade from recipe 2, there is an option to preserve the MOSS 2007 UI in SharePoint 2010.
Then, as the organization is ready for the new look and feel, it can be applied at a site level or at a site collection level. This can be done as a preview and then rolled back. Or the SharePoint 2010 UI can be committed permanently to your site.
The person doing this must be a site collection administrator or site owner, and the upgrade must have been applied with the MOSS 2007 look preserved.
1. Navigate to the site where the SharePoint 2010 UI will be applied.
3. A screen is presented with three options:
Display the Previous SharePoint user interface
Preview the new SharePoint user interface (it can be rolled back if there is a problem)
Use the new SharePoint user interface (this is permanent)
Choose the Preview... option.
4. The site is now presented with the new SharePoint 2010 UI.
5. To roll the site back or commit the site to the new UI, click Site actions | Visual Upgrade. Choose either of the options: Display the Previous SharePoint user interface or Use the new SharePoint user interface.
SharePoint 2010 ships with the MOSS 2007 master pages, application pages, and CSS files. It provides the facility to convert those deprecated layouts to the new UI through the visual upgrade.
This makes sure organizations do not have to make the visual leap to SharePoint 2010 all at one time. It can be phased in and tested properly, ensuring all the UI assets and UI changes function correctly.
The visual upgrade can also be done at the site collection level through the administration page. This will allow the site collection administrator to apply the SharePoint 2010 UI to all sites under the Site Collection or hide the visual upgrade from the site owners.
The caveat to doing an upgrade to all sites is there is no preview. Any issues that result in the new UI must be dealt with immediately. There is no changing back to the MOSS 2007 pages.
The steps to achieve this are:
1. Click Site Actions, Site Settings.
2. Under the Site Collection Administration, there is an option for visual upgrade. The screenshot is the screen we get:
Choose either of the following options: Hide Visual Upgrade or Upgrade All Sites.
There are times when a visual upgrade must be rolled back after it has been committed. This may be due to issues with the ribbon or CSS styling. In any event, the upgrade has been made and now the company wants to roll it back.
Using PowerShell, it is possible to change the look back to MOSS 2007. Use the following snippet to change the look back for a single site:
A web application is not limited to using a single content database. SharePoint allows you to associate many content databases to a web application. One of the reasons to do this could be based on the size of the content database. If the content database is larger than 200 gigabytes, it makes more sense to distribute this content across two content databases.
A different consideration is factoring the type of data that is being housed in the content database. If there is a marketing site that contains media files such as photos and video, it may be desirable to create a content database just for this site collection data. Another example is housing all legal data into one content database/site collection for a litigation department.
Finally, a major benefit of doing this is disaster recovery. Knowing where your data is, and how it is structured, will allow you to implement a disaster recovery strategy that is efficient, effective, and flexible.
The data that is created is not the same, that is, we have various kinds of data. Data has different properties and may even have different backup and restore service level agreements. However, multiple content databases may be connected to one web application.
This recipe will show how to create multiple content databases to one web application and apply the appropriate site collection to the corresponding content database.
Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site. You must have the correct permissions to create a database (typically dbcreator and sysadmin).
1. Open the Central Administration screen. Under Application Management in the Databases section, click Manage Content Databases.
2. At the top of the resultant page is the Add a content database option. Click the option and the following screenshot will be displayed:
3. The database name is given a GUID suffix by default. Change the database name to be relevant but use a naming convention. In the case of the preceding screen, I will change database name to
WSS_Content_Marketing. Keep the rest of the defaults and click OK.
The content database will be created and listed under Manage Content Databases.
4. To ensure that the site collection gets added to the proper content database, ensure that you are still under Manage Content Databases.
5. Click on the content database(s) you don't want the site collection to get added to.
6. Under the Database Information settings, set the Database status to Offline. Click OK. Refer to the next screenshot:
7. Navigate to Application Management, then Site Collections. Under this section, click Create site collections.
8. Fill the information for Title, URL, select a template, and include a primary site collection administrator. Click OK.
9. The site collection should be created and added to the appropriate content database. To check this, navigate back to the Manage Content Databases screen. See the example shown in the following screenshot.
WSS_content_7777is Stopped (offline) and the new site has been added to
10. Reverse the action from step 6 and put the content database back in Ready state.
The first half of the procedure is self explanatory. We are creating a content database under the appropriate web application. The second half of the procedure takes the database offline. This action will ensure that the next site collection cannot be added to that database.
The action of assigning a site collection to a content database is very similar to network load balancing. The site collections are assigned quite evenly across the content databases while they are online.
When doing a SharePoint 2010 upgrade of multiple content databases, ensure that the first content database that you add contains the root site for the associated web application. The rest of the content databases for the web application can be added in any order afterwards.
There will be times when you do not want to add any more site collections to a content database. In order to accomplish this, perform the following steps:
1. In Central Administration, under the Databases section, click on the Manage Content Databases option.
2. Click on the database that you wish to no longer add site collections to.
3. Change the Maximum number of site collections settings (under Database Capacity Settings) to be equal to the current number of site collections.
4. Change the Number of sites before a warning event is generated setting to be one less that the current number of site collections.
You have seen how to do this recipe through the user interface. There is a way to do the same procedure through scripting. PowerShell is the new way of scripting, but the
stsadm command set is still available. Here are both methods:
stsadm -o createsiteinnewdb -url <url> -owneremail <email> -ownerlogin <domain/name> -sitetemplate <site template> -title <title> -databaserver <serverdb> -databasename <dbname>
Using PowerShell, we need to run the following two commands:
In SharePoint 2010, content databases are the heart of an organization's data. This is where all the site content information, such as documents, list data, and web part properties, is stored. By default, the content database is set up with parameters that may not be optimal to your organization.
Thankfully, these parameters can be changed and tweaked to fit your installation. It is important to note what can be changed and the ramifications of the change. In this recipe, you will be exposed to the parameters and the possible changes that can be made.
Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.
1. Open Central Administration. Under the Databases section, click Manage Content Databases. A listing of content databases will be shown in blue.
2. Click on the content database whose parameter you wish to change. The screen with the parameters to be changed will appear. The items that can be changed are:
Database Capacity Settings
Remove Content Database
Preferred Server for Timer Jobs
3. Make the appropriate changes and click OK.
Database Information: This section gives information on the status of the database. The drop-down list allows the administrator to change the database state. When a content database is taken offline, it is not available and sites cannot be created within it. Refer to the next screenshot:
Failover Server: This is a new option within SharePoint 2010. Entering a server name into this box will not set up the failover server. It tells SharePoint what failover database server to utilize in the event one is needed. Refer to the following screenshot:
Database Capacity Settings: This section controls the number of site collections that will be created within the content database. There is a warning level, which must be at least one less than the maximum number of sites that can be created. Refer to the following screenshot:
Remove Content Database: This section allows the administrator to disassociate the content database from the web application. It does not delete the content database from the SQL Server. The data is still available and untouched. Any content in the site collections, contained in the content database, will no longer be accessible. Refer to the next screenshot:
SharePoint's repository is the content database that resides in the SQL server. These databases house all the data for an organization. Organizations may require that users outside the company have access to a subset of this data. For example, vendors may wish to see if their invoices have been paid.
Another example at a large enterprise is hourly workers may see a different subset of data than salary workers. The data all resides in the same content database.
Appropriately architecting the taxonomy and authentication lead into providing two different URLs. The end user will put in the appropriate URL and be directed to the trimmed content associated with that URL.
Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.
There should also be an existing web application.
1. Open the Central Administration screen and click System Settings.
2. Under the Farm Management section, select the Configure alternate access mappings option.
3. A list of the current AAMs, associated with the web application, will be presented. This will be shown in the upper right-hand portion of the screen.
4. Click Add Internal URLs.
5. Fill in the data in the screen that appears. In the following screenshot, we have entered a URL as an example:
6. Click Save. The updated listing of AAMs will be visible.
7. Set up DNS to correctly reference the URL that was just entered.
When the URL is entered by a user, IIS takes the page request and passes it to SharePoint. It is SharePoint's job to fulfill this request. SharePoint checks the AAM to make a decision on which web application to map the request.
A point of confusion about AAMs is that they can be used for redirecting sites, with a completely new URL, to a custom port. For example, consider the following URL:
This URL cannot be redirected to a URL such as
If a SharePoint site is created on a port other than port 80(HTTP) or port 443(HTTPS), the port number must be supplied. AAMs deal only with the base URL for a web application.
SharePoint 2010 brings a new story when it comes to applying updates. Typically when applying a service patch, there are two components that get updated: the web front end (WFE) and the database(s). When applying patches with WSS 3.0/MOSS 2007, an administrator had to start the process on one WFE, get it to a certain point, then start the patching on another server, and when the process got to a certain point, finish the patching process.
With SharePoint 2010, there is a new concept known as Compatibility Boundaries as it applies to patching. This will allow your WFEs to be at a different patch level than your database(s). The administrator can upgrade multiple SharePoint servers at the same time. The configuration wizard (PSConfigUI) handles this process itself without any manual intervention.
If you have large content databases, it can take some time to apply patches. This new approach means you can now patch the files on your SharePoint servers, but delay the updates to the databases until a more appropriate time. This is useful to quickly protect your environment against any newly discovered security vulnerabilities or resolve any non-database bugs.
In addition, Central Administration has several components where your patching level can be monitored. This recipe shows you the components within Central Administration where you should be checking for database schema versions, patch levels, and general monitoring of the patching process.
Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.
1. Open the Central Administration screen and click Upgrade and Migration.
2. Click on Check product and patch installation status. A report is pulled up showing all the product components from the farm.
3. There is a drop-down list at the top that allows you to select whether to look at the whole farm or only the components on a particular server. A part of the report looks like the following screenshot:
4. Navigate back to Upgrade and Migration and select Review database status. A report is displayed, detailing all the databases for the Farm and their status.
5. Navigate to Application management | Databases | Manage Content Databases.
The recipe shows three components of the patching story. Together, these components provide a comprehensive view to the administrator of the SharePoint Farm. Utilizing this information, the administrator can make informed decisions as issues are brought up, and can decide if a new patch must be applied.
The three components are:
Database Status: This is a listing of all the databases in the farm including SQL instance. With SharePoint 2010, there are many databases and they can be run in a compatibility range. Under status, there will be a message letting the administrator know what is required or what is happening.
SharePoint 2010 monitors the health of your farm using a set of rules that are programmed against best practices. An administrator can review these rules and run them on demand or change their schedule. When a rule is broken, the issue is flagged and a red bar with a hyperlink to view the issues will appear on the Central Administration home page.
These are found under Central Administration, under a section called Monitoring. In that section is a Review rule definitions hyperlink. The rules for patch management can be found under the section Configuration. Refer to the following screenshot:
PowerShell is a powerful enabler for the SharePoint Administrator. There are three commands that are applicable to this process.
To produce a listing of all the patches on the server:
Return a listing of content databases and their GUIDs:
To upgrade the database:
Upgrade-spcontentdatabase -id <GUID>