Within a few weeks, SharePoint 2010 should be released to manufacturing (RTM), and the SharePoint 2010 revolution will begin. It's not just the business and your customers—internal and external—that will benefit from enhancements to SharePoint 2010. With more enterprises storing more mission-critical data in SharePoint, Microsoft was compelled to bring to the table significant improvements to the administration, management, security, scalability, deployment, and governance of SharePoint implementations. What Microsoft has created in the three years since the release of SharePoint 2007 is impressive. In this article, I'll explore the changes to SharePoint that impact you, the IT pro.
Of course, work at Microsoft is ongoing between the time of this writing and RTM, and I'll be covering all the latest developments at www.sharepointproconnections.com. Be sure to check there for the latest changes.
64-Bit Only
SharePoint 2010 raises the stakes—significantly—for your infrastructure. Gone are the days of 32-bit servers and of virtual machines (VMs) hosted on 4GB laptops for developers. It requires 64-bit hardware for each server in the farm, including your database server, and therefore requires 64-bit versions of Windows and Microsoft SQL Server. Windows Server 2008 is the minimum OS version for production servers; Windows Server 2008 R2 is highly recommended. You need SQL Server 2008 R2, SQL Server 2008, or SQL Server 2005 to support SharePoint 2010. And with each of these products, you must have the latest service packs and updates. The specifics are changing regularly in the run up to RTM, and will continue to change as products such as SQL Server 2008 R2 are released, so you should consult TechNet for the latest information about SharePoint 2010 hardware and software requirements.
SharePoint 2010 can be installed with slightly lower memory requirements—4GB of RAM—for development and evaluation. Developers also can install SharePoint 2010 on 64-bit Windows 7 or Windows Vista clients—a welcome change from the previous requirement to develop on a server platform.
The 64-bit requirement for SharePoint 2010 isn't premature, given the fact that it's been difficult to buy a 32-bit–only server for many years now. And the performance benefit of 64-bit code is significant. However, many organizations, particularly small businesses and enterprises in developing nations, are struggling to provision hardware that meets SharePoint 2010's standards. The 64-bit requirement is likely to be the top reason cited for delays in migrating from previous versions of SharePoint to SharePoint 2010.
SharePoint Foundation and SharePoint Server
Microsoft continues to offer a free version of SharePoint, SharePoint Foundation 2010, which replaces Windows SharePoint Services (WSS) 3.0. Like its predecessor, SharePoint Foundation 2010 supports many collaboration scenarios through features such as lists, libraries, and team sites. SharePoint Foundation continues to provide core functionality, including administration, management, authentication, and Office client integration. SharePoint Foundation 2010 incorporates some of the platform functionality formerly provided by Microsoft Office SharePoint Server (MOSS) 2007, most importantly service applications, which I'll discuss later.
I've spent a lot of time explaining to clients that they don't need MOSS on every farm—WSS supports collaboration scenarios quite effectively and therefore lets you place multiple, decentralized WSS collaboration farms in remote sites and maintain a centralized MOSS farm for intranet, search, My Sites, and other MOSS services. Many people have swallowed Microsoft's marketing message whole and believe they need MOSS for every scenario. That just isn't the case.
The same situation holds true with SharePoint 2010. I expect Microsoft will push SharePoint Server hard, but it's not the only answer. SharePoint Foundation could be the answer for many collaboration requirements. Be sure you need SharePoint Server before you pay for it.
However, SharePoint Server brings a lot more chips to the table, such as enterprise search and social networking features. The Enterprise license adds full-strength business intelligence, including Excel Services and connectivity to back-end data sources. In addition, InfoPath forms, Visio Services, FAST Search, Access Web Services, and the Office Web Applications are compelling capabilities of the Enterprise version. I believe that Access Web Services and Office Web Applications are the killer aps for the Enterprise edition that will be major drivers toward full-blown SharePoint Server 2010 farms in the next few years.
Of course, SharePoint 2010 will be offered as a hosted service as well, continuing Microsoft's drive for Software Plus Services. You can read about that option in the sidebar, "What SharePoint 2010 Offers Online."
Upgrade Options
After you ensure that your infrastructure meets the SharePoint 2010 prerequisites and decide on your mix of SharePoint Server and SharePoint Foundation, and on-premises and hosted services, you're ready to start thinking about upgrading your current SharePoint implementation. When you upgrade to SharePoint 2010, you might also need to upgrade to 64-bit hardware, and potentially upgrade your Windows and SQL Server versions as well. It's important that you do each prerequisite upgrade before upgrading SharePoint itself. You can combine upgrades of the prerequisites—for example, upgrading from 32-bit Windows Server 2003 to 64-bit Windows Server 2008 R2. Make the upgrade from a previous SharePoint version to SharePoint 2010 the last step.
You have two upgrade paths to SharePoint 2010. The first, an in-place upgrade, involves installing SharePoint 2010 (Foundation or Server) on an existing SharePoint 2007 farm. An in-place upgrade requires downtime for the farm, but it preserves farm settings and customizations. Alternatively, you can perform a database attach upgrade, in which you attach an existing SharePoint 2007 content database (either MOSS or WSS) to a SharePoint 2010 farm, and upgrade the content database in the process. This method can be faster than an in-place upgrade because SharePoint can upgrade multiple content databases concurrently, but it requires a separate SharePoint 2010 farm and therefore requires you to manually configure farm settings and customizations. There are also hybrid upgrade paths that combine these two approaches. You can find more about upgrade options in the TechNet article "Upgrading to SharePoint Server 2010."
The upgrade to SharePoint 2010 preserves the UI of MOSS 2007 and WSS 3.0, letting you leverage the new platform management and administration capabilities while letting business owners retain control over when to unleash the new UI, including the Ribbon, and the new user features. For each upgraded site, you can preview the new UI and its impact on the site by using a new feature called Visual Upgrade. While a site is in preview state, you can continue to make changes to it, but only changes that are compatible with the earlier version of SharePoint. You can switch between the SharePoint 2010 preview mode and the legacy SharePoint compatibility mode. When you're ready to commit to the new UI and features, you can update the UI and enable SharePoint 2010 features.
Improved Administration
Central Administration has had an extreme makeover, resulting in a cleaner layout, organized in logical, task-based groupings. The Ribbon makes its SharePoint debut, making administrative tasks easier to discover. Figure 1 shows the new interface for managing Web applications. You no longer have to change Web applications within a command; instead, select a Web application, then choose a command on the Ribbon.
Central Administration also adds wizards that make it easier to step through common configuration sequences, including the initial configuration of a farm. No more bouncing back and forth between a configuration task list and the actual configuration tasks.
Central Administration isn't the only administrative game in town. Stsadm.exe continues to provide command-line administration capabilities and, new to SharePoint 2010, Windows PowerShell lets you perform both simple and complex configuration and automation. So far, over 500 PowerShell cmdlets are exposed in SharePoint 2010. When SharePoint 2010 RTMs, Microsoft will publish some useful PowerShell scripts, including farm, server, and site provisioning scripts, and scripts that move data from file servers into SharePoint document libraries.
Many organizations have fought SharePoint proliferation—instances of SharePoint (particularly WSS) being installed on servers by administrators acting outside of the SharePoint governance plan. SharePoint 2010 addresses this governance problem by introducing Active Directory markers that let you track SharePoint installations, and Group Policy blockers to prevent unauthorized SharePoint installations.
High Availability, Recovery, and Storage
SharePoint 2010 introduces a rudimentary solution for high availability. A Web application can be configured to refer to a second instance of SQL Server. If the primary instance of SQL Server fails, SharePoint will fail over to the second instance. Of course, the assumption is that you're leveraging SQL Server capabilities such as mirroring to replicate the database to the second instance. This is an important new feature, but it has its limits. First, the solution isn't positioned as a solution for geographic distribution and replication of data. In other words, this is for failover, not for a remote office to have a local SQL Server instance. The entire farm looks at one instance of SQL Server or the other—not both.
Second, and more importantly, although the failover story is decent, the failback story has its rough spots. My peers who have worked with this feature report that the process of restoring operations of the farm against an up-to-date instance of the original SQL Server database is ugly and frustrating. So SharePoint 2010's out-of-box high-availability solution is a start, and might suffice for some businesses, but there's still plenty of room for third-party high-availability solutions.
SharePoint 2010 does encroach on third-party backup-and-restore solutions. Such solutions are all but mandatory with SharePoint 2007, which can recover content only down to the site-collection level on its own; third-party utilities are required to recover a site, list, library, item, or document. SharePoint 2010 lets you natively recover sites, lists, libraries, items, and documents. With unattached content database recovery, you can mount a detached content database and perform operations from within Central Administration, including browsing content, extracting a document, backing up a site collection, and exporting a site or list. SharePoint 2010's recovery functionality is much improved and will address the needs of a broader range of enterprises, but still leaves room for functionality and manageability features from third-party solutions.
Many changes have been made to improve the way SharePoint stores and retrieves content, and additional improvements come with newer editions of SQL Server. One of the most important changes is Remote BLOB Storage (RBS). This feature lets you store BLOBs, such as documents in a document library, in a location other than the SharePoint content database. The most easily understood example of this is an implementation that uses the file system provider in order to store document library documents on a server's file system, rather than in the content database. This storage method reduces the size of the content database significantly, reduces the impact of SharePoint on your SQL Server infrastructure, moves files to file servers, which are cheaper to maintain and support, and lets you get past the 2GB BLOB size limit of SharePoint.
Monitoring SharePoint Health and Usage
SharePoint 2010 delivers significant improvements in health and configuration monitoring, providing what Microsoft calls "deep operational insight" into service performance and server health. You can use the Review problems and solutions page in Central Administration, which Figure 2 shows, to identify potential problems. This page shows results generated by using a set of rules run periodically and automatically through the new Best Practices Analyzer. Each problem entry includes a description of the problem and guidance for remediation. The out-of-the-box rules are customizable—you can even configure a rule to automatically correct a problem—and the rule definitions are extensible, so third parties can add rules. This "Best Practices Analyzer on Steroids" is a major addition to the health monitoring capabilities of SharePoint.
You need to know more than whether a server is healthy or sick—you also need to know how a SharePoint farm is being utilized: which sites and pages are being hit, and which pages or processes are consuming system resources. SharePoint 2010 introduces a new database to support usage reporting and logging, and the unified logging database keeps track of just about everything SharePoint does, from individual feature usage to the length of time it takes to load a page.
Some useful analytics reports are built-in, such as reports for slowest pages and top users, and you can add your own reports thanks to the fully documented database schema. The usage database and logging infrastructure is extensible, letting you and third parties log events and tracing data and generate customized reports. With this kind of insight, you'll have the hard metrics you need to tweak settings, change page designs, and optimize code.
Governance Over Customizations
Speaking of code, the Developer Dashboard lets administrators and developers monitor the impact of customizations on pages. The Dashboard can be exposed on a page to reveal performance and debugging information.
Any custom code has the potential to affect other processes and system resources on a SharePoint farm. The Developer Dashboard provides insight for monitoring and debugging, but real control is exerted by deploying sandboxed solutions. Using sandboxed solutions, deployed as SharePoint solutions (.wsp) packages that can touch a limited set of APIs, you can isolate custom code to prevent it from affecting other processes, and to control the resources that can be consumed. You can delegate the ability to upload custom user code to site admins with the confidence that any problems won't harm other apps or the farm. Site admins can also be delegated the ability to monitor and deactivate the feature that enables the problematic custom code.
In addition to controlling custom code, SharePoint 2010 gives you control over other customizations, including look-and-feel changes such as themes and customizations made using SharePoint Designer 2010.Unfortunately, the benefits of developing for and customizing SharePoint using Visual Studio 2010 and SharePoint Designer 2010 apply only when those applications are used against SharePoint 2010. In fact, you must use previous versions of Visual Studio and SharePoint Designer to code for and customize SharePoint 2007. If your enterprise includes mixed levels of farms, you'll need to support both customization and development environments. This fact alone might make you want to upgrade the entire enterprise to SharePoint 2010 as quickly as possible.
Governance Over Client Integration
Office 2010 client applications provide additional functionality when paired with SharePoint 2010. While Word, PowerPoint, Excel, Access, Outlook, Project, and OneNote continue to improve their already strong SharePoint integration, specific applications, such as SharePoint Workspaces (formerly known as Groove), SharePoint Designer, and InfoPath, will see increased use and might be entirely new to your organization. When your users discover what they can do with these applications, your governance plan had better explain when these applications will be supported.
SharePoint 2007 let you enable or disable all client integration with a single switch. SharePoint 2010 adds granularity. At the list or library level, you can enable or disable Microsoft Office client integration features.
Extended Browser Support
In some ways, IT pros have it easy with SharePoint 2007. Users can access SharePoint only through Internet Explorer, and some of my clients have used that fact as an excuse to prohibit installation of Firefox, Safari, and other browsers. The good news is that SharePoint 2010 supports Firefox and Safari, as well as other browsers and devices. The bad news is that now you might be asked to support those browsers.
List and Library Scalability
Microsoft has improved the experience with lists and libraries in SharePoint 2010, which now supports lists and libraries with millions of items. Changes to both the back end (with improved SQL Server queries) and the front end (how web front-end servers retrieve and present list and library content) make a world of difference by balancing the end-user experience with the impact on the server infrastructure.
On the server side, you can configure Web application settings that control the maximum number of items returned by a query generated by a list or library view; the default is 5,000 items. You can set different limits for administrators and nonadministrative users. When a view generates a number of items greater than this limit, a warning message appears at the top of the list informing the viewer that the view isn't returning all items. Additionally, a warning appears on the List Settings page.
Web application settings let you set what is oddly called the Happy Hour window—a period of time each day during which query limits aren't applied. You set the window to start at a specific time each day, seven days a week, to run for a whole number of hours. Both the name and the lack of granularity of control qualify the Happy Hour window as a half-baked feature.
When it's not Happy Hour, views won't return more items than the query limit, but SharePoint 2010 makes it easy to help users dynamically filter data to narrow the result set. Metadata can be used to create a navigation hierarchy and content filters. The result is a tag-based folder hierarchy, using keywords or metadata, that filters the result set and therefore narrows the number of items returned.
Farm Service Scalability
Service applications in SharePoint 2010 replace the Shared Services Provider (SSP) model of SharePoint 2007. Forget everything you know about SSPs. The new model is radically different, better, and easier.
SharePoint 2010 has several built-in services, including Business Data Connectivity, Visio Graphics Service, Excel Services, Office Web Apps, Search, User Profile, Web Analytics, and the new Managed Metadata Service, which creates a central store for taxonomy and content types. Each service runs as an application exposed as a Windows Communication Foundation (WCF) service on one or more application servers in the farm. Consumers such as web parts, typically on web front ends, utilize the service. To connect the consumer to the service, each service application has a proxy that knows how to talk to the service.
This architecture, which is completely extensible so that third parties can create new service applications, offers several advantages. First, a service can be published to other farms by installing the service application proxy on the other farm and pointing it to the Uniform Resource Identifier (URI) provided by Central Administration when you publish the service application. Therefore, farms can share service applications, providing unified services for functions such as search, taxonomy, data aggregation, and analytics.
Second, Web applications can be configured to use one or more instances of a service. For example, a Web application for a company's finance department can consume a taxonomy service (the Managed Metadata Service) that provides a taxonomy specific for finance and another service that provides a unified, enterprise-level taxonomy.
Third, services can be scaled up in times of high demand. If a service is in high demand, you can deploy the service application to additional application servers. When the service proxy queries the farm for the location of the WCF service, the service architecture returns the instance of the service in round-robin fashion, including the new application servers.
Another capability of service applications is multi-tenancy, which is used to partition a service so that it returns a subset of data. The classic use of this technique is for hosted SharePoint offerings where a single Search service is used by several hosted customers. Obviously, it's important that search results are restricted to each customer's data—that a security layer prevents leakage of search results. This security is achieved by implementing multi-tenancy, which adds a subscriber ID field to each row of data in the Search service. A site collection, which is specific to a customer, with that subscriber ID can return results only from the service that matches the subscriber ID. There will certainly be other services and other scenarios—even intranet scenarios—in which enterprises will want to partition the data returned by a single service application.
Wrapping It Up
This article has described many significant changes for IT professionals in SharePoint 2010. Microsoft groups these improvements into three categories: Increased Productivity, Scalable Unified Infrastructure, and Flexible Deployment. These high-level groupings obscure some of the most important and high-impact aspects of SharePoint 2010. I've tried to point out the features I think will be most welcome—or most half-baked—but only time will tell, after enterprises get SharePoint 2010 into production.
