WH

ITEP

AP

ER

NEW FEATURES INSHAREPOINT 2010:A DISASTER RECOVERYLOVE STORYBY SEAN MCDONOUGH AND JOHN FERRINGER

In April 2010, Microsoft released a major update to SharePoint, one of its most popular server platforms ever. Since its release, there’s been a great deal made of all the new functionality, features, and experiences that SharePoint 2010 delivers to its users and their organizations. With the launch of SharePoint 2010, Microsoft implemented sweeping changes to almost every facet of the platform, impacting users, developers, and administrators alike. Organizations had to reconcile and comprehend how to best put the new iteration of the SharePoint platform to work for their organization.

At its core, SharePoint 2010 is still a multi-tier, .NET-based application platform hosted on Windows Server and Microsoft’s Internet Information Services (IIS) web server. The overwhelming majority of SharePoint 2010’s content and configuration is still stored in SQL Server databases. The SharePoint 2010 software platform is still highly complex and often difficult to implement correctly and maintain over the long haul, which presents IT departments with a wide range of performance, stability, and maintenance challenges throughout its lifetime. At the same time, SharePoint 2010 continues to provide compelling functionality to its users and is often adopted virally and expanded far beyond the initial expectations of those implementing it.

One drawback organizations encounter with SharePoint is that both the adoption and the expansion it encourages can often have unintended or unexpected consequences, especially in the realms of performance, stability, and maintenance. The adoption and use of SharePoint 2010 also forces organizations to place a great deal additional importance on the availability and protection of the valuable content they place in their SharePoint environments—an undertaking not to be taken lightly. The good news is that throughout its numerous releases, SharePoint has provided many tools and features to aid organizations’ disaster recovery

PAG

E 1

ABOUT THE AUTHORSSean McDonoughSean McDonough is a Product Manager for SharePoint Products at Idera, a Microsoft gold certified partner and creator of tools for SharePoint, SQL Server, and PowerShell. As a consultant, Sean has worked with a number of Fortune 500 companies to architect, implement, troubleshoot, tune, and customize their SharePoint environments. Sean is an MCPD, an MCTS, and the co-author of the “SharePoint 2007 Disaster Recovery Guide” and the “SharePoint 2010 Disaster Recovery Guide”.He can be reached through:Blog: http://SharePointInterface.comTwitter: @spmcdonough

John FerringerJohn is a Senior Manager with Sogeti, LLC, with over seven years of experience administering and supporting SharePoint technologies and over thirteen years working in the information technology consulting industry. He is the co-author of the “SharePoint 2010 Disaster Recovery Guide” and the “SharePoint 2007 Disaster Recovery Guide”. He is a MCTS and a MCITP for several Microsoft server products and platforms, including SharePoint 2007 and 2010, System Center Operations Manager 2007, and Hyper-V Server, as well as a Delta Force Ranger for Office 365. He can be found online at http://www.MyCentralAdmin.com and at Twitter as @ferringer.

PAG

E 2

(DR) efforts of that valuable content. With the 2010 release, DR for SharePoint stands poised to become even easier thanks to several new capabilities and enhancements.

This whitepaper covers these new capabilities and enhancements and discusses how they fit into the overall SharePoint DR picture. We’ll also investigate when these additions may or may not make sense for your organization to implement in the service of protecting your indispensable content.

REVISITING KEY DR CONCEPTSBefore you get too far into looking at what’s new in SharePoint 2010’s DR capability set, spend some time revisiting important DR terms and concepts that should be kept in mind when considering DR planning and preparation with SharePoint 2010. These fundamental considerations, and the way your organization defines them, have as much impact on how you go about protecting your SharePoint 2010 investment as the platform’s new enhancements and additions do. You need to make sure you understand these concepts and can use them properly to plan your own SharePoint 2010 DR solutions. (For more detailed information on this subject, see our previous Idera whitepaper on SharePoint DR, “Protecting Your SharePoint Content,” and our latest book, the SharePoint 2010 Disaster Recovery Guide.)

RPO/RTOTwo terms you are (hopefully) hearing a lot as you start your SharePoint DR planning are Recovery Point Objective (or RPO) and Recovery Time Objective (or RTO). RPO and RTO are fundamental DR concepts used to help organizations define key boundaries and requirements for their customized DR solution.

RPO defines the maximum amount of data loss that is deemed acceptable in the event of a disaster. . An RPO is commonly measured in hours or

minutes, but intervals can be substantially longer or shorter depending on the function of the particlular SharePoint farm or specific aspect of the SharePoint farm.

RTO is used to describe the maximum amount of time that recovery personnel have to return a SharePoint environment, or an explicit piece of an environment, to a pre-determined state of operational readiness following a disaster. . RTO targets, much like RPO targets, are typically measured in hours or minutes. As with RPOs, RTO intervals can vary significantly. .

The High Cost of High PerformanceMost administrators would love to have a SharePoint DR solution that guarantees both zero data loss and zero downtime in the event that an outage should occur. However, these kinds of RPO/RTO targets come with a very high price tag. The important thing to remember is that establishing accurate RPO and RTO targets is very much like preparing a financial budget: You have to balance your needs and wants against the constraints of your resources. There is a very real chance you’re not going to get all (or perhaps even any) of your wants because you have to focus on your needs. Effective SharePoint DR planning is about identifying your critical SharePoint components, determining how to protect those components, understanding the constraints of your solution, and then setting reasonable expectations for your organization.

NEW DR FEATURESBefore introducing the new DR features to consider in SharePoint 2010, you should be cognizant of the impact the aforementioned fundamental concepts may have on your ability to take advantage of these new features. Take a look at how each new feature works, and consider whether or not the feature is going to offer you broad enough coverage and deliver the responsiveness you need. At the same time, think about what it takes to implement the feature and the costs that may come with

that implementation. Don’t allow yourself to get distracted by all the DR bells and whistles in SharePoint 2010; protecting your farm from a disaster is serious business, and you need to focus on finding the right fit for your environment, rather than getting overly ambitious about the new ways to use enhancements like SQL Server snapshot integration.

PowerShellHopefully by now you’ve heard of PowerShell, the command line shell and scripting language that Microsoft introduced in Windows Server 2008 and Windows Vista. If you haven’t, it’s time to get up to speed. PowerShell is designed to accelerate and automate common administrative tasks on Windows computers, and Microsoft is positioning PowerShell as the primary command line administration tool for most of its server platforms, SharePoint 2010 included. SharePoint 2010 ships with literally hundreds of pre-packaged administrative tasks (called “cmdlet” in PowerShell) for a SharePoint farm, so there is a great deal of PowerShell functionality exposed directly by the SharePoint 2010 platform.

What it isPowerShell is a scripting language and command line shell intended for both interactive administration and the automated execution of scripts. PowerShell is especially relevant to SharePoint DR, as you can use SharePoint 2010’s built-in backup cmdlets to script-out and automate backups for your farm. SharePoint 2010’s PowerShell cmdlets also offer several advantages over STSADM.exe, like full object-orientation for deeper scripting options, better performance, and enhanced functionality.

If you are already familiar with PowerShell and have used it with SharePoint 2007, the idea that using PowerShell and SharePoint 2010 together as a “new” system may be a little confusing. The thing to remember is that with SharePoint 2007, you could use PowerShell as a more efficient replacement for other scripting languages such as VBScript, but you still had to call STSADM.exe when you wanted to run

common administrative tasks against SharePoint. With SharePoint 2010, STSADM.exe is still around, but largely redundant, since all of its backup and restore operations have been duplicated as PowerShell cmdlets. Although there are still some administrative tasks that are easier to execute via STSADM.exe in SharePoint 2010 (none of them happen to be related to DR), the main reason STSADM.exe is still shipped with SharePoint 2010 is to provide backward compatibility with existing SharePoint 2007 scripts. Microsoft has been pretty clear in stating that PowerShell cmdlets are replacing STSADM.exe operations for SharePoint administration going forward.

Thankfully, Microsoft designed the DR-related PowerShell cmdlets for SharePoint 2010 similarly to STSADM.exe’s operations, providing a comfortable mapping of existing functions to the new cmdlets. The following table illustrates STSADM.exe’s operations and their new SharePoint 2010 cmdlet equivalents, along with some new cmdlets unique to SharePoint 2010:

STSADM.exe operation (SharePoint 2007) cmdlet name (SharePoint 2010)STSADM.exe –o backup –directory … (catastrophic backup operation)

Backup-SPFarm

STSADM.exe –o backup –url … (site collection backup operation)

Backup-SPSite

*** No equivalent in SharePoint 2007 *** Backup-SPConfigurationDatabase

STSADM.exe –o restore –directory … (catastrophic restore operation)

Restore-SPFarm

STSADM.exe –o restore –url … (site collection restore operation)

Restore-SPSite

STSADM.exe –o backuphistory … (backup history display operation)

Get-SPBackupHistory

STSADM.exe –o export … (content export operation) Export-SPWeb

STSADM.exe –o import … (content import operation) Import-SPWeb

PAG

E 3

What you can do with itFirst and foremost, PowerShell and SharePoint 2010’s new DR cmdlets make it much easier to create your own automated SharePoint backup solutions; it’s a much more compelling upgrade over VBScript and STSADM.exe, or even PowerShell and STSADM.exe. You now have full object-orientation to do things like easily iterating through a list of site collections to individually back them up, integrating with the .NET Framework and WMI objects for a much broader range of functions and tools to build into your scripts, and much more. SharePoint 2010 uses PowerShell version 2.0, so you can also leverage PowerShell’s built-in remoting capabilities to easily manage multiple remote SharePoint environments from a central management location. This reduces the time you spend managing your DR solution and ensures that you’re taking a consistent approach throughout your environments.

There’s also another interesting PowerShell cmdlet you should get to know: Export-Clixml. Export-Clixml serializes objects (such as PowerShell objects) into XML and stores that XML data in a file. The ability of the Export-Clixml cmdlet to transform objects into XML documents allows you to take the output of any SharePoint 2010 cmdlet and convert it into a static text document that lists the current state and configuration of the many important facets of your SharePoint 2010 farm. Before you get too excited, keep in mind that the output is just documentation; you can’t actually use it directly as a restore source should disaster strike. Export-Clixml does, however, provide a great way for you to document key information about your environment and generate useful point-in-time references when needed.

Protecting Your ConfigurationWith SharePoint 2007, Microsoft did not support the practice of restoring a stand-alone backup of a farm’s configuration database into a new farm. That restriction hasn’t changed in SharePoint 2010, but there are now new options available to organizations who want to preserve their

valuable configuration data and recover it, if necessary. Using SharePoint 2010, you can elect to manually initiate a configuration-only backup of your farm through the Central Administration site. If you prefer the command line or want to automate a configuration-only backup with a PowerShell script, you can use the Backup-SPFarm cmdlet (using the –ConfigurationOnly switch) or the Backup-SPConfigurationDatabase cmdlet.

What it isSharePoint 2010’s configuration-only backups are a significant improvement over a frustrating limitation of SharePoint 2007: the inability to capture the configuration state of the farm in a portable manner. Configuration-only backups allow you to record important information about your SharePoint farm in a consistent and repeatable fashion, making it much easier to create a baseline image of your farm’s state. These backups are not, however, all encompassing. Configuration-only backups don’t make an exact copy of a farm’s settings; they capture just a portion of its settings and configuration. Configuration-only backups capture a limited, portable subset of configuration data from your farm, such as antivirus settings, information rights management (IRM) settings, outbound email settings, installed customizations and solution packages, and diagnostic logging settings. What they don’t cover is actually a pretty big list, including web application configuration settings and service application configuration settings, both of which are pretty significant.

What you can do with itConfiguration-only backups are an extension of SharePoint 2010’s existing catastrophic backup capabilities that can help reduce your RTO targets to a certain degree. However, they won’t eradicate all the headaches associated with duplicating configuration settings to a recovery farm. Configuration-only backups do not give you the means to create an exact clone of your existing farm down to the most minute

PAG

E 4

detail. Rather, they help you capture more information about the setup and configuration of your farm and get a head start on a rebuilding effort should it be necessary. The fact that configuration-only backups cover your farm’s customizations and solution packages is a big advantage over the challenges that SharePoint 2007 presented for change management around those very same items.

SQL Server Database Snapshots Another important facet of SharePoint’s infrastructure is its databases. SQL Server is a vital and necessary component of every SharePoint farm, and the SharePoint databases hosted in it are often a key point of emphasis for successful SharePoint DR planning. SQL Server backups have long been a viable means of backing up SharePoint content, but with SharePoint 2010, you now have the ability to take advantage of a feature that Microsoft first included in SQL Server 2005: database snapshots.

What it isDatabase snapshots are fixed, read-only views of existing databases running within a live SQL Server database instance. When a snapshot is created, SQL Server creates a sparse file in its file system. As changes are made to the database after the snapshot is taken, SQL Server updates the sparse file with the content of the database prior to when the change was made. Combining the contents of the live database with the contents of the sparse file yields the snapshot, and this allows the snapshot to remain consistent to a point in time even as normal read and write activities continue to change the live database.

Database snapshots were first introduced with SQL Server 2005 Enterprise and Developer Editions. They are also available in the Enterprise and Developer editions of SQL Server 2008 and the Datacenter, Enterprise, and Developer editions of SQL Server 2008 R2.

What you can do with itUnlike previous versions of the platform, SharePoint 2010 includes native support for SQL Server database snapshots. You can create, delete, and manage snapshots explicitly through PowerShell and/or custom code which is written against the SharePoint object model using the SPDatabase class. In addition, a number of platform functions include support for leveraging database snapshots in their operations.

For example, the Backup-SPSite PowerShell cmdlet includes a –UseSqlSnapshot switch that allows you to perform a site collection backup against a snapshot of a content database, as opposed to the actual database. Using a snapshot for this operation removes the need to lock the site collection to prevent update and write operations to the database when the backup is being performed. When the backup operation is complete, the cmdlet then takes care of cleaning up the particular database snapshot. The net effect is that users can continue to operate as they normally would without interference from the backup operation. Export-SPWeb also provides a similar level of functionality for integrating with SQL Server snapshots.

The ability to avoid locking a site collection during a backup by using database snapshots can prove very useful, especially for environments with large amounts of content in their site collections. Since SharePoint 2010 locks a site collection by default when it is backed up via Backup-SPSite, using snapshots permits sites to remain available for writing, deleting, and updating while a backup is still underway.

There are a few points to take into account when using snapshots. Primarily, using snapshots places an increased performance burden on your SQL Server instance due to the overhead of writing changes to the database file, while simultaneously adding the original state to the sparse file. You should also note that while snapshots do a pretty effective job

PAG

E 5

of minimizing storage use, heavy reliance on snapshots may require you to adjust your capacity planning targets for SQL Server performance and storage.

Unattached Content Database RecoveryItem-level recovery from database backups in SharePoint 2007 is both arduous and time-consuming. It’s impossible to connect restored databases directly to your production farm because the SharePoint farm already has a copy of the database attached to it. Since the goal is to recover a single item, you also need to avoid overwriting the existing database because it contains numerous other files and objects that have changed since you took the backup. Ideally, you would access items in a restored content database and extract them directly into your production farm. The good news is that SharePoint 2010 brings you closer to this ideal with unattached content database recovery.

What it isIn practical terms, SharePoint 2010’s ability to use unattached content databases for recovery purposes removes the need for you to maintain a recovery farm purely for item-level restores. As an alternative, you now have the ability to make items within a content database available for export without actually formally joining or attaching the content database to the farm. This means that while the site collections in the unattached content database are not available for your end users to access through a web browser, the objects in those site collections can be retrieved by a farm administrator via SharePoint’s content export functionality. The contents of an unattached content database can be accessed through the Central Administration site’s export functionality, using the Export-SPWeb PowerShell cmdlet, or programmatically via the SharePoint object model.

What you can do with itThe key benefit to emerge from the unattached content database recovery in SharePoint 2010 is that it no longer requires a recovery farm for item-level restores. But there are other benefits as well. Item-level

restores in SharePoint 2007 were often time-consuming given the time it took to transfer backups to a recovery farm, restore the backups in the recovery farm, extract content out in a manageable format, transfer that content to the production farm, and then finally restore the content correctly. That doesn’t include the time it may have taken to properly update the recovery farm to the correct patch level or install required customizations. With unattached content database recovery, RTO targets can be reduced because item-level restores can be completed much more quickly and directly in your production farm.

SQL Server Database MirroringWhile most of the other new SharePoint 2010 capabilities covered so far focus primarily on backup and restore, database mirroring support is a high availability (HA) mechanism designed to provide redundancy and failover protection for SQL Server databases. Microsoft introduced database mirroring with SQL Server 2005, and has continued to deliver it in the subsequent releases of SQL Server 2008 and SQL Server 2008 R2.

What it isWith database mirroring, you set up a “principal” server to send some or all of the databases hosted in it to a second “mirror” server. Then, SQL Server automatically copies the principal’s transaction logs to the mirror to keep the databases in the mirror up to date with the databases in the principal. Database mirroring is one of three commonly used HA solutions for SQL Server (the other options being log shipping and database clustering). Mirroring offers a significant advantage over transaction log shipping, because you can add a third server to the mix as a “witness,” which automatically fails over client database connections from the principal to the mirror when the principal become unavailable.

Database mirroring is usually more cost-effective than database clustering, which also provides redundancy and automatic failover, but has a much steeper price tag to implement due to hardware requirements. It should be noted that in order for database mirroring

PAG

E 6

to be a full HA solution, a witness server (described below) is required. This requirement incurs additional hardware and software costs, as does the use of synchronous database mirroring, which can have a negative performance impact.

Although mirroring existed when SharePoint 2007 was released, the problem was that SharePoint 2007 itself was not database mirroring-aware. If you configured database mirroring with a principal, a mirror, and a witness server, SharePoint 2007 wouldn’t automatically fail over from the principal to the mirror. This meant that manual intervention or some combination of extra scripting and configuration adjustments were required to restore service should the principal go down; you had to tell SharePoint to consider the mirror its database host rather than the principal. There were some scripts and articles available that showed you how to automate that cutover process, but they were problematic and had a tendency to build a tenuous and unpredictable foundation.

What you can do with itUnlike SharePoint 2007, SharePoint 2010 is database mirroring aware. If you configure database mirroring with automatic failover for your farm’s database hosts properly, SharePoint 2010 fails over from the principal database host to the mirror as necessary. This means that DR plans involving SQL Server can accommodate much more aggressive RPO and RTO targets. From an operational standpoint, RPO and RTO windows are drastically reduced (effectively to zero) versus what they would be if you had to rebuild the principal database instance from backups.

Discussion thus far has been about database mirroring as an HA solution, not explicitly as a DR solution. In the event of a full-fledged disaster, backups are still needed; after all, database mirroring can’t help you if both sides of the mirroring configuration go down. Additionally, the cost to implement database mirroring is substantial.

Mirroring is only available in SQL Server’s Enterprise, Datacenter (SQL Server 2008 R2 only), Standard, and Developer editions. Licensing for these products can also be quite costly, and the hardware expenditures for the servers must also be taken into consideration. In addition to the hardware costs, Microsoft has some very specific guidelines for mirroring: consistent SQL Server editions/versions, gigabit bandwidth between instances, a reliable network connection between instances, sub-millisecond latency between instances, and full recovery models for mirrored databases. These guidelines add both cost and complexity to the overall DR solution.

IMPROVEMENTS TO EXISTING FEATURESMicrosoft spent a significant amount of time working to ensure that the SharePoint 2010 platform was shipped with an array of new features to simplify and enhance DR planning and implementation, but they didn’t stop there. Microsoft examined the DR features that were present in the SharePoint 2007 platform and found ways to improve a number of those for SharePoint 2010, something that paid off quite well in a few key areas.

Search ImprovementsFirst of all, consider some changes to a key feature of Microsoft’s Server version (i.e., the “non-free” version) of the SharePoint platform: Search.

Most of Microsoft Office SharePoint Server (MOSS) 2007’s components and functions can be made redundant or highly available with a combination of platform features found in SharePoint, SQL Server, and Windows itself. SQL Server clustering and Windows Network Load Balancing (NLB), for example, protect against the loss of a single SQL Server or SharePoint WFE, respectively.

However, one notable exception exists in nearly every MOSS 2007 farm: The server assigned to the Office SharePoint Server Search Index

PAG

E 7

role, or simply the “indexer.” Every MOSS 2007 farm requires that at least one SSP be defined to handle tasks associated with search, My Sites, audiences, and other shared service responsibilities. Each SSP relies on a single indexer to crawl farm content to build an index for the purpose of answering search queries. The indexer is identified during SSP provisioning, with only one server operating in that specific role for the SSP. The fact that only one server can operate as an indexer for an SSP serves as a natural barrier to achieving failover and redundancy for search indexing operations.

SharePoint Server 2010 breaks through the single indexer limitation of MOSS 2007 using a redesigned search crawling architecture. The role that a search indexer plays in a MOSS 2007 farm is now filled by one or more servers hosting a SharePoint Server 2010 crawl component. Although similar in purpose to an indexer, a crawl component is stateless in its operation and can be hosted on more than one server in a farm. Since more than one server can host a crawl component, content crawling (indexing) can be made redundant and is no longer a single point of failure in SharePoint Server 2010. At the same time, the indexing load in a farm can actually be split between multiple crawl components for increased performance. This ability to scale-up and scale-out index-building operations is a significant improvement in search operation over MOSS 2007.

The improvements don’t end with crawl components. Although the query service in MOSS 2007 can be hosted by multiple servers to keep it from becoming a single point of failure, all servers answering search queries in MOSS 2007 require a full copy of the search index generated by the indexer. The newer query components in SharePoint Server 2010 can still be hosted on multiple servers for failover and redundancy, but now, query components can be configured to serve only a subset of the index partitions for a farm, a convenience that boosts throughput and reduces

query latency. As with crawl components, query components scale both up and out to satisfy any combination of performance and redundancy requirements.

Read-Only DatabasesUnder normal operating conditions, SQL Server databases that are associated with a SharePoint environment see a steady stream of traffic. And since database traffic involves a mix of read and write requests, SharePoint databases must naturally be set to operate in read-write mode.

In some cases, you may want to operate a SharePoint farm with its databases set to read-only mode. For example, you might locate a farm in an off-site DR data center as a log-shipping destination for your production farm. In this scenario, data would flow from your production environment to your DR farm, but the read-only DR environment shouldn’t accept content changes that originate any place other than the production farm and no local content changes should occur.

SharePoint 2007 permits the use of read-only databases, but the experience and results leave something to be desired. In addition to a variety of user experience issues, there are limitations on a number of farm-level operations and services. One limitation with SharePoint 2007 is that only content databases can be set to read-only mode. None of the other SharePoint databases can be placed in read-only mode, and many services are not even capable of working with content databases that are themselves running in read-only mode.

One SharePoint 2007 service that is incapable of operating against read-only databases is Search. Consider the implications of this limitation as it pertains to a read-only DR farm. Without the ability to crawl content databases in the read-only farm, search indexing within the farm can only

PAG

E 8

occur once the databases have been toggled from read-only to read-write. This change in the state of the database would normally only take place in the event of an actual failover associated with a disaster. On the other hand, if search indexing can’t be started until the point of a DR-related failover, then Search is likely unavailable or of minimal value in the newly promoted farm, that is, until the indexer has processed the contents of the farm—a process that could take hours, days, or even longer.

SharePoint 2010 removes read-only limitations by permitting read-only operation for both content databases and service applications. The result is a better read-only database experience for both users and services alike. In the case of the Search service application, for example, a crawl component is now capable of working against read-only content databases to index their contents. In the previously described read-only log-shipped DR farm, this subtle but important change means that Search can be working to crawl the farm’s read-only content and build the index partitions needed to serve Search queries prior to a disaster. In the event of a DR-related failover, Search is up-to-date and ready to go without the need to start a full crawl from scratch.

Native Backup and RestoreMany small to mid-size companies depend on the native backup and restore functionality present in SharePoint to protect against catastrophic loss. Although native backup and restore looks, feels, and performs largely as it did under SharePoint 2007, some internal changes have been made to add new weaponry to SharePoint 2010’s arsenal. Some of these new advantages, like the ability to back up and restore service applications, require little explanation. However, a couple of other changes deserve some additional detail.

A review of SharePoint 2010’s Central Administration Default Backup and Restore Settings page reveals that you can now specify the number of threads that SharePoint uses for both backup operations and restore

operations. For both native catastrophic backup and restore operations, the default value is three threads but is adjustable from one to ten. These values provide you with a certain degree of control over backup and restore operations and how system resources are utilized during those operations. Increasing the allocated thread count leads to increased concurrency in backup and restore operations, which can result in greater performance. Keep in mind that you should exercise care when modifying the values, since significantly elevated concurrency levels in backup and restore operations may actually degrade performance, as bottlenecks shift from server-related operations to the file operations tied to the specified backup location.

Another significant change in SharePoint 2010’s native backup and restore functionality concerns the way that Search is backed up. Under SharePoint 2007, initiating a Search backup suspended the indexer’s crawling for the duration of the Search backup. This meant that in large farms with a significant corpus, the indexer was forced to play catch-up as it attempted to index content following a backup.

With SharePoint 2010, Search backup is now a two-step process. In the first step, a backup of Search is run while crawling continues to take place; the only thing that is suspended is the merging of new crawl data with the existing Search crawl data. Once the first-phase of the Search backup completes, a merge of the newly generated crawl data and the existing crawl data is conducted; a differential backup of Search then takes place following the merge. This improved two-step approach to Search backup in SharePoint 2010 means that such backups can be up to 90% more efficient than those conducted under SharePoint 2007.

Site Recycle BinThe introduction of recycle bins with the SharePoint 2007 platform was seen as a significant enhancement to end-user self-service recovery. Just like the recycle bin that Windows users are familiar with seeing

PAG

E 9

on their desktop, SharePoint’s recycle bins provide both end-users and administrators with a mechanism for the recovery of deleted content that doesn’t require IT intervention or going to an off-system backup set.

With Service Pack 1 (SP1), SharePoint 2010 extends the capabilities of the recycle bins even further. . Prior to SP1, recycle bins could be used to restore deleted lists, libraries, list items, and documents. SP1 for SharePoint 2010 enhances the safety net to include sites and entire site collections. This important change should mean that IT resources receive fewer restore requests from end-users in the future and is one of the many compelling reasons why you should consider upgrading your SharePoint 2010 environment to SP1 if you haven’t done so already.

WHERE CAUTION IS WARRANTEDSharePoint 2010 features a dizzying array of new capabilities and architectural features which can sometimes blur the line between SharePoint and other systems that either interface with SharePoint or are consumed by it. In the business of DR, this kind of overlap is generally viewed in a negative light, because it’s difficult to clearly define system boundaries and DR planning responsibilities.

Before you begin the process of disaster recovery planning for your SharePoint 2010 environment, there are a couple of new technology and feature areas that you should take some time to learn and understand. If any of these are relevant to your environment, be sure to account for them properly in any DR planning and implementation you undertake.

Service ApplicationsGone are the “all or nothing” days of SSPs and their fixed set of service offerings. Service applications in SharePoint 2010 have replaced the SSPs of MOSS 2007, and in the process they have given administrators the flexibility to provision and use only the services (such as Search and Managed Metadata) applicable to their specific SharePoint environments.

Service applications afford a level of granularity, control, and scalability to services that MOSS 2007 left to be desired.

The downside to this unprecedented level of flexibility is a new level of architectural complexity and an increase in supporting middle-tier infrastructure. Although they are built on top of a common Service Application Framework, each service application is unique in its design and in the implementation of the Service Application Framework. Some service applications are backed by a single SQL Server database, while some utilize multiple databases, and yet others have no backing database at all. Most service applications use Windows Communication Foundation (WCF) endpoints that are exposed through IIS, but WCF endpoints are not a firm requirement. Most service applications are also backed by Windows services and host configuration data in the SharePoint farm configuration database. Service applications also have proxies, which serve as connection points for consumers, while some service applications can even be consumed across farm boundaries.

As you can see, service applications have their components, configuration, and operational data scattered throughout a SharePoint farm – and in some cases, across SharePoint farms. Backing up and restoring all of the data associated with a service application is no simple feat. In most cases, the simple act of incorporating service applications into a DR strategy increases the complexity of the strategy significantly. When planning your strategy, be sure to give service applications the attention they deserveand exercise test plans involving them rigorously.

Remote BLOB Storage (RBS)SharePoint stores nearly all user-originated content in content databases. This includes file uploads, metadata pertaining to those files, and other content that is entered most commonly through SharePoint’s web-based user interface. Although storing everything in content databases works well in many SharePoint environments, it isn’t the best fit for

PAG

E 10

all organizations. For example, some companies might prefer to store uploaded files on a medium that is less expensive than database storage, such as a networked file share or even cloud-based storage. Other organizations might desire a way to leverage features like tiered-storage and de-duplication of their uploaded SharePoint file content.

For companies and organizations seeking to alter the SharePoint storage equation, Microsoft has built support into SharePoint 2010 for SQL Server 2008 RBS. With RBS, you can split data that would normally go into a SharePoint content database into two streams: 1.) Non-file information, such as metadata and loose authored content, which still goes into a content database, and 2.) Uploaded files, which are passed to an RBS provider for storage in an external system rather than stored as a binary large object (BLOB) in the appropriate content database. Depending on the capabilities of the RBS provider, the uploaded file contents (BLOBs) can be stored on a less-expensive storage medium, de-duplicated, and more.

The storage of BLOBs in some form that is external to a content database may provide a combination of cost and operational advantages, but it can also complicate your DR protection strategy. Without RBS, backing up a content database is enough to ensure that the total content it represents, file and otherwise, is protected. When RBS is in use, a content database only contains part of the data you must protect. The uploaded file BLOBs reside in some other location and you must make certain to account for this as you plan your protection strategy.

Business Connectivity Services (BCS)The Enterprise Edition of MOSS 2007 introduced SharePoint users to the Business Data Catalog (BDC), and in doing so, greatly increased the value of SharePoint as an information aggregation point and data hub from disparate systems. The BDC also simplified the process of “wiring-up” SharePoint to other line-of-business (LOB) systems for purposes of consuming their data.

BCS in SharePoint 2010 builds upon the foundation laid by MOSS 2007’s BDC, and addresses a number of its constraints—most notably the read-only limitation of BDC connections to LOB systems. BCS is fully capable of reading from and writing to LOB systems and other data sources. In addition, establishing connections to external systems with BCS is greatly simplified over the same BDC-related process, and support for building BCS connections is available within SharePoint Designer 2010. With SharePoint Designer 2010, end-users can define external content types (ECTs) easily and build external lists that make the data from external LOB systems appear as though it actually lives within SharePoint itself.

The fact that BCS-exposed LOB data appears to reside within SharePoint warrants special attention when undertaking DR planning for SharePoint. When BCS is used within your SharePoint environment, your DR plan must account for the fact that users perceive external LOB system data to be “part of SharePoint.” If a disaster occurs and SharePoint is returned to an operational state without the LOB systems it exposes through BCS, then it resembles a deficiency in DR planning for SharePoint itself. Exposed LOB systems should be treated as dependencies during SharePoint DR planning, and an effort to communicate and raise user awareness regarding where SharePoint ends (and LOB systems begin) can help to set user expectations accordingly in the event of a disaster.

PAG

E 11

CO

NC

LUSI

ON CONCLUSION

Proper business continuity planning for your SharePoint environment is a challenge, and Microsoft has enhanced the SharePoint 2010 platform significantly with new tools and capabilities to improve your user experience. Features such as PowerShell integration, configuration-only backup, SQL Server snapshot integration, unattached database recovery, and SQL Server database mirroring all address limitations and overcome barriers that presented DR-specific challenges in older SharePoint 2007 environments. At the same time, improvements to SharePoint 2010’s handling of read-only databases, Search, native backup/restore, and recycle bins make it easier than ever for you to leverage these components and capabilities as part of a comprehensive DR strategy.

Along with its new and improved capabilities, SharePoint 2010 introduces some novel challenges and caution areas that must be accounted for when putting together a DR plan. Your DR plans should address any gaps or gray areas that may be introduced by the use of service applications, RBS, and BCS in your environment.

ABOUT IDERAIdera provides tools for Microsoft SQL Server, SharePoint, and PowerShell management and administration. Our products provide solutions for performance monitoring, backup and recovery, security and auditing, and PowerShell scripting.

Headquartered in Houston, Texas, Idera is a Microsoft Gold Partner and has over 5,000 customers worldwide.

For more information or to download a 14-day trial of any Idera product, please visit www.idera.com.

Idera is headquartered in Houston, TX with offices in London and Melbourne.

WEB www.idera.comTWITTER www.twitter.com/Idera_Software FACEBOOK www.facebook.com/IderaSoftwareLINKEDIN www.linkedin.com/groups?gid=2662613

US EMEAAPACMEXICOBRAZIL

+1 713 523 4433877 GO IDERA (464 3372)+44 (0) 1753 218410+61 1300 307 211+52 (55) 8421 6770+55 (11) 3230 7938