Installing SharePoint Server 2010

 

Installing SharePoint Server 2010 from scratch via the interactive GUI took me a little more than an hour. Half of that time involved prep work to an existing Windows Server 2008 R2 machine, including setting up the Web server and database, and the remainder to the actual installation and setup of SharePoint. Both the preinstall and the install processes collect needed information when they start up, and for the most part, can be run unattended.

For my purposes, the GUI install was sufficient, but anyone with more than a handful of machines will want to take some extra time to set up a scripted installation that runs through Windows PowerShell; this method offers two advantages. The first is that you're guaranteed that your SharePoint servers will adhere to a standard configuration; the second bonus is that having the scripts in hand makes building a new server a much quicker process than trying to manually replicate settings.

Upgrading an existing SharePoint installation is much easier than one might imagine, thanks to new tools for the preupgrade phase and a thoughtfully designed ability to stage upgrade phases.

For starters, the "preupgradecheck" operation is available to run against instances of SharePoint Services 3.0 and SharePoint Server 2007, to give the upgrade team information on the health and upgrade suitability of the SharePoint farm and individual servers. The tool can identify problems such as missing dependencies, data orphans and schema problems without changing the current environment.

Upgrades to SharePoint can be done in place on machines meeting the requirements for SharePoint 2010; if issues arise, the installation can be restarted as necessary. Larger installations, and upgrades that involve moving SharePoint to a new server, can use database attachment. This takes a backup of the existing SharePoint database and attaches it to a SharePoint 2010 Web application. Before the database is modified to run with the 2010 application, administrators can use the supplied Test-SPContentDatabase cmdlet to verify data health from the application perspective, and identify issues such as missing site definitions or assemblies. The test cmdlet, like preupgradecheck, is read-only and can be run as often as needed until you're satisfied that the upgrade can proceed.

We all know that upgrades can be hard for both IT and users, but SharePoint 2010 offers many ways to ease the stress. On the back end, server administrators can mark databases as read-only during the upgrade, allowing users access while locking the databases against changes until the upgrade is complete.

SharePoint farm and server administrators can also upgrade a number of databases in parallel through multiple PowerShell sessions; this is limited only by what your SQL Server installation can support. Finally, alternate-access mapping can be used to direct traffic between a SharePoint 2010 farm and an existing SharePoint farm, using an HTTP "302" redirect; this allows for a gradual upgrade, which may be necessary when dealing with a truly monstrous amount of content.

The first complaint of users who are presented with an upgraded application is "it doesn't look like what I'm used to." In SharePoint 2010, that problem is solved. Upgraded databases are presented with their visual elements from the older platform until the site administrator decides it's time to switch. Along with the "2010" and "prior" modes, sites can also exist in a preview mode that allows site administrators to kick the tires and train users before committing to the full-blown SharePoint 2010 experience.

SharePoint 2010 is a remarkably flexible and powerful tool that nevertheless can be easily deployed, whether you're upgrading an existing installation or just beginning to work with it. With this release, Microsoft may have finally gotten it right.