Events, SharePoint

The SharePoint Journey

Microsoft Ignite will open the window to our vision, strategy, and future for SharePoint and provide a first look at most recent developments with SharePoint Server 2016.  From the business value for organizations looking to modernize their workplace and infrastructure to the technical value it will deliver to IT Professionals and Developers as well as new hybrid investments for those customers looking to enrich their existing investments with cloud innovation.

With Microsoft Ignite just around the corner, it’s time to look back and provide a little historical SharePoint information.

There have been 5SharePoint releases.

1997-1998

“Exchange and SharePoint become best friends”

Exchange Server works on a new information store (Web Store) to support document, web content, and e-mail management.

Codename Tahoe (the genesis of SharePoint Products and Technologies) advances Platinum introducing document management capabilities through WebDAV – Document Authoring and Versioning in addition to an improved search and indexing engine.

Platinum and Tahoe would represent a new, next generation messaging, collaboration, and document management platform.

Learn more about the evolution of SharePoint’s storage architecture at http://blogs.technet.com/b/wbaer/archive/2012/12/20/shredded-storage-and-the-evolution-of-sharepoint-s-storage-architecture.aspx.

1999

“A gem is found in nuggets”

Microsoft makes available a free download called Digital Dashboard Starter Kit introducing our first portal framework.   Solutions based on the starter kit enabled a user interface that could reside within Outlook through visual aids called “nuggets” that displayed information from a variety of content sources – “nuggets” would later take on the name Web Parts.

2000-2001

“A rolling milestone gathers no moss”

Tahoe reaches its beta 1 milestone in early 2000 and the Digital Dashboard Starter Kit is renamed the Digital Dashboard Resource Kit.  In mid-2000 Tahoe reaches another important milestone (Beta 2) with important changes to include a new user interface based on the Digital Dashboard Resource Kit creating a “true” portal user experience and subsequently retiring its codename in favor of SharePoint Portal Server 2001.

2001

“So it begins”

SharePoint Portal Server 2001 is released and creates a portal web site that allows users to share documents and search for information across the organization and enterprise, including SharePoint Team Services-based Web sites—all within one extensible portal interface. SharePoint Portal Server includes robust document management features that allow companies to incorporate business processes into their portal solution, but is limited by the Web Store and Digital Dashboard.

Web Store performance and scalability limited the expansion of SharePoint and Digital Dashboards were developed outside of the core development platform (Visual Studio) which limited the audience for extensibility.

In parallel the fledging portal market began to see unprecedented growth and overlap with the existing  Web Content Management (WCM) market which included CMS 2001.

As the growth and adoption of SharePoint Portal Server 2001 continued to rise in the then new portals market, SharePoint Team Services was released in conjunction with Office 2000 providing web-based team-centric collaboration capabilities.

Untitled

2002-2003

“Raise the roof”

The Web Store, the storage foundation for SharePoint Portal Server 2001 is replaced with SQL Server as the storage backend – on the other side of the topology Digital Dashboards were phased out in favor of ASP.NET improving overall scalability and portal capabilities at the expense of some document management capabilities, notably document profiles and workflow that were to be removed from the upcoming SharePoint release.

This was also a tumultuous time for SharePoint Team Services – but in the end the teams responsible for SharePoint Portal Server and SharePoint Team Services were converged.  In parallel to the changes affecting the technologies that powered SharePoint, CMS evolved as well leveraging ASP.NET on the frontend and delivered as CMS 2002.

In 2002 SharePoint Team Services officially was renamed as Windows SharePoint Services (WSS) and packaged in Windows Server 2003 as a Feature of the server – like SharePoint Portal Server it also provided a collaboration store and Web Part user interface build on ASP.NET.

In this same period SharePoint Portal Server (v2 at the time) was officially branded Microsoft Office SharePoint Portal Server 2003 (no longer referred to as codename Matrix), built on top of Windows SharePoint Services, but delivered independent of Windows Server 2003.

sharepointserver2003

This new release contained important scenarios such as search and indexing, but also ushered in personalization (people-centric collaboration), and enhanced taxonomy capabilities with improved overall manageability.

2004-2005

“Got SOX”?

SOX or Sarbanes-Oxley is introduced to the world and changes document and records management practices.  In response, the CMS and SharePoint Portal Server groups converge in 2004 and Web Parts built using ASP.NET were enabled for developers.  The extensibility era begins…

Near the end of 2005 ASP.NET v2 launches to include new native Web Parts and Windows Workflow Foundation becomes a native add-on to Windows Server that provides a new workflow service that other applications can build on.

2005

“Time to Groove”

In 2005, Grove was acquired, a peer-to-peer (P2P) team-based collaboration product that also includes synchronization of SharePoint sites.

2006-2007

“Who puts MOSS on a server anyway”

Microsoft Office SharePoint Server 2007 is born signifying a leap forward in experiences.

Microsoft Office SharePoint Server 2007 was defined as a Microsoft server product that creates a portal website that allows users to share documents and search for information across the organization and enterprise within one extensible portal interface.

SharePoint-2007

Windows SharePoint Services moves forward, but now as a standalone product versus Windows Server feature.

Groove Server 2007 is released with Microsoft Office SharePoint Server 2007, which provides the server software and tools that IT organizations can use to best deploy, manage, and integrate the Groove functionality that comes with the new Groove 2007.

2009

SharePoint Server 2010 is released, the first in two successive releases to drop the Microsoft Office branding.

SP2010

Groove is renamed SharePoint Workspace and released as Microsoft SharePoint Workspace 2010, the server management platform remains Groove Server and released as Groove Server 2010.

2012

10/11/12 the world is introduced to the most recent generation of SharePoint Products and Technologies, SharePoint 2013.

prev_EN_ShrPt_Srvr_PT_C_rgb

Personal sites, a staple of SharePoint people-centric collaboration are rebranded and paired with a new sync client powered by Groove as SkyDrive Pro, over the course of the SharePoint Server 2013 release these capabilities will become OneDrive for Business.

2015

The next generation of SharePoint is revealed as SharePoint Server 2016 – want to learn more…  Register now for Microsoft Ignite.

Standard
Administration, SharePoint

Implementing SQL Server Code Name “Denali” CTP3 AlwaysOn Availability Groups with SharePoint Server 2010

If you attended my SharePoint Conference Session on SharePoint 2010 on SQL Server Denali you’re probably ready to get started with some of the features and capabilities we discussed and demonstrated today, particularly AlwaysOn Availability Groups which provide a robust, ready to use solution supporting both local redundancy and remote disaster recovery.

NOTE

SharePoint 2010 is not currently supported on SQL Server Code Name “Denali”.

There are several prerequisites to using AlwaysOn which are documented further at http://msdn.microsoft.com/en-us/library/ff878487(v=SQL.110).

Windows Server Failover Clustering

While SQL Server Denali does not need to be clustered from a SQL Server perspective, the nodes on which SQL Server Denali is installed should be members of the same WSFC if configuring an AlwaysOn scenario.

NOTE

The steps in this post make several assumptions about the SQL Server environment where SQL Server Codename “Denali” will be installed. The steps to install and configure SQL Server Codename “Denali” may differ as a result.

These steps will help you configure AlwaysOn in a SQL Server Code Name “Denali” environment.

Download SQL Server Code Name “Denali” CTP3

Download SQL Server Code Name “Denali” CTP 3.

Download SQL Server Code Name “Denali” CTP3 at the TechNet Evaluations Center.

Create or Select a Windows Server Failover Cluster

Choose and existing or create a new Failover Cluster on which each node SQL Server Code Name “Denali” will be installed.

Install .NET Framework 3.5.1

On each Windows Server where SQL Server Code Name “Denali” will be installed install the .NET 3.5.1 Features.

  1. Open Server Manager and select the Features node.
  2. In the Feature pane select Add Features.
  3. Expand .NET Framework 3.5.1 Features and select .NET Framework 3.5.1.
  4. Click Next > to install the select Features.

Install SQL Server Code Name “Denali” CTP3

Install SQL Server Code Name “Denali” CTP3.  For installation instructions see also Installation for SQL Server ‘Denali’.

Enable Named Pipes and AlwaysOn High Availability Groups

Enable Named Pipes and AlwaysOn High Availability Groups.

Enable Named Pipes

  1. Click Start | All Programs | Microsoft SQL Server Denali CTP3 | Configuration Tools | SQL Server Configuration Manager.
  2. Expand SQL Server Network Configuration and then select Protocols for MSSQLSERVER.
  3. Right-click Named Pipes and select Enable from the list of available options.

NOTE

MSSQLSERVER will need to be restarted to commit the changes.

In SQL Server Code Name “Denali” you will need to include the startup option 9532 (TraceFlag 9532) to enable enabling AlwaysOn High Availability Groups.  To configure the required startup option on each Windows Server where SQL Server Code Name “Denali” is installed:

  1. Click Start | All Programs | Accessories | Command Prompt.
  2. Enter NET STOP MSSQLSERVER.
  3. Enter NET START MSSQLSERVER /T9532.

Enable AlwaysOn High Availability Groups

  1. Click Start | All Programs | Microsoft SQL Server Denali CTP3 | Configuration Tools | SQL Server Configuration Manager.
  2. Select SQL Server Services.
  3. In the details pane right-click SQL Server (MSSQLSERVER) and select Properties from the list of the available options.
  4. Select AlwaysOn High Availability, select the checkbox labeled Enable AlwaysOn Availability Groups and click OK.

NOTE

The Windows Failover Cluster Name should appear on the AlwaysOn High Availability dialog.  MSSQLSERVER will need to be restarted to commit the changes.

Create a Seed or select an existing Database

Create a seed database.

NOTE

At least one database must exist to create a new Availability Group in Step 9 below.  This step is not required when installing SharePoint Server 2010 using DBA created databases.  For information on installing SharePoint Server 2010 using DBA created databases see Deploy by using DBA-created databases (SharePoint Server 2010).

  1. Click Start | All Programs | Microsoft SQL Server Denali CTP3 | SQL Server Management Studio.
  2. Right-click the Databases node and select New Database…
  3. Enter Seed in Database name: and click OK.

Backup the Seed or an existing Database

Backup the Seed Database

  1. Click Start | All Programs | Microsoft SQL Server Denali CTP3 | SQL Server Management Studio.
  2. Expand Databases.
  3. Right-click Seed and select Tasks, and then select Back Up…
  4. On the Back Up Database – Seed dialog click OK.

NOTE

Prior to adding a database to an Availability Group a FULL backup of the database must exist.

Create a Network Share

Create a Network Share

A network share must exist and must be accessible by all nodes in the AlwaysOn configuration in order to perform initial data synchronization.

Create an Availability Group

Create a new Availability Group

  1. In Object Explorer, connect to the server instance that hosts the primary availability replica, and expand the server tree.
  2. To launch the New Availability Group Wizard, expand the Management node, right-click the Availability Groups node, and click New Availability Group.
  3. On the Specify Availability Group Name page, enter the name of the new availability group in the Availability group name field. This name must be a valid SQL Server identifier that is unique on the WSFC failover cluster and in your domain as a whole.
  4. On the Select Databases page, the User databases meeting high-availability requirements grid lists local user databases that are eligible to become the availability databases for the new availability group. Select one or more of the listed databases to participate as availability databases in the availability group. These local availability databases will initially be the primary databases of the new availability group. 
  5. On the Replicas tab, the Selected instances grid initially displays only the instance of SQL Server to which you are connected. This server instance will host the initial primary replica. To specify the server instance that will host the secondary replica, click Add. Note that in CTP3, you must add a single secondary replica now.
  6. Select the desired configuration for each instance in the Selected instances grid.
  7. Click Next.
  8. Click Finish to create the Availability Group.
  9. Click Start Data Synchronization to initiate initial data synchronization.

NOTE

The following restrictions exist for using the New Availability Group wizard to start data synchronization:

  • If the file paths on the secondary replica location from the file paths on the primary location, click Close to exit the New Availability Group wizard now and then start data synchronization manually.
  • If any secondary database already exists, using the New Availability Group wizard to start data synchronization requires manually deleting these secondary databases before you click Start Data Synchronization. If want to use your existing secondary databases, click Close to exit the New Availability Group wizard now and then start data synchronization manually.
  • If you have clicked Start Data Synchronization the Start Data Synchronization page opens. This page requires a network share (backup share). Either browse for your backup share, or enter its fully qualified universal naming convention (UNC) path name, \SystemnameShareNamePath, in the Specify a shared network location for backups field. Optionally, click Test to verify the path.

For each database in the availability group, the Start Data Synchronization page displays the progress of the following operations:

  1. Creating a full database backup of the primary database on the network share.
  2. b. Creating a log backup (which will be part of the backup log chain) on the network share.
  3. c. Restoring these backups onto the secondary replica location. These restore operations both use RESTORE WITH NORECOVERY, leaving the new secondary database in the RESTORING state.
  4. d. Joining the secondary database to the availability group. This step puts the secondary database in to the ONLINE state, and starts data synchronization for this database.

Column

Description

Replica Location

Displays the name of the server instance that will host the availability replica.

Read Mode in Secondary Role

Specifies whether the availability databases on this replica location will be readable when the availability replica is serving as a secondary replica (performing the secondary role).

Select one of the following values from the drop-down list:

Value Description

Disallow ConnectionsNo direct connections are allowed to secondary databases of this replica. They are not available for read access.

Allow Only Read Intent ConnectionsOnly direct read-only connections are allowed to secondary databases of this replica. The secondary database(s) are all available for read access.

Allow All ConnectionsAll connections are allowed to secondary databases of this replica, but only for read access. The secondary database(s) are all available for read access.

Initial Role

Indicates the role that the new replica will initially perform: Primary or Secondary.

Create a Client Access Point

An access point is a name and associated IP address information.  For additional information on Client Access Points in a Failover Cluster see also Understanding Access Points (Names and IP Addresses) in a Failover.  The Client Access Point will be used when configuring SharePoint 2010.

  1. Click Start | Administrative Tools, and then click Failover Cluster Manager.
  2. Expand the cluster.
  3. Expand Services and Applications, and select the name of the Availability Group created in the previous steps.
  4. Note that the resource group, AG1, has the same name as the availability group.
  5. In the Actions pane click Add a resource and select 1 – Client Access Point.
  6. In the Client Access Point dialog specify a name for the network name, and then click Next.
  7. In the Confirmation dialog box, click Next.
  8. In the Summary dialog box, click Finish.
  9. In the Summary of AG1 navigation pane, right-click AG1 under Other Resources, and then click Take this resource offline.
  10. In the Please confirm action dialog box, click Take AG1 offline.
  11. Right-click AG1 and then click Properties.
  12. In the AG1 Properties dialog box, click the Dependencies tab.
  13. Click Insert, and then click the drop-down box under the Resource column.
  14. In the drop-down list, select the network name, and then click OK.
  15. In the Summary of AG1 navigation pane, right-click AG1, and then click Bring this resource online.

Configure SharePoint Server 2010

Start the SharePoint 2010 Products Configuration Wizard.

Create a new server farm specifying the name of the Client Access Point as the name of the database sever.

Add Databases to the Availability Group

  1. In Object Explorer, connect to the server instance that hosts the primary replica of the availability group, and expand the server tree.
  2. Expand the Management node, the AlwaysOn High Availability node, and the Availability Groups node.
  3. Right-click the availability group to which you are adding a database, and select the Add Database command. This command launches the Add Database to Availability Group Wizard.
  4. On the Select Databases page, select one or more databases.
  5. On the Select Initial Data Synchronization page, choose how you want your new secondary databases to be created and joined to the availability group. Choose one of the following options:
  6. · Full
  7. In the Specify a shared network location accessible by all replicas: field, specify a backup share to which all of the server instance that host replicas have read-write access.
  8. On the Connect to Existing Secondary Replicas page, Information_still_to_come.
  9. The Validation page verifies whether the values you specified in this Wizard meet the requirements of the New Availability Group Wizard. If the validation changes, you can click Previous to return to an earlier wizard page to change one or more values. The click Next to return to the Validation page, and click Re-run Validation.
  10. On the Summary page, review your choices for the new availability group. To make a change, click Previous to return to the relevant page. After making the change, click Next to return to the Summary page.
  11. If you are satisfied with your selections, optionally click Script to create a script of the steps the wizard will execute. Then, to create and configure the new availability group, click Finish.
  12. The Progress page displays the progress of the steps for creating the availability group (configuring endpoints, creating the availability group, and joining the secondary replica to the group).
  13. When these steps complete, the Results page displays the result of each step. If all these steps succeed, the new availability group is completely configured. If any of the steps result in an error, you might need to manually complete the configuration. For information about the cause of a given error, click the associated “Error” link in the Result column.
  14. When the wizard completes, click Close to exit.

Once all databases have been added to one or more Availability Groups the configuration is complete.

NOTE

SharePoint 2010 is not currently supported on SQL Server Code Name “Denali”.

Standard
Administration, SharePoint

SharePoint 2010 and Windows Firewall with Advanced Security

I’ve recently noticed a number of posts on social.msdn.com related to configuring SharePoint 2010 with Windows Firewall with Advanced Security. The following post provides the basic steps necessary to get started with provisioning a SharePoint 2010 server farm in environments where the Windows Firewall is enabled.

To access an instance of the SQL Server through a firewall, you must configure the firewall on the computer that is running SQL Server to allow access.

Step 1 Create an Inbound Rule for SQL Server Database Engine

Create a new Inbound rule for the SQL Server Database Engine. In default installations this port is TCP 1433.

Using Windows Firewall with Advanced Security Microsoft Management Console

To create a new Inbound rule open Windows Firewall with Advanced Security by clicking Start, Run…, and then enter WF.msc in the Run dialog and click OK.

On the Windows Firewall with Advanced Security Microsoft Management Console window, select Inbound Rules, and then select New Rule… from the Action Pane.

On the New Inbound Rule Wizard on the Rule Type dialog from the list of available options select Port, and then click Next >.

On the Protocol and Ports dialog from the list of available options select TCP, enter 1433 in the Select local ports: input box, and then click Next >.

On the Action dialog from the list of available options select Allow the connection, and then click Next >.

On the Profile dialog from the list of available options select Domain, Private, and Public, and then click Next >.

On the Name dialog enter SQL Server Database Engine in the Name: input box, and optionally enter a description in the Description (optional): input box, and then click Finish.

Suggested text for the Description (optional): input box:

The Database Engine is the core service for storing, processing, and securing data. The Database Engine provides controlled access and rapid transaction processing to meet the requirements of the most demanding data consuming applications within your enterprise.

Using Netsh Commands

Open a Command Prompt by clicking Start, Run…, and then enter cmd in the Run dialog and click OK.

Enter netsh advfirewall firewall add rule name = “SQL Server Database Engine” description = “The Database Engine is the core service for storing, processing, and securing data. The Database Engine provides controlled access and rapid transaction processing to meet the requirements of the most demanding data consuming applications within your enterprise.” dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = ALL in the Command Prompt and press Enter.

Step 2 Create an Inbound Rule for SQL Server Browser Service

Create a new Inbound rule for the SQL Server Browser Service. In default installations this port is UDP 1434.

Using Windows Firewall with Advanced Security Microsoft Management Console

To create a new Inbound rule open Windows Firewall with Advanced Security by clicking Start, Run…, and then enter WF.msc in the Run dialog and click OK.

On the Windows Firewall with Advanced Security Microsoft Management Console window, select Inbound Rules, and then select New Rule… from the Action Pane.

On the New Inbound Rule Wizard on the Rule Type dialog from the list of available options select Port, and then click Next >.

On the Protocol and Ports dialog from the list of available options select UDP, enter 1434 in the Select local ports: input box, and then click Next >.

On the Action dialog from the list of available options select Allow the connection, and then click Next >.

On the Profile dialog from the list of available options select Domain, Private, and Public, and then click Next >.

On the Name dialog enter SQL Server Browser Service in the Name: input box, and optionally enter a description in the Description (optional): input box, and then click Finish.

Suggested text for the Description (optional): input box:

The SQL Server Browser program runs as a Windows service. SQL Server Browser listens for incoming requests for Microsoft SQL Server resources and provides information about SQL Server instances installed on the computer.

Using Netsh Commands

Open a Command Prompt by clicking Start, Run…, and then enter cmd in the Run dialog and click OK.

Enter netsh advfirewall firewall add rule name = “SQL Server Browser Service” description = “The SQL Server Browser program runs as a Windows service. SQL Server Browser listens for incoming requests for Microsoft SQL Server resources and provides information about SQL Server instances installed on the computer.” dir = in protocol = udp action = allow localport = 1434 remoteip = localsubnet profile = ALL in the Command Prompt and press Enter.

Step 3 Enable Named Pipes on the SQL Server Instance

Enabling Named Pipes will allow the provisioning of a new server farm using the SharePoint 2010 Products and Configuration Wizard. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients and is used to provide communication between processes on the same computer or between processes on different computers across a network.

Open SQL Server Configuration Manager by clicking Start, All Programs, Microsoft SQL Server 2008 (or Microsoft SQL Server 2008 R2), Configuration Tools, SQL Server Configuration Manager.

Select Protocols for MSSQLSERVER under SQL Server 2008 Network Configuration.

Right-click Named Pipes and select Enable from the list of available options.

Restart the MSSQLSERVER service to commit the change.

Open a Command Prompt by clicking Start, Run…, and then enter cmd in the Run dialog and click OK.

Enter net stop mssqlserver in the Command Prompt and press Enter.

Enter net start mssqlserver in the Command Prompt and press Enter.

To enable Named Pipes using Windows PowerShell see also http://msdn.microsoft.com/en-us/library/dd206997.aspx.

Step 4 Create new Inbound Rules for Optional Services

For additional services, such as Analysis Services, see also http://msdn.microsoft.com/en-us/library/cc646023.aspx.

To learn more about Windows Firewall with Advanced Security see also http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=19192.

Step 5 Export and Reuse the Firewall Policy

To configure additional SQL Server database servers you can export the rule set configured on the initial SQL Server and apply that set to any additional SQL Server database servers to be configured.

To export a firewall policy you can use the Windows Firewall with Advanced Security Microsoft Management Console or Netsh commands.

Using Windows Firewall with Advanced Security Management Console

Open Windows Firewall with Advanced Security by clicking Start, Run…, and then enter WF.msc in the Run dialog and click OK.

On the Windows Firewall with Advanced Security Microsoft Management Console window, select Export Policy… from the Action Pane.

On the Save As dialog specify a location to save the policy file and file name.

On the Windows Firewall with Advanced Security Microsoft Management Console window, select Import Policy… from the Action Pane.

On the Windows Firewall with Advanced Security prompt click Yes to import a policy.

NOTE

Importing a policy will overwrite the current Windows Firewall with Advanced Security policy.

On the Open dialog, browse to the location of the policy file and click Open.

Using Netsh Commands

Open a Command Prompt by clicking Start, Run…, and then enter cmd in the Run dialog and click OK.

Enter netsh in the Command Prompt and press Enter.

In the netsh context enter advfirewall in the Command Prompt and press Enter.

To export the current firewall policy enter netsh advfirewall export “C:Users<user>DocumentsPolicy.wfw.

To import the firewall policy enter netsh advfirewall import “C:Users<user>DocumentsPolicy.wfw”.

Running the SharePoint 2010 Products Configuration Wizard should now enable the provisioning of a new server farm.

Standard
SharePoint

Site Recycle Bin (Service Pack 1 and CodePlex) FAQs

Do I need to uninstall the Site Recycle Bin from CodePlex if I plan to use the Site Recycle Bin in Service Pack 1?

It depends on what you’re looking for.  The Site Recycle Bin available through CodePlex will capture deleted Site Collections and Sites to disk, Site Recycle Bin in Service Pack 1 copies the Site Collections and Sites to an auxiliary SQL table until they are permanently deleted at which point are managed by Gradual Site Deletion.  Once a Site Collection or site enters this Garbage Collection phase it will be managed by the Site Recycle Bin on CodePlex and copied to disk.  In theory you could have both.  The CodePlex Site Recycle Bin to provide archival and the Site Recycle Bin in Service Pack 1 to provide quick recovery and enable Site Collection administrators to perform self-service restores.

What happens to deleted Site Collections?  Do they ever get deleted?

These objects are purged.

There already is Web application property that controls the retention period for the Site Collection level Recycle Bin.  The same property is used for the deleted Site Collections themselves; when the Site Collection was deleted prior to a specified period (30 days), the timer job permanently removes it from the Content Database.  A Site Collection in the process of being permanently removed can no longer be restored.

Standard
Administration, SharePoint

Service Pack 1 Move-SPSite w/ ‘shallow copy’

Service Pack 1 introduces a new method of moving Site Collections between Content Databases where RBS is used known as ‘shallow copy’.

Overview

What is ‘shallow copy’?

‘Shallow copy’ refers to moving structured content without moving the underlying unstructured content.  With SharePoint 2010 Products ‘shallow copy’ moves the structured Site Collection data across Content Databases without moving the unstructured data which is comprised of user created content such as PowerPoint Presentations, Word Documents, etc.

What is a ‘shallow copy’ migration?

‘Shallow copy’ migration refers to a migration technique in which structured Site Collection data is moved across Content Databases while the unstructured BLOB data remains untouched in its originally configured BLOB store.

What is a deep copy migration?

Deep copy refers to a migration technique is which unstructured BLOB data is passed through the Object Model when its associated Site Collection is moved across Content Databases, I.e. download and upload of BLOB data.

Benefits

‘Shallow copy’ capabilities provide a number of benefits, for example, shallow copy migration enables seamless movement of Site Collections across Content Databases while improving performance through enabling the unstructured data to remain in the originally configured BLOB store.  In scenarios where the same RBS provider is configured in both the source and destination Content Database the structured Site Collection data is moved without copying the underlying BLOB data – transferring only the ownership information between Content Databases.

In many SharePoint 2010 Products deployments unstructured BLOB data comprises 80% or more of the total content, ‘shallow copy’ helps administrators avoid deep copy migration significantly reducing the time required to move Site Collections between Content Databases.

Prerequisites

The following prerequisites are required to implement ‘shallow copy’ migrations.

SQL Server 2008 R2 Public Cumulative Update
SharePoint Server 2010 Service Pack 1

Administrators can leverage ‘shallow copy’ functionality in Service Pack 1 through both the Object Model and Windows PowerShell using the Move-SPSite Windows PowerShell CmdLet with the -RbsProviderMapping parameter.  The -RbsProviderMapping parameter defines the mapping between the RBS providers in the source and destination Content Databases.

Move-SPSite -Identity siteUrl -DestinationDatabase databaseName -RbsProviderMapping
    @{"sourceProvider1"="targetProvider1", "sourceProvider2"="targetProvider2"}

When using the -RbsProvideMapping parameter the ownership of the RBS pool (subset of the BLOB store documents) used by the specified Site Collection is transferred from the source to the destination Content Database without moving the underlying unstructured data associated with that Site Collection.

‘Shallow copy’ is also an efficient migration method when moving from EBS to RBS.  In an EBS to RBS scenario the EBS token is moved from the source to the destination Content Database.

For additional information on Remote BLOB Store Architecture see http://msdn.microsoft.com/en-us/library/gg316769.aspx.

For additional information on the Move-SPSite CmdLet see http://technet.microsoft.com/en-us/library/ff607915.aspx.

Standard
Administration, SharePoint

Now Serving Larger Databases…

Today we are announcing some important and exciting changes to our software boundaries and limits for SharePoint 2010 Products, in summary SharePoint 2010 Products will now support content databases up to 4TB.  However, prior to considering multi-terabyte databases you should thoroughly review the following whitepapers:

Managing multi-terabyte databases with SharePoint 2010 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26700)

Abstract

Managing large content databases with SharePoint 2010 requires careful planning and consideration to include capacity management, performance, and data protection.  This whitepaper provides guidance to support these considerations to include additional resources to support this guidance.

Database Maintenance for SharePoint 2010 Products (http://www.microsoft.com/download/en/details.aspx?id=24282)

Abstract

This white paper provides information and guidelines for maintaining the databases that host Microsoft® SharePoint® 2010 data and configurations. It describes and provides examples of the database maintenance tasks that we recommend when using SharePoint 2010.

Before you implement any database maintenance tasks or modify your SharePoint 2010 databases, read the following support article: Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=110812&clcid=0x409).

To learn more about this announcement see the SharePoint Team Blog at http://sharepoint.microsoft.com/blog.

To learn more about the new software boundaries and limits see SharePoint Server 2010 capacity management: Software boundaries and limits at http://technet.microsoft.com/en-us/library/cc262787.aspx.

Standard