Microsoft SharePoint 2010 Administration Cookbook: Over 90 simple but incredibly effective recipes to administer your SharePoint applications

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 stsadm command.

You must be a member of the Farm Administrators SharePoint Group, with administrator permissions on the server.

The pre-upgrade application leverages rules that can be found in the following two files: OssPreUpgradeCheck.xml and WssPreUpgradeCheck.xml.

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.

The preupgradecheck should already have been run on your current installation and any issues should have been resolved. Be sure to identify the content database that is being upgraded.

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.

Navigate to the new site.

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

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 Mount-SPContentDatabase command.

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.

More info—errors when upgrading

There are times when the upgrade fails. If that occurs, you may see a screen similar to the following:

When this occurs, you are directed to the log file in order to determine what the issue is and how to go about resolving it.

WSS 3.0/MOSS 2007 installation must have the Office 2007 Service Pack 2 installed.

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.

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.

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:

$web = Get-SPWeb http://server/site
$web.UIVersion = 3
$web.UIVersionConfigurationEnabled = $true
$web.Update()

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

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.

Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.

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.

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: http://spmysite:2222.

This URL cannot be redirected to a URL such as http://mysite.

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.

Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.

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:

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: