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.
Database Attach

129
The database attach method also means more work for the administrator and may require access to
the SQL Servers if the backups are being moved from one SQL Server to another. You may also need
to factor in time and network bandwidth if you have to shuffl e databases around.
Another benefi t of the database attach method is that it enables you to combine the content
databases from multiple farms and consolidate your environment. You may have had mul-
tiple SharePoint 2007 farms for a variety of reasons: scale, isolation, hardware, and so on.
SharePoint 2010 fi xes a lot of those issues, so it might make sense to combine those separate
SharePoint 2007 farms into one massive SharePoint 2010 farm. You can use the database attach
method to do this before you upgrade all of your SharePoint 2007 farms to SharePoint 2010. Create
the additional web applications on your SharePoint 2010 farm and attach the content databases to
the appropriate web application.
If you can live with those considerations, then maybe a database attach upgrade will work for your
environment. You can use either STSADM or Windows PowerShell to attach content databases to
SharePoint 2010. This chapter focuses on Windows PowerShell.
For plenty of information on Windows PowerShell, see Chapter 10.
The Windows PowerShell cmdlet you will use to attach to attach the database is Mount-
SPContentDatabase
. In your perusal of Windows PowerShell cmdlets, you may stumble across
the
Upgrade-SPContentDatabase cmdlet, but that cmdlet is not necessary when doing a database
attach unless part of the database attach upgrade fails. The
Upgrade-SPContentDatabase cmdlet
retries or resumes a failed upgrade. To prevent that, you should check your content database for
potential problems. There’s a Windows PowerShell cmdlet for that, too:
Test-SPContentDatabase.

While it’s not necessary to test a content database before you mount it, it is a good idea. When you
run
Test-SPContentDatabase you need to provide it with a database name and the URL of the
web application to which you want to attach it. You need to supply the web application because
solutions and features can be scoped at the web application level. A site collection in an attached
database may work fi ne with one web application but not work at all with another. Figure 5-13
shows running
Test-SPContentDatbase against a SharePoint 2007 database.
Note that you run
Test-SPContentDatabase against a database that is in SQL but has not yet
been attached to SharePoint. It’s easy to fall into the trap of assuming that SharePoint can only
deal with databases that it knows about. That’s not the case here. As shown in Figure 5-13,
Test-
SPContentDatabase
has found a couple of problems with the database. A couple of Web Parts that
it references do not exist in the
http://upgrade web application. Notice, though, that neither issue
is enough to block the upgrade, as the
UpgradeBlocking property for both errors is False. Both
of those errors are something that we can live with and fi x later if the need arises. We will use the
Mount-SPContentDatabase cmdlet to add it to our farm, which will upgrade it automatically if it
is from SharePoint 2007. Figure 5-14 shows the command to use to attach your SharePoint 2007
database to your SharePoint 2010 farm. Note the percentage, indicating the progress of the
upgrade process. You can also watch the upgrade progress in Central Administration. Click
130

CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010
Upgrade and Migration in the left navigation pane and check Upgrade Status in the Upgrade and
Migration page.
FIGURE 513

FIGURE 514
We mentioned earlier that this can also be done with STSADM. STSADM is old and kind of dusty, and
we don’t recommend using it; but if you lose a dare and need to attach a SharePoint 2007 database to
a SharePoint 2010 farm with STSADM, you can use the command
STSADM –o addcontentdb to do
it. If you wanted to use STSADM to replace the Windows PowerShell command in Figure 5-14, you
would use this:
Stsadm –o addcontentdb –url http://upgrade –databasename WSS_Content_OOTB_upgrade
Database Attach

131
Figure 5-15 shows the finished product. Even though Test-SPContentDatabase indicated that errors
would occur with the upgrade, SharePoint 2010 upgraded it anyway, enabling you to browse the site
collection in that content database.
FIGURE 515
You can use the Get-SPSite cmdlet, as shown in Figure 5-16, to see what site collections you have
just added to your farm with your upgraded database.
FIGURE 516
As mentioned before, one of the big benefits of the database attach method is that you can attach
multiple databases at one time. To do this, open multiple SharePoint Management Shell windows
and run the
Mount-SPContentDatabase command in them.
When you use
Mount-SPContentDatabase to upgrade databases, you will notice that the content
looks like it did in SharePoint 2007. This is by design. It demonstrates Visual Upgrade, functional-
ity that Microsoft created to ease the transition to SharePoint 2010. It is covered in more detail
later in this chapter. If you want your content rendered with the SharePoint 2010 interface, add the
-UpdateUserExperience parameter to your Mount-SPContentDatabase command.
This section has spent a lot of time covering attaching content databases because we think that is
what the majority of people will do, but content databases are not the only SharePoint 2007 data-

bases that can be attached to SharePoint 2010. Project Server 2007 databases can also be attached
to a SharePoint 2010 farm that is running Project Server 2010. Project Server 2007 did not support
customizations, so attaching those databases is pretty straightforward.
132

CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010
A SharePoint 2007 SSP can also be attached to a SharePoint 2010 farm. Not all of it can be
used by SharePoint 2010 because of the change in architecture, but SharePoint 2010 can take a
SharePoint 2007 SSP database and use it as a Profile Services database.
HYBRID UPGRADES
In this chapter we have covered the two official upgrade methods: in-place and database attach. Both
work well, but they each have some drawbacks that might be deal breakers in your environment. The
in-place upgrade maintains all of your customizations and configuration, but it doesn’t leverage your
hardware by doing multiple databases at a time, and your entire farm is unavailable during the dura-
tion of the upgrade. The database attach addresses those issues but requires you to redo all of your
customizations and settings, and will likely require extra hardware to get SharePoint 2010 up and
running on before you move your SharePoint 2007 databases over. It would seem that SharePoint
administrators just can’t win … .
What if we told you that you can have your cake and eat it too? Using a combination of the in-place
upgrade and the database attach, you can get the best of both worlds. To use the hybrid method,
simply detach all of the content web application content databases from your SharePoint 2007 farm.
Don’t get carried away and detach your central admin content database — leave that one attached.
Now you have a SharePoint 2007 farm with all the configuration and customizations, but none
of the big databases. The next step is to do an in-place upgrade of that SharePoint 2007 farm.
The in-place upgrade should go quickly, as there is very little to upgrade. The infrastructure will
be upgraded and Central Administration will be upgraded, but that’s it. After the in-place upgrade
has completed successfully, you finish it up by attaching your SharePoint 2007 content databases to
your new SharePoint 2010 farm. This is where you get to leverage the flexibility of the database attach
method. You can attach the databases in the order in which you want the content to come back online.
In addition, because the farm was upgraded in-place, it is accessible. As soon as the database is

attached and upgraded, the content can be browsed. If your hardware can support it, you also have
the option to attach multiple databases. In other words, the hybrid method has all the benefits of the
in-place upgrade with the flexibility of the database attach method. Looks like this book just paid
for itself.
As if that were not enough, the hybrid method offers yet another option. If you have another
SharePoint
2010 farm already standing, it could upgrade your SharePoint 2007 databases while the in-
place upgrade

is running. Content databases are portable, so while your production farm is doing the in-place
upgrade
, or even while it is attaching your content databases, you could have another SharePoint 2010
farm upgrading your databases in tandem. When they are upgraded in the test SharePoint 2010 farm, sim-
ply detach them and reattach them to your production farm. Because they have already been upgraded, the
hard work is finished and they will be online in a matter of seconds. The hybrid approach
has great poten-
tial; I think it’s going to go places.
Database Attach with AAM Redirect

133
DATABASE ATTACH WITH AAM REDIRECT
If your SharePoint 2007 farm has a lot of content and a lot of customizations, none of the options
talked about already may work for you. An in-place won’t work because it will take too long. A data-
base attach won’t work because it would be too much work and too costly to rebuild all of your
customizations and get extra hardware. Even the hybrid won’t work because of the amount of time
it will take to upgrade all of your databases. What’s a large SharePoint 2007 farm to do?
There is one final tool in the SharePoint 2010 upgrade toolbox, the database attach with Alternate
Access Mapping (AAM) redirect upgrade method. Like it sounds, this is basically the database
attach method, but with a twist. You start the same way, with a SharePoint 2010 installation in tandem
with your SharePoint 2007 farm. You end the same way, by detaching your SharePoint 2007 content

databases and attaching them to your SharePoint 2010 farm. There’s an extra step in the middle, though,
and that’s where all the magic occurs. For our example, our SharePoint 2007 farm has a web applica-
tion at
, where all of our content resides. We give that web application
a second AAM for
. When we create our SharePoint 2010 farm,
we also give it a web application at
. However, when we create that
web application, we don’t do it in Central Administration, we do it with STSADM and add an extra
parameter,
redirectionurl. It would look like this:
stsadm -o addzoneurl -url -zonemappedurl
-urlzone default -redirectionurl

That’s the magic. Now, when SharePoint 2010 gets a request for a page on a site collection that it can’t
find on the
web application, it sends the browser an HTTP 302
redirect to the same site collection but at
. This sends requests
to the SharePoint 2007 farm where the content exists. Then when you move a SharePoint 2007
content database to SharePoint 2010, SharePoint 2010 no longer redirects the site collections in
that content database to SharePoint 2007. This enables you to upgrade your SharePoint 2007 farm
over the course of days or weeks, as your content is always online in either SharePoint 2007 or
SharePoint 2010. Once all of your SharePoint 2007 content databases have been attached to your
shiny new SharePoint 2010 farm, you can retire your SharePoint 2007 farm.
The redirect works well for web browsers, as they understand HTTP 302 redirects. Office applica-
tions, however, aren’t quite so understanding. It’s unlikely that users will have shortcuts directly to
a document, but it is possible. Also keep in mind that this is scoped at the site collection level. When a
request comes in to a SharePoint 2010 web application with a redirection URL, SharePoint 2010 checks
its list of site collections for that web application to see if there is a match. If there is, SharePoint 2010

attempts to render the content. If not, SharePoint 2010 sends the browser the HTTP 302 redirect. If
SharePoint 2010 has the site collection but not the specific web or page in the request, the user will get
a much less friendly HTTP 404 error.
134

CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010
OTHER UPGRADE OPTIONS
So far, this chapter has covered how to get your SharePoint 2007 content into SharePoint 2010. 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 2010 to your users. We also cover some techniques you can use to mini-
mize the downtime your users experience while you are upgrading.
Visual Upgrade
To help ease the upgrade to SharePoint 2010, Microsoft added a new feature, Visual Upgrade. Visual
Upgrade enables the rendering of content using the SharePoint 2007 master pages and CSS files
in SharePoint 2010. This enables you to separate the binary upgrade to SharePoint 2010 from
the interface. You can upgrade your back end to SharePoint 2010 without having all of your
SharePoint 2007 customizations ready for SharePoint 2010. While your content is in SharePoint 2010
it will look like SharePoint 2007 and it will be able to take advantage of your SharePoint 2007 master
pages and CSS. This is important, as SharePoint 2007 master pages and CSS files will not upgrade
to SharePoint 2010. 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 different enough
that the elements of the master pages and CSS don’t map easily. Instead of doing the upgrade poorly,
SharePoint doesn’t do it at all.
When doing any of the upgrade methods described earlier, the default is always to render the content
in the SharePoint 2007 style. This demonstrates one of the philosophies Microsoft followed when
designing the upgrade experience, “Do no harm.” If you don’t understand what Visual Upgrade is
and you choose the default options, your content will upgrade and render the way that it always has.
No harm has been done. After the upgrade is finished, you can choose the SharePoint 2010 interface
when you’re ready for it. Earlier, in the discussion of in-place upgrades, you saw in Figure 5-7 where

you are offered the choice. The default value is to preserve the look and feel of SharePoint 2007. When
upgrading with a database attach, the site collections will maintain the SharePoint 2007 interface
unless you specify an interface upgrade with the
-UpdateUserExperience parameter. No matter how
you get content into SharePoint 2010, you need to deliberately choose the new interface.
Since SharePoint has done everything in its power to keep you from having the SharePoint 2010
interface, how do you get it? You have a few choices. The easiest way is with your browser, in the
site itself. Figure 5-17 shows a portal site that was upgraded. It has the SharePoint 2007 interface. In
the Site Actions drop-down menu is a new entry, Visual Upgrade. This will be available to site col-
lection administrators.
If you click this option, you’ll be taken to the Title, Description and Icon page in Site Settings. At
the bottom of the page are the Visual Upgrade settings, as shown in Figure 5-18.
There are three options. The first, Use the previous user interface, is the SharePoint 2007 UI. The sec-
ond option, Preview the updated user interface, uses the SharePoint 2010 interface, but it leaves the
Visual Upgrade option in Site Actions in case you want to switch back. It’s for site collection adminis-
trators with commitment issues. The final option, Update the user interface, uses the SharePoint 2010
interface and removes the Visual Upgrade setting from Site Actions. This is the option to use if you
Other Upgrade Options

135
are sure you will no longer need the SharePoint 2007 interface. You can switch back afterward using
Windows PowerShell if necessary.
Figure 5-19 shows the same site in SharePoint 2010 Preview mode. The Visual Upgrade option is
still present in the Site Actions menu so you can switch back to SharePoint 2007 UI, or commit to
the SharePoint 2010 UI.
FIGURE 517
FIGURE 518
136

CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010

FIGURE 519
Once you choose Update the user interface from the Visual Upgrade page, that option is removed from
Site Actions. Again, this is scoped at the web level, so that setting must be changed for each web that
is upgraded.
Changing the Visual Upgrade setting for all the webs could be cumbersome if there are a lot of them.
Fortunately, you can use Windows PowerShell to do this more efficiently. Each web has two settings
that need to be changed: which version of the UI to use, and whether the Visual Upgrade setting is
enabled in the UI. The following code updates the web from Figure 5-17 to the SharePoint 2010
interface and removes the configuration option:
$site = Get-SPSite http://spdemo/sites/portal
$web = $site.RootWeb
$web.UIVersion = 4
$web.UIVersionConfigurationEnabled = $false
$web.Update()
Code file Chapter05_code.txt
Other Upgrade Options

137
That works well for one or two webs, but it could be slow going for a few hundred webs. One of the
benefits of Windows PowerShell is its ability to loop through objects. The following code will loop
through all of the site collections in a content database, then loop through all of the webs in those site
collections, and set them all to the SharePoint 2010 interface and turn off the Visual Upgrade setting:
$db = Get-SPContentDatabase WSS_Content_OOTB_upgrade
$db.Sites | Get-SPWeb -limit all | ForEach-Object {$_.UIversion = 4;
$_.UIVersionConfigurationEnabled = $false; $_.update()}
If you want a quick report showing which interface each web in a site collection is using, you can
use the following code:
$site = Get-SPSite http://spdemo/sites/portal
$site | Get-SPWeb -limit all | sort-object uiversion -desc | select url, uiversion
The output should look something like Figure 5-20.

FIGURE 520
This makes it easy to discover which webs need to be upgraded. It could be expanded to run across
the entire farm if a larger report were needed. Be sure to test out Visual Upgrade when planning
your farm upgrade; it provides tremendous flexibility and eases the upgrade for the end users.
Mitigating Downtime with Read-Only Databases
No one likes downtime, and SharePoint users are no different. Sadly, there is no such thing as a “no
downtime upgrade.” However, using some of the techniques in this chapter, you can control and
minimize the downtime you have to experience.
Earlier in this chapter we covered the database attach with AAM redirect upgrade option. This is
a great way to control downtime, as you have both farms (SharePoint 2007 and SharePoint 2010)
online at the same time. When we discussed the hybrid method, we mentioned another downtime
138

CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010
mitigation technique: upgrading your databases on multiple farms at the same time, and then
attaching them quickly to your production SharePoint 2010 farm. These both work well, but your
SharePoint 2007 content has to be offline during the duration of the upgrade. You don’t want users
changing content in SharePoint 2007 while you’re upgrading the database.
We have one more trick up our sleeves to help minimize downtime. Behold, the read-only database!
Beginning with service pack 2 for SharePoint 2007, SharePoint can now gracefully handle a content
database being set to read-only in SQL Server. If the database is read-only, SharePoint will render
its content, but not allow any changes. If you couple that with the other techniques, you shorten the
amount of time SharePoint 2007 content is unavailable while upgrades are happening. In the data-
base attach with AAM redirect method, you would set the content database to read-only and copy it
over to SharePoint 2010 to be upgraded. Once it’s upgraded in SharePoint 2010, simply detach it in
SharePoint 2007.
This technique could even be used with an in-place upgrade. In that case, you would need to stand
up a temporary SharePoint 2007 farm to host the read-only content while the production farm is
being upgraded. It’s a little extra work, but if your environment needs uptime it’s worth considering.
PATCHING SHAREPOINT 2010

It seems almost anticlimactic to cover patching after covering all the great improvements that have
been made to upgrade, but since we promised it in the Introduction it only seems fair to follow
through.
Patching SharePoint 2007 wasn’t a bad experience, as long as your farm was exactly one server and
didn’t have much content. As soon as you added that second machine, or started getting a few GBs
of content, things got scary in a hurry. Patching, at its most basic level is simply an in-place upgrade.
The upgrading that was covered earlier in the chapter is referred to as a version-to-version or a v2v
upgrade, since we are upgrading from the SharePoint 2007 version to the SharePoint 2010 version.
Patching is referred to as a build-to-build or b2b upgrade, as it is only upgrading to a newer build
of the same version. Under the covers though, they’re very similar. Not identical twins, but maybe
fraternal twins.
We’ve already covered the shortcomings of the 2007 in-place upgrade, and two of those were of
particular concern when patching. The patching process ran serially and could take a long time with
large content databases. There was no way around that. Second, if the patch failed there was no way
to resume. It was time to dust off those backup tapes and order some pizza. Both of those problems
and a whole lot more get addressed in the SharePoint 2010 patching story.
One of the most liberating improvements in patching with SharePoint 2010 is that the binaries on
your farm can be at a newer version than the databases those binaries are using, if both builds are
in the same compatibility range. The compatibility ranges should be between service packs, mean-
ing that any database that is SharePoint 2010 SP1 or higher should be able to be rendered by bina-
ries that are at the same build or later, but before SP2. This gives you the freedom to upgrade your
binaries without immediately upgrading your databases at the same time. Walking through all your
databases and upgrading them is the most time intensive part of patching, so being able to postpone
that is a huge advantage. You’ll be able patch the binaries running on your servers quickly and take
Patching SharePoint 2010

139
advantage of any fixes or security updates without having to incur the downtime penalty of upgrad-
ing your databases too. You can postpone the lengthy database upgrade part to a more convenient
time, like over the weekend. Also, since the binary upgrade isn’t coupled to the database upgrade,

you can do the database upgrades in waves instead of all at once. This is especially handy if you
have user bases in different time zones. While you shouldn’t plan on leaving your farm in this condi-
tion for weeks or months, you can safely do it for a few days.
If you do decide to upgrade your content databases, you can do it manually with Windows PowerShell
using the
Upgrade-SPContentDatabase cmdlet. Provide Upgrade-SPContentDatabase with the
name of the content database you want upgraded and it’s off. Like
Mount-SPContentDatabase, you
can run multiple copies of this at once to make the upgrades go more quickly if your hardware can
handle it. When you get around to finalizing your patch installation with the configuration wizard,
any content databases that are not already upgraded will get upgraded, along with any service appli-
cation databases that need to be upgraded.
Not only can your databases be out of sync with the binaries installed on your server, but the serv-
ers themselves can be at different build levels as well. This is truly an advanced move, however, and
should only be used when necessary by trained professionals. If you do choose to patch your servers
individually it’s recommended that you do tiers of them at a time. For example, if you have several
servers running the Search component, try to keep their patch level in sync. If you have multiple
web front ends (WFEs), keep them in sync. If you want to improve uptime by patching your WFEs in
waves, then make sure all the WFEs that are accepting end user traffic are at the same patch level. This
means you can’t stagger them in and out of your load balancer as you patch. For instance, if you
have four WFEs you can pull two of them out and patch them while two stay in. Before you add the
two patched WFEs back into rotation, pull out the two unpatched WFEs. That way all the WFEs
serving pages to end users are at the same patch level at all times. It won’t be the end of the world if
they’re mismatched, dogs and cats won’t be living together or anything, but it will likely result in an
inconsistent or confusing experience for the end users. That will mean angry phone calls to you, and
none of us wants that.
After all the servers in your farm have a patch installed, you need to run the configuration wiz-
ard on them all to finalize it. If you try to be sneaky and run the configuration wizard before
all of the servers in your farm are at the same patch level, you’ll get a very stern talking to from
it while it glowers at you over its glasses. It will tell you which servers are out of sync and wait

patiently for you to get your act together and install the patch on them before it proceeds. As with
SharePoint 2007, you do have to run the configuration wizard on each and every server in your
farm. Unlike SharePoint 2007, the steps are very fluid. It doesn’t matter in what order you run it
on the servers and there is no coordination needed. In SharePoint 2007, the configuration wizard
would stop at various stages while it was running, and advise you to go to other servers in your farm
and complete steps. In SharePoint 2010, the configuration wizard handles that all itself by writing
entries in the Config DB file as different machines complete different tasks. After the configuration
wizard is running on all of your servers, you can feel free to go out and have a nice dinner, followed
by a very fattening dessert. The configuration wizard will finish the farm upgrade all on its own
and start serving out pages without any human intervention. It will upgrade any content databases
you have not already upgraded with
Upgrade-SPContentDatabase and it will upgrade any other
databases that need to be upgraded. When you get back from dinner, click OK a couple of times and
your farm is officially patched.
140

CHAPTER 5 UPgradiNg from sharePoiNt 2007 to sharePoiNt 2010
SUMMARY
The road from SharePoint 2007 to SharePoint 2010 is not a complicated one. There are several paths
you can take, depending on what’s best for your environment. If you have customizations you want
to keep, you can do an in-place upgrade. If you want more control over your upgrade, the database
attach method might be appropriate for you. If you have complex needs, or the desire to flex your
SharePoint muscle, you can choose one of the advanced methods. Once you figure out which method
you’re going to use, you have other options to help guide your SharePoint 2007 farm easily toward
SharePoint 2010 without upsetting your users too much. Upgrading to SharePoint 2010 will be an
adventure, for sure, but it will be a good one, and well worth it.
Using the New Central
Administration
WHAT’S IN THIS CHAPTER?
Using the Farm Confi guration Wizard


Setting up Managed Accounts

Finding your way around the new and improved interface

Using the Ribbon in Central Administration

Backing up and restoring your site with Central Administration

Now that you’ve laid down the SharePoint bits and fi nished running through the SharePoint
Confi guration Wizard, you get your fi rst taste of using SharePoint 2010 when Central
Administration launches.
This chapter mainly serves as a general overview of Central Administration. Many topics require
more than just a few pages to adequately cover; in fact, some topics actually have entire chapters
dedicated to them. In this chapter we’ll hit the major highlights of Central Administration, and
point you to different areas in this book that cover certain topics in more detail.
A QUICK OVERVIEW OF THE NEW
CENTRAL ADMINISTRATION INTERFACE
If you could navigate Central Administration in SharePoint 2007 with your eyes closed, you
might be in for a bit of a shock when you fi rst look at Central Administration in SharePoint
2010. One of the fi rst things you will notice about the new Central Administration is that it
looks nothing like the Central Administration in SharePoint 2007 that we came to know and
6
142

CHAPTER 6 UsiNg the NeW ceNtral admiNistratioN
love. In SharePoint 2010, all tasks and links are divided into one of eight categories. You can see
these categories on the home page of Central Administration, both in the Quick Launch and in the
body, as shown in Figure 6-1. Underneath each category header are several links, which enable you to
access some of the more frequently used pages in each category, right from the home page. Clicking

the headings of each category will take you to that category’s page, which features additional subcat-
egories and links related to the category. Although this new layout is vastly different from SharePoint
2007’s Central Administration, it may also seem somewhat familiar to you: the new categorical
approach is visually and structurally similar to the look and feel of the Control Panel in Windows
Vista and Windows 7.
FIGURE 61
As you click through some of the links in the various pages, you will encounter several pages that
look nearly identical to their SharePoint 2007 counterparts. In many instances, how you confi gure
certain settings hasn’t changed a bit, only the way they are accessed.
Aside from the reorganized settings, Central Administration also makes use of another major change
to the SharePoint platform: the Ribbon. The Ribbon interface (also known as the Fluent UI) was intro-
duced with the Offi ce 2007 suite of clients. In the Offi ce clients, the Ribbon was used to make more
tasks available to the user at one time, while logically grouping them together. In SharePoint 2010, this
same idea is carried over. The Ribbon interface is designed to make accessing settings and performing
tasks easier for both administrators and users.
Using the Ribbon interface from a user perspective is covered in Chapter 2.
First Things First

143
The Ribbon isn’t used in Central Administration as extensively as it is in the normal user interface,
but understanding how it works will make your life easier. This chapter covers some of the basics of
the Ribbon as it pertains to Central Administration.
As you start using Central Administration, you’ll notice that its structure is much “flatter”
than SharePoint 2007. By using the categorical approach to organizing the content in Central
Administration, tasks and settings can usually be accessed in fewer clicks than it used to take in
SharePoint 2007. Because the links are divided among eight categories, many administrators will
likely discover that finding links is much quicker, as there is less guesswork as to where a link would
logically be located.
FIRST THINGS FIRST
You just finished up the install and are greeted by Central Administration. This section gives you

an overview of the steps taken the first time you access Central Administration post install. (If the
install has already been done and you are just accessing the server for the first time you can skip this
section and jump forward a page or two to the “Managed Accounts” section.)
Central Administration fires up for the first time immediately after the SharePoint Configuration
Wizard finishes its tasks. A pop-up window opens first, and you’ll be asked if you’d like to participate
in the Customer Experience Improvement Program (CEIP) to make SharePoint better. Make your
selection and click OK to close the pop-up. Central Administration offers to help you through the
initial setup process right off the bat by asking if you’d like to run through the Farm Configuration
Wizard (see Figure 6-2). You can choose to run through the wizard now or run it later if you wish.
Generally, you’ll probably want to run through the wizard, as it enables you to provision a default
set of service applications and create a web application to start exploring SharePoint 2010. It’s pretty
short — only a couple of options and questions and you’ll be ready to go. Of course, you can also
configure the farm manually and skip the wizard altogether if you wish. The wizard simply provides
a one-stop-shop for getting up and running with SharePoint 2010. Chapter 7 covers the manual pro-
cess for provisioning service applications.
FIGURE 62