Introduction
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.
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.
Checking current installation upgradeability
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.
This tool documents
the current installation, checks your MOSS/WSS installation against
SharePoint 2010 requirements, and applies best practice rules
identifying areas of concern.
Getting ready
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.
How to do it...
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:
How it works...
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.
There's more...
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.
More info
Using the preupgradecheck rule files parameter, you can create your own custom rules to identify items that are specific to your installation.
