Attaching the Content Database
After you have tested your content
databases and fixed as many issues as you can, it’s time to attach the
database. Use the PowerShell cmdlet Mount-SPContentDatabase to mount the content database to the web application that will serve its content. The syntax for Mount-SPContentDatabase is similar to Test-SPContentDatabase,
and if you aren’t using any of the optional parameters when testing
your database, you can usually just press the up arrow in PowerShell,
replace “test” with “mount” and press Enter. Here is the command used to mount the database that you tested earlier against your upgrade web application:
Mount-SPContentDatabase -Name wss_content_tk_com -WebApplication
http://upgrade.contoso.com
Figure 5
shows the output returned from running that command. While it might be
tempting to run screaming out of the room when you see all that red
error text, it’s not so bad. You know from running Test-SPContentDatabase that there will be some issues.
To satisfy your curiosity about what happened
during the upgrade, SharePoint 2013 does a thorough job documenting the
process. Each time a database is upgraded it creates two log files. One
contains all the events associated with the upgrade, good and bad. The
other is a subset of the first, containing only error information. If
you just want to see what went wrong, skipping all the back-patting for
what went well, go right to the error log. Both logs are in the 15 Hive
(c:\program files\common files\microsoft shared\web server extensions\15)
in the Logs directory. The full log will have a name like
Upgrade-YYYYMMDD-HHMMSS-MMM.log, where YYYY is the four-digit year, MM
is the month, DD is the day, HH is the hour in 24-hour format, MM is
the minutes, SS is the seconds, and MMM is the milliseconds when the
upgrade was started. The errors-only log has the same name with
“-error” at the end. They’re both text files, so they can be read with
any text editor. They also have the same schema as the ULS logs, so you
can use the MSDN ULS Viewer to view them as well.
The Upgrade log contains a tremendous amount of
information, so if problems are reported during the upgrade it’s more
efficient to start your troubleshooting in the error log, then work
back into the full log if you need more information. The full Upgrade
log is a good way to determine how long it took to complete a
particular mount. All the lines are time stamped, or if you’re bad at
math you can search for “Elapsed time” at the end of the log to see how
long it took. Keeping track of these times in your test environments
will help you plan your production upgrades.
If you prefer to consume your error logs in a
civilized manner, you can also view them in Central Admin. On the
Upgrade and Migration page there is a link to “Check upgrade status.”
Clicking that will take you to the /_admin/UpgradeStatus.aspx
page where you will find all the tales of previous upgrades. Some
upgrade stories have happy endings, some don’t; they’re all available
on this page, shown in Figure 6.
You can click each upgrade’s status to load its details on the bottom.
If you want to read the full log, its location is listed as “Log File”
at the bottom.
After the database is attached you should verify
how things look. The following PowerShell cmdlet returns the site
collections in that database, so you know where to start looking:
(Get-SPContentDatabase wss_content_tk_com).sites
Figure 7
shows the command’s output, which contains a couple of notable things.
First, notice there’s an Office Viewing Cache site collection in there.Because of this, the Office Viewing Cache site collection
has no SharePoint 2013 equivalent and cannot be upgraded. You can
either delete them in SharePoint 2010 before you upgrade, or in
SharePoint 2013 afterward.
All the site collections in this content
database have the CombatibilityLevel 14, which is SharePoint 2010. By
design, it is not possible to have the site collections upgraded to the
SharePoint 2013 compatibility level when a SharePoint 2010 database is
attached. The team that owns the upgrade process planned the upgrade
around one guiding principle, “Do no harm.” Because some site
collections might not render after being upgraded, they decided that
none of the site collections can be upgraded without a deliberate
action on someone’s part. Because this database is attached but none of
the site collections have been upgraded, the following section walks
through upgrading the site collections.
