Installing SharePoint Server 2010
SharePoint 2010 Offers More for Both IT and Users
They say that nothing's new under the sun, and ordinarily, I agree with that sentiment. But in this line of work, one is occasionally treated to a surprise, and Microsoft's SharePoint Server 2010 qualifies as one of the more pleasant surprises of this year.
The surprise isn't a matter of features or functionality,
although SharePoint Server offers many improvements on the previous
release. What grabbed my attention first is the way the platform has
evolved to match
the way people actually work, and second, how well Microsoft has
the needs of customers who want to upgrade existing installations.
I'll just point to the cream of SharePoint's new features, starting with the services model. This does away with the Shared Services Provider of the 2007 release, in favor of a more granular approach that lets SharePoint administrators decide whether services are run against a central farm or live on a local server. Farm administrators can delegate administrators for specific applications and define permissions at an application feature level.
Then there's the updated data connectivity service that allow users to create, rename, update and delete data on external sources such as Oracle and SAP installations. This can be configured as a number of instances, each individually managed by separate administrators.
Search has been rethought in SharePoint 2010, with flexibility, redundancy and scalability as the top priorities; perhaps the most notable enhancement is the ability to run multiple indexers, to increase crawl frequency, performance and volume while distributing the load among crawlers.
Security has also received attention in this release, with a new authentication model that builds on standard protocols, including SAML, WS-Federation and WS-Trust, to work with the widest possible range of identity systems. SharePoint 2010 borrows the concept of managed accounts from Windows Server 2008, which puts the farm administrator in charge of the service accounts that SharePoint uses, and allows the SharePoint administrators to change passwords automatically or manually, according to policy.
A new health analyzer component builds on the best practices analyzer of SharePoint 2007.Tthis runs as part of the browser-based administration GUI, and allows the development of custom rules to meet one's needs and supplement the predefined health rules.
All of these features are centrally administered from a browser-based dashboard; many functions can be scripted to run in PowerShell for consistent behavior and use.
Perhaps the most noticeable change on the front end for both administrators and users is the adoption of the Office ribbon interface, which is meant to provide the proper context for any task. As one would expect, the ribbon UI can be customized as needed.
On top of that, SharePoint 2010 is now more like a wiki than ever, with sites being presented as pages, rather than a grab bag of lists. Editing is now a matter of clicking on a tab and typing.
Workers who go offline frequently will benefit from the ability to use SharePoint Workspace, which caches changes and synchronizes them when the user reconnects to the SharePoint site.
SharePoint Server 2010 requires (as a minimum) a 64-bit installation of Windows Server 2008 with Service Pack 2; its database can run on 64-bit versions of Microsoft SQL Server 2005 with SP3 and Cumulative Update 3, or SQL Server 2008 with SP1 and Cumulative Update 1, or SQL Server 2008 R2.
From the user perspective, SharePoint 2010 works best with 32-bit versions of IE7 or IE8; other browsers are supported with limitations, including 64-bit IE7 and IE8 and 32-bit Firefox on Windows. For those running an OS other than Windows, Firefox 3.6 and Safari 4.04 are acceptable.
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.