As SharePoint 2013 continues to mature, the size of the update packages (both the security updates and the cumulative updates) continue to get larger.  In working my customers who are SharePoint Administrators, I am starting to get more and more questions regarding ways to optimize the SharePoint patching process and looking for opportunities to reduce the duration of the maintenance window required to apply SharePoint patches.  The guidance on this topic continues to evolve over time and what I present here is an approach that I have seen used by many customers to optimize their SharePoint patching operations.

Before we get too far into the meat of the guidance,  let’s first establish a bit of common knowledge.  Setting a knowledge foundation and set of common terms will not only help you to understand the guidance, but it will also make it possible to tweak and adjust this guidance based upon your own requirements and constraints.  Let’s start by taking a look at the types of updates that are available.

Type of Updates

Updates to SharePoint are made available to the public in three varieties.  The first one is the security update (also known as a PU or Public Update), the second one is the cumulative update (also known as a CU), and the third one is the Service Pack (SP).

Public Updates

Public updates are released via the Microsoft Download site as well as the windows update process.  Released as frequently as once a month, public updates typically contain security updates or minor fixes to a specific SharePoint component (such as a specific .dll) and will only include those updated components that are affected by the specific change.  Public updates are cumulative for the components that are included (i.e they will have the latest versions of each component in the update package) but they are not inclusive.  “Not inclusive” means the other components of the system that were not updated by the specific change will NOT be included in the update package. 

Cumulative Updates

Cumulative updates are also released via the Microsoft download site but are not published to windows update.   They are released as frequently as once a month, and come in two flavors.  One flavor includes all components (in all languages) in a given “grouping” of components. A “grouping” typically includes all the components for a given “subsystem” with SharePoint such as search or OfficeFile formats, etc. and are usually contained within a single .msi package.  The other flavor, called “server” or “uber” packages, includes updates to all components (in all languages) for all “groupings” of components.  A “server package” is truly cumulative and all inclusive.  Installing the latest “Cumulative Update Server Package” will ensure that all components of the entire SharePoint products is current  for all installed languages.  It is this cumulative and all-inclusive aspect of server packages that accounts for their large size (the latest server package CU tops 1.4 GB in size).  An important thing to note about CU updates is that they include all fixes that have been released to the point in time in which they are compiled and built.   This means that the May 2016 Cumulative update will include everything that was in the April cumulative updates as well as any security updates that may been released prior to compilation and packaging of the update release.

Service Packs

Service Packs are yet another update release mechanism that are made available only via the Microsoft download site.  Like cumulative updates, service packs include the latest version of all components available at the time of compilation and packaging.  However, unlike, cumulative updates, service packs contain only the components for a single language.  This means that if you have installed multiple languages packs, you will need to download and install the service pack release for each required language pack.  (This is not true for CUs – as stated above, each CU contains all components in all languages). 

For more information about SharePoint patches, see https://blogs.technet.microsoft.com/stefan_gossner/2014/08/18/sharepoint-patching-demystified/

Overview of the Update Deployment Process

Now that we have a good background on the type of patches, let’s take a closer look at the patch deployment process.  The deployment process is comprised of two keys phases:  Patching phase and “Build-To-Build” (B2B) upgrade phase.

Patch Phase

The patch phase is comprised of two steps:  the patch deployment step and the binary deployment step.  During the patch deployment step, the windows installer patches are extracted from the downloaded cab files and placed in temporary storage in preparation for deployment.   The windows installer patches are then merged with the existing installed images to produce the target components that actually get deployed.  Once step one is complete, step two begins.  During step two (“binary deployment”), the SharePoint services that are being patched are temporarily stopped so that the new binaries (executables and dynamic link libraries) can be copied to the appropriate locations (Remember that for Cumulative Updates, all components are upgraded so therefore all processes get stopped).  Running services are stopped before the components are replaced in order to prevent a restart of the server.  However, in some circumstances a restart will still be required.

The patch phase MUST be completed on every server in the farm and failure to do will render the farm in an inconsistent state.  Once the patch phase has been completed and before the “upgrade” phase has started, the farm is in a state called “compatibility mode”.  The farm will remain in this state until the upgrade phase is successfully completed.  You can safely leave your farm in this state for a short period of time but should try to complete the upgrade phase as soon as possible.  Furthermore, when you are in “compatibility mode” it is suggested that you not apply any additional updates until you complete the “upgrade” phase.

Optimizing the Patch Phase

As we know, SharePoint is a complex system and is comprised of many, many services.   As a result, the process of shutting down services and updating dependencies can take a long time.  There are a number of recommendations in the forms of blogs and other online publications that provide ways to optimize the patching process.   The most common one is found at https://blogs.msdn.com/b/russmax/archive/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install.aspx.  I have worked with many customers that have successfully used the provided scripts to significantly reduce the time it takes to complete the patching phase.

“Build-to-Build” Upgrade Phase

Once the patching phase is complete, the “build-to-build” upgrade phase must be started.   The “build-to-build” upgrade (also known an b2b) is typically completed by running the SharePoint Configuration Wizard (psconfigui.exe) but can also be initiated by running the command-line utility psconfig.exe.  During this phase, the SharePoint objects in the configuration database are updated,  the SharePoint services and their databases are upgraded, and finally the SharePoint content databases are enumerated and upgraded. Depending on the type of schema changes present and the size of the content database, the content upgrade tasks can take a considerable amount of time to execute.  Furthermore, the SharePoint Configuration Wizard will upgrade content databases in a sequential manner.  Since the databases are shared across all servers in the farm, this database upgrade process takes the most amount of time on the first server.  However, the upgrade process must be completed on all servers in the farm in order for the farm to remain in a predictable and supported state.

More information about the update deployment process can be found in the TechNet Article entitled “Software updates overview for SharePoint 2013“.  Please go to https://technet.microsoft.com/EN-US/library/ff806329.aspx for more information.

Upgrade Strategies

The various TechNet articles (as well as general recommended best practices) tend to recommend one of two upgrade strategies: in-place and database attach.  Let’s look at each of these in a bit more detail.

In-place upgrade

For the in-place upgrade, the patch phase is executed on each server in the farm (typically starting with the Central Admin server) and then when that is complete, the SharePoint Configuration Wizard is then executed on each server (again typically this is done first on Central Admin server). 

In simplified form the process is:

1. Install patch on first server in Farm (typically CA)
2. If installing service pack, install additional SP language packs
3. Install patch on all other servers in the farm. (This can be done in parallel with Step #1)
4. If installing service pack, install additional SP language packs on all other servers
5. Run the SharePoint Configuration Wizard on first server in the farm (Typically CA) (This could take a very long time if content databases are large and patch includes schema changes)
6. Run the SharePoint Configuration Wizard on all other servers in the farm  (This should go faster on subsequent servers)

Some of the advantages of this approach is that it is the simplest approach and requires the least administrative effort.  Some of the disadvantages are that the upgrade operations are performed sequentially and there is no way to determine or change the order in which items are upgraded.  As a result of the sequential nature of this approach, it typically results in the longest maintenance window.

Database attach

For the database attach upgrade, all of the SharePoint content databases are detached from the farm before the patching and upgrade process is started.  Then the typical “in-place” process is executed.  Once that is complete on all servers in the farm, the SharePoint content databases are reattached to the farm. 

In simplified form the process is:

1. Install patch on first server in Farm (typically CA)
2. If installing service pack, install additional SP language packs
3. Install patch on all other servers in the farm. (This can be done in parallel with Step #1)
4. If installing service pack, install additional SP language packs on all other servers
5. Detach all content databases from the farm (Sometime this is performed as Step #1)
6. Run the SharePoint Configuration Wizard on first server in the farm (Typically CA)
7. Run the SharePoint Configuration Wizard on all other servers in the farm.
8. Attach all content databases to the farm via Central Admin or Attach-SPContentDatabase.   (The attach process can be done in parallel (multiple at once) and will automatically upgrade content databases to the current schema version) 

The primary advantages of this approach are that multiple database attach operations can be run at once and the order of reattachment can be controlled by the administrator (upgrade most critical or largest content databases first).  The primary disadvantage of this approach is that while detached, content is unavailable.  Furthermore, there is some risk in detaching content databases as there are some timer based processes that expect the content to be available and could result in unexpected results if those databases are detached while the timer processed run.

These strategies (and others) are documented in the TechNet Article at https://technet.microsoft.com/en-us/library/ff806338.aspx

In-place with Manual Database Upgrades

Over the years, working with many, many different customers, I have learned that neither of these approaches are ideal for all customers.  As a result, experience has taught us that alternative approaches should also be considered.  One such approach is to complete the patch phase on all servers then utilize the SharePoint Management Console and PowerShell to execute Upgrade-SPContentDatabase on all SharePoint content databases.  Depending on the capability of the SQL servers it is quite likely that multiple database upgrade sessions can be run in parallel. Once all content databases have been upgraded, the upgrade process can be completed by running the SharePoint Configuration Wizard to complete whatever upgrade tasks remain. 

1. Install patch on first server in Farm (typically CA)
2. If installing service pack, install additional SP language packs
3. Install patch on all other servers in the farm. (This can be done in parallel with Step #1)
4. If installing service pack, install additional SP language packs on all other servers 
5. Upgrade all content databases in the farm using Upgrade-SPContentDatabase.   (The upgrade process can be done in parallel (multiple at once) and will upgrade content databases to the current schema version)
6. Run the SharePoint Configuration Wizard on first server in the farm (Typically CA) (Since the content databases have already been upgraded, this should run relatively quick since just SPservice DBs need to be upgraded)
7. Run the SharePoint Configuration Wizard on all other servers in the farm.

One disadvantage of this approach is that additional administrative involvement is required and it could put more strain on the database infrastructure.  However, one big advantage is that the content remains available through most of the upgrade process (Sites in a given content DB may be unavailable or slow while Upgrade-SPContentDatabase is being run against that database).  This is also likely to result in the shortest maintenance window as multiple content database(s) can likely be upgraded simultaneously.

Hope you find this information useful!

It Begins with a question

In this blog post, I am presenting a question that I recently received from a customer.   The question was:  What steps need to be taken to move the database utilized by the Usage and Health Data Collection Usage Service Application (referred to as the WSS_Logging DB) to a different database server.  Furthermore, the steps need to minimize server downtime and ensure that no historical and current usage data is lost.

The question seems simple enough and something that I initially thought would be well documented in the SharePoint product documentation found in the online TechNet libraries.   However, it turns out the question is not as straight forward as first thought. 

Let the Research Begin

As with most questions like this, the first step is some quick internet searching.  An internet search query (Bing of course, what else?) led me to the following article:

Move service application databases (SharePoint 2013)

https://TechNet.microsoft.com/en-us/library/jj729805.aspx

This article is a great start and appears to provide me all I need to move any of the SharePoint Service Application databases to a new server or instance.  There is a specific article for the Usage and Health Data Collection Service application linked here:

Move the Usage and Health Data Collection service application databases in SharePoint 2013

https://technet.microsoft.com/en-us/library/jj729804.aspx

Awesome.  This article seems like it an exact match.  It should everything I need, right?   Well after reading closely, and then actually trying to implement the steps in a test lab, I realized that there are some areas of the article that are ambiguous and misleading.

Highly summarized, the guidance in the article is to perform the following steps:

1. Move the service application database

a. Stop the service application

b. Detach the database from SQL Server

c. Move database files to a new location

d. Attach the database to a new instance of SQL Server

2. Point the Usage and Health Data Collection service application to the moved database. 

The guidance under Step 1a “Stop the service application” contains a link to the following document:

Start or stop a service (SharePoint 2013)

https://technet.microsoft.com/en-us/library/ee704549.aspx

Whoa.  Hang on.   The guidance says to “Stop the service application” but the link references steps to “Stop a SharePoint Service”.  A Service Application and a SharePoint Service are two distinctly different things so what gives?  After digging a little deeper, I think the wording in the guidance should say “Stop the Service”. rather than “Stop the Service Application” 

Okay great, stop the SharePoint service that corresponds to the “Usage and Health Data Collection Service Application”, but what service is that exactly?  Unlike many of the other service applications which have clearly defined SharePoint services, the Usage Application does not.

Some Background about the Usage and Health Data Collection Service Application

To better understand what needs to be done to complete the move, it is helpful to take a step back and remind ourselves what the Usage and Health Data Collection is and does.  This service application provides a set of data collectors that, when enabled, collect and aggregate useful information about the health of the SharePoint components of the farm and how they are being used.  These collectors are implemented as timer jobs, and there are collectors for a variety of things, including server event logs, SharePoint diagnostics logs, SharePoint feature usage data, and server performance counter logs.  All of this data is stored in a single database (the Usage or Logging DB) and is specific to this particular farm.  Many of these data collectors are disabled by default but can be enabled by the administrators to collect this data as desired.   Due to the potentially large volume of data that can be collected, the system is designed such that it retains only the last 14 days of data and old data is automatically purged,  This results is a “rolling window” of the last 14 days (by default)..  Because this database can be very active and grow to be very large, it is considered a recommended best practice to place this database on its own SQL server if possible.  See the below link for more information about database sizes:

Database types and descriptions (SharePoint 2013)

https://technet.microsoft.com/en-us/library/cc678868.aspx

This database is primarily intended for reporting and manual querying purposes. However, there are a few reports from the Search Service Application that rely on data in this database.

Validation in the Lab

After completing my research and validating these steps in a lab, I have slightly modified the steps provided in the TechNet article below:

1. Perform a complete SQL backup of the Usage and Logging database

2. Stop and disable the timer service

a. Stop and disable the SharePoint Timer Service on all servers in the farm

This can be done via the Service control panel or by running the following command from an elevated command prompt: sc config sptimerv4 start= disabled sc stop sptimerv4 Note: the “space” following start= is required and is not a formatting anomaly

 

3. Move the service application database 

a. Verify the account that is the DBOwner of the WSS_Logging database

b. Make sure that the new instance of SQL server has a login configured for the DBOwner from step #3a.

c. Detach the database from SQL Server

c. Move or copy database files to the new instance of SQL Server

d Attach the database to a new instance of SQL Server specifying account captures in step #3a as the Database Owner 

4.  Configure the Usage and Health Data Collection Service Application

a. Point the Usage application to the new Database

From an elevated SharePoint Management Console, run the following PowerShell command: Get-SPUsageApplication | Set-SPUsageApplication -DatabaseName "<DbName>" -DatabaseServer "<SQLServerName>"

5. Restart the Timer service

a. Re-enable and start the SharePoint Timer Service on all servers in the farm.

This can be done via the Service control panel or by running the following command from an elevated command prompt: sc config sptimerv4 start= auto sc start sptimerv4 Note: the “space” following start= is required is a not a formatting anomaly

b. Re-boot all servers in the farm

Hope you find this information helpful!

Customer Question

“As we continue to grow our SharePoint footprint within our organization, we need to expand our standards and patterns in a couple of specific areas.  One thing that we need to be able to document and articulate clearly is when should we consider creating a new web application versus just a new site collection?   And when creating a new Web App, should we use a new App Pool or reuse an existing app pool?”

What is a SharePoint Web Application?

In order to answer this question, we need to take a look at what is a SharePoint Web Application.  MSDN defines a SharePoint Web application as the following (see https://msdn.microsoft.com/en-us/library/office/ee556558(v=office.14).aspx)

Clearly, in this case, it is definition one that is most relevant in this context.  The SP Object model defines the SPWebApplication class (which is used to programmatically represent a SharePoint Web Application) as the following (see https://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.administration.spwebapplication(v=office.15).aspx)

The key to really understanding the concept of a  web application comes by looking at the various properties of the SPWebApplication class.  Some of the key properties of this class include:

• ApplicationPool - represents the application pool used by the web application
• AlternateURLS - Collection of URLS (AAMs) that are routed to this web application
• Blocked File Extensions – List of extensions that cannot be uploaded or downloaded from sites within the web application
• Content Databases - Collection of content database attached to this web application
• Features - Collection of web-application scoped features activated for this web app
• IisSettings - Collections of settings for all IIS instances that belong to this web application
• Job Definitions  - Collection of timer job definitions for this web application
• MaximumFileSize  - The size in MB of the largest file that can uploaded to site collections within this web application
• Service Application Proxy Group  - Group of Service applications that are available to this Web Application
• Throttle Settings - Things like MaxItemsPerThrottledOperation, MaxQueryLookupFields, and other throttling settings
• Security Policies – Collection of security policies that are defined within this web application
• Rights/Permissions Set - Rights mask defining what permissions can be assigned within this web application

When Should I use a New Web Application?

So, when considering the question of when to use a new Web Application versus a new site collection, you need to consider some of the key settings that are configured at the web application level such a authentication providers, Security policies, blocked file list, maximum file size, service applications consumed, etc. Here are some examples

1.) You have an existing web application that contains collaboration sites for groups within your company.  This web site is configured to use Windows Claims authentication.  However, you have a request for an externally accessible site where users will access the site via forms based authentication

In this situation, you would need to use a new web application, since you need to support a different authentication method.

2.) You have an existing web application that contains your company’s collaboration sites.  The Marketing department wants to add a site that contains materials to be used for mandatory company training.  Some of the files contained within these materials are quite larges (videos, large pdfs and some Virtual hard disks)

In this situation, you would probably want to use a new web application and increase the maxFileUpload size for just this new web application.  Furthermore, using a new web app forces the use of a separate content database to hold these larger files.  This allows for unique backup and maintenance operations if needed.  You could go with using the existing web application and use a separate content database for just this site collection but increasing maxFileUpload for the entire collaboration web application could allow users to upload large documents to the collaboration sites (resulting in bloat) if quotas are not being used.

3.) You have an existing web application that is hosting your company’s collaboration sites.  The HR department wants to create a new site used to track employee reviews.  Due to the highly confidential nature of the data, this site needs to have very specific security policies defined.

In this scenario, a new web application, may be the best way to go because it allows for the creation of very specific security profiles and gives the ability to restrict user permissions that you wouldn’t want to apply to the collaboration sites.  Using a separate web application with it’s own app pool also provides an additional layer of process isolation.

4.) You have an existing web application that is hosting your team site content at https://teams.contoso.net.  A manager from the Operations department wants to create a site create a new site with a specific “vanity” url such as https://operations.contoso.net.

In the scenario it may be that a host-name site collection would be sufficient.  This scenario may not require a new web application

5.) You have an existing web application that is hosting your team site content at https://teams.contoso.net.  A manager from the Operations department wants to create a site create a new site with a specific “vanity” URL but they need it to be SSL (such as https://operations.contoso.net.)

Since the existing site is running http and the user specifically needs SSL, in this scenario you will need to create a new web application.

What About App Pools?

In addition to determining whether a new web app is desired or not, another important consideration is whether a new app pool should be created or if an existing app pool should be reused.  This question is even more subjective than the previous one.  For application pools, there are really 2 primary considerations:  1.) Scale and 2.) Isolation

For each application pool that you create, IIS will create a new worker process (w3wp.exe) to host that application pool.  Each instance of a worker process consumes a lot of memory resources, so more application pools means more memory consumption.  However, more app pool yields greater isolation.  If multiple web applications are sharing a single application pool, all of those web application are running inside the same worker process.  This means that recycling the worker process will affect all of the sites hosted in those web applications.  Furthermore, if one of those sites is running custom code that crashes and or leaks memory, all other web applications using that application pool  will also be affected.

So when should I use a new application pool versus using an existing one?  You would use an new app pool in the following situations:

• You have adequate available server memory and need to provide isolation from other applications
• The app pool is running code that is unstable and crashes or has serious memory leaks
• The app pool is hosting data that is sensitive and requires higher isolation.
• The application is mission critical and needs to have a different recycle schedule than the others. 

You would use a shared app pool in the following situation:

• You have limited available server memory
• You Are using the same “stable” code customizations across many different web applications  (those customization take memory, more efficient if they can be shared). 

SharePoint currently limits  the number of applications pools that a given server can support to 10 (see https://technet.microsoft.com/en-us/library/cc262787(v=office.14).aspx#WebApplication) so that needs to be a part of the consideration as well..

What Do You Think?

Many of the common scenarios are covered in this post but what about you?  What have you seen and what are some of the guidelines and criteria that you consider as you are faced with these types of administrative requests?  Please share you thoughts here for the benefit of all.

Note:   This article focuses on the capabilities of SharePoint that are available in the product (both when running on-premises and in the cloud).  However, additional advantages can be achieved when choosing a cloud deployment over an on-premises deployment and vice versa.  This article does not discuss the topic of cloud versus on-premises but rather focuses on capabilities available in the product in general.

Why SharePoint 2013?

If I were trying to make a case for SharePoint 2013 to my users, I would focus on those features that will have the most impact on their productivity and day to activities.  That might be features that enable them to do things they couldn’t before or features that allow them to do things faster and more efficiently than they could before.  There a lot of features in SharePoint 2013 but here are some of the key areas of innovation that could have a huge benefit for the end user.

• Better support for Mobile Devices

https://technet.microsoft.com/en-us/library/fp161352(v=office.15).aspx

• Social Computing

https://technet.microsoft.com/en-us/library/jj219766(v=office.15).aspx

• Better Performance

https://technet.microsoft.com/en-us/library/cc262971(v=office.15).aspx 

• Improvements in High Availability and Disaster Recovery

https://technet.microsoft.com/en-us/library/cc263031(v=office.15).aspx 

• Improvements in eDiscovery

https://technet.microsoft.com/en-us/library/fp161513(v=office.15).aspx

• Improvements is Business Intelligence

https://technet.microsoft.com/en-us/library/jj542395(v=office.15).aspx

• Improvements in Workflow

https://technet.microsoft.com/en-us/library/jj219638(v=office.15).aspx

• Improvements in Search

https://technet.microsoft.com/en-us/library/ee667266(v=office.15).aspx

• Improvements in Web Content Management

https://technet.microsoft.com/en-us/library/jj219688(v=office.15).aspx

Case Studies

In addition to looking at the newest features, I would also try to demonstrate how the product has benefited similar customers.

Below are a few of the published case studies for SharePoint 2013

• Cambridgeshire Constabulary

https://technet.microsoft.com/en-us/library/dn479049(v=office.15).aspx

• Mavention and web content management in SharePoint Server

https://technet.microsoft.com/en-us/library/jj822912(v=office.15).aspx

• United Airlines and SharePoint Server 2013

https://technet.microsoft.com/en-us/library/dn423227(v=office.15).aspx

Additional case studies can be found at the Microsoft Case Study search site https://www.microsoft.com/casestudies

More Information

More information about SharePoint 2013 and the new capabilities that it provides can be found at https://technet.microsoft.com/en-us/library/cc303422(v=office.15).aspx

In this post I will define key terms and concepts and then provide a list of questions that can be used to help facilitate conversations around Business Continuity Planning.

Business Continuity

Business Continuity refers to the activity performed by an organization to ensure that critical business functions will be available to entities that require access to those functions. Typically, business continuity planning for SharePoint environments include architecting solutions for High Availability, planning for Disaster Recovery and conducting normal day-to-day operations such as applying software patches and taking backups.

For more information on business continuity management and SharePoint, please see https://technet.microsoft.com/en-us/library/jj715263.aspx

High Availability (HA)

High-Availability is typically defined in terms of the end user's ability to access the system during designated times and perform expected business functions. As a result, the goal of High Availability planning is usually to minimize or eliminate system downtime.

In the case of SharePoint, the following descriptions usually apply to High Availability (HA):

• There could be a single data center or multiple (close proximity) data centers
• If multi-data center, High network bandwidth (1 GB/s) and low network latency (<1 ms) required.  (See https://technet.microsoft.com/en-us/library/cc262485.aspx for more details about these requirements).
• Utilizes a single Configuration database (meaning single SharePoint Farm)
• Leverages Automatic failover (no user intervention required)
• Typically consists of SQL Clusters and load balanced application servers
• Depends on database and/or storage technologies to synchronize data between servers in near real-time
• Provides protection from Failure of DB server and Application (SP) servers
• There is a defined goal for desired uptime (3, 4 or 5 9's)
• There is an attempt to eliminate single points of failure via redundancy (Hardware, power supply, network, etc.).

For more information about SharePoint High Availability see https://technet.microsoft.com/en-us/library/jj715263.aspx

Disaster Recovery (DR)

Disaster Recovery Planning typically focuses on recovering from a planned or unplanned outage. It entails defining detailed operational processes to be followed to ensure that recovery is possible and documents business requirements around recovery. Such requirements typically include but are not limited to RTO (Recovery Time Objective) and RPO (Recovery Point Objective). Most Disaster Recovery plans cover the scenario of a complete loss of the primary data center and as such often include a secondary data center located some distance apart from the primary data center.

In the case of SharePoint, the following descriptions usually apply to Disaster Recovery (DR):

• Servers are located in different data centers, often far apart
• Consists of separate configuration database in the secondary data center (Separate SharePoint Farm)
• There is a defined Recovery Time Objective (RTO)
• Time frame after a disaster in which the recovered business functionality should be available (i.e. service downtime after event)
• Typically described in hours
• RTO requirements typically dictate the DR Approach (Hot versus warm versus cold)
• For SharePoint getting the data to the secondary data center is often the longest time component of the recovery process
• There is a defined Recovery Point Objective (RPO)
• Specifies time frame of allowable data loss after recovery from event
• Usually specified in hours
• RPO requirements typically dictate data backup/synchronization approach and schedule 
• Facilities of Secondary Farm may have various degrees of availability during normal operations (cold, warm, hot)
• May be invoked via a planned or unplanned failover.
• Failover is often a manual, deliberate event.

For more information about SharePoint Disaster Recovery Planning see https://technet.microsoft.com/en-us/library/ff628971.aspx

Now that some common terminology and SharePoint specific characteristics have been established, it is time to list some of the important questions that should be answered as part of any Business Continuity Planning exercise.

Questions For Business Continuity Discussions

These discussion question are broken down into five categories of questions:   Business Requirements, Infrastructure Inventory, Operational Practices, Asset Prioritization, and Service Prioritization

Business Requirements

The following business requirements should be defined and documented as part of the Business Continuity Planning Process

Uptime

1. What are the business needs around uptime?
2. What are considered normal business hours for your organization?
3. Does your organization differentiate between planned downtime and unplanned downtime?
4. Do you have regular maintenance windows? If so, how long are they? How often do they occur?
5. Do you proactively measure and report application uptime?

Disaster Recovery

1. Do you have a desired/defined RTO for major extended outage?
2. Do you have a desired/defined RPO for major extended outage?
3. Do you perform disaster recovery tests?  If so, how often?
4. Do you have a disaster recovery site? Where is it located compared to the primary site?

Infrastructure Inventory

The following questions help define and document the physical infrastructure that will be utilized for business continuity discussions.

Computing Resources

1. Are you running with physical or virtual servers?  If virtual, what platform is being used?
2. Do you have a process in place to manage growth and prevent over subscription?

Storage

1. What storage infrastructure/vendor are you using?
2. Is the same storage infrastructure used at both the primary and secondary data center?
3. Does the storage infrastructure provide replication mechanisms to different data centers?
4. What maximum IOPS capacity can the storage infrastructure provide?  Have you measured this?  If so how?

Network

1. What is the bandwidth and latency between data centers?
2. What other applications are utilizing the network connection?
3. Are WAN accelerators in use between data canters? If so, what kind?

Database

1. Do you take regular database backups? What is the backup schedule?
2. Do you use DB Log Shipping?
3. Do you use DB Mirroring? If so, Synchronous or Asynchronous?
4. How large are your SP databases?

Operational Practices

The following questions, help define and document that operational aspects of running a SharePoint environment

Patching

1. Do you take planned downtime to patch?  If not, how do you achieve that?
2. Do you run with limited capacity while patching? Read-only?
3. Do you use a planned failover to DR to eliminate downtime during patching?
4. What is your patching cadence? How frequently do you patch?

Backups

1. Do you take regular backups? If so, What kind? What types of tools are used?
2. Do you ever test restores?
3. Do you take SharePoint Farm backups? What about Site Collections Backups?
4. Where are backups files stored and how are the archived?
5. Is there an off-site back-up facility in place in case of total data center loss?

Asset Prioritization

Asset prioritization and inventory is an important part of the Business Continuity Planning process.  Identifying what business assets are most critical, where they are stored and what priority they should have from a high availability and/or disaster recovery perspective will help business entities devise an optimized business continuity plan.

SharePoint Asset Recovery

Since the focus here is about business continuity planning for SharePoint, these questions focus specifically on SharePoint assets but a complete business continuity plan should inventory all important information assets including those NOT stored in SharePoint.  (Note: Though intended for use in the upgrade process, the workbook at https://go.microsoft.com/fwlink/?LinkId=252097 can be used as a tool to assist in documenting the various SharePoint Assets).

1. How important is availability of each of the following assets after recovery from a disaster event? (Scale of 1 - 5 : 1 - not very important, 5 - very important)
• Documents
• List items
• Social data
• User/Profile Data
• Termsets/Taxonomy
• MySites
2. How quickly do you need access to each of the following assets after recovery from a disaster event? (1 -5 : 1 can probably wait a while, 5 need this right away)

• Documents
• List items
• Social data
• User/Profile Data
• Termsets/Taxonomy
• MySites
• Ability to locate artifacts via search

Service Prioritization

Again there are non SharePoint services that are going to need to be prioritized and inventoried but these questions just focus on SharePoint

SharePoint Service Prioritization

1. Which if the following services must be highly available? What level of availability is desired?
• Sites (Are there some sites that must be more available than others? If so which ones?)
• Content (Pages, documents and lists)
• Search Query
• TermSets and Taxonomy
• User Profiles
• Social Activity
• Excel Services
• SharePoint 2013 Apps
• Workflow
• Custom SharePoint Solutions (.wsps)
• Other?  If other, what?
2. How important is the availability of each of the following services after a disaster event? (Scale of 1 - 5 : 1 - not very important, 5 - very important)
• Sites (Are there some sites that must be more available than others? If so which ones?)
• Content (Pages, documents and lists)
• Search Query
• TermSets and Taxonomy
• User Profiles
• Social Activity
• Excel Services
• SharePoint 2013 Apps
• Workflow
• Custom SharePoint Solutions (.wsps)
• Other?  If other, what?
3. How quickly do you need access to the following services after a disaster event (1 -5 : 1 can probably wait a while, 5 need this right away)
• Sites (Are there some sites that must be more available than others? If so which ones?)
• Content (Pages, documents and lists)
• Search Query
• TermSets and Taxonomy
• User Profiles
• Social Activity
• Excel Services
• SharePoint 2013 Apps
• Workflow
• Custom SharePoint Solutions (.wsps)
• Other?  If other, what?

Credits

A big thanks goes out to some colleagues whose feedback and discussion around this topic have been greatly appreciated and helped to complete the picture in several areas!  Thanks Bob Fox (https://blogs.technet.com/b/sharepoint_foxhole/), Kirk Evans (https://blogs.msdn.com/b/kaevans/) and Cory Roberts.  It’s awesome working with you guys!

I hope you have found this information useful and as always I welcome comments, feedback, community insights and corrections!

# # # # #

Note:  The instructions provided are for SharePoint 2013 but these steps are valid and will also work for SharePoint 2010.

Question from Customer

Good Morning.  I wanted to touch base with you on an issue that we are experiencing in our environment.  What we have discovered is that we are having difficulty “renaming” SharePoint 2013 sites. 

Consider the scenario where we need to take an existing SharePoint 2013 Site and rename it.  There are various blogs posts out there that suggest using Copy-SPSite to perform this operation.  What we have found is that the operation appears to work.  However, due to some customizations that we have deployed, we receive the following error:

“Error loading navigation.  The Managed Navigation term set is improperly attached to the site: (Correlation ID: removed)”

Also, what about moving sites between Web Applications within the same environment or between environments (such as from Test into Prod).  In general, what is are the best practices around renaming site collections and moving them from farm to farm?

Response to Customer

First of all, the Copy-SPSite commandlet is a upgrade and migration command that is intended to be used to make a copy of a site collection with its content being written into a user specified content database.  Typically this command is used to make copies of site collections that can be used to validate the upgrade process.   It wasn’t really intended to be used as part of day to day operations and has limitations that prevent it from being used for this purpose

Instead, the best way to accomplish your objective of renaming a SharePoint site collection is to use a combination of the following three commandlets:  Backup-SPSite, Restore-SPSite, and Remove SPSite.  Also, the same set of command can be used to accomplish your second goal of moving site collections between farms (such as from Test into Prod).

Backup-SPSite

Use Backup-SPSite to make a backup copy of a given site collection.  When using this command, you should always specify the –UseSQLsnapshot if your database server supports it.   Including the –UseSQlSnapshot option ensures a valid backup for larger site collections and ensure that users activity does not affect the validity of the backup.

For more information about Backup-SPSite see https://technet.microsoft.com/en-us/library/ff607901.aspx

Restore-SPSite

Once the backup is complete, use Restore-SPSite to create a new site collection from the backup.  The Restore-SPSite command will automatically assign a new id to the created site collection to avoid the potential of duplicate site ids.  You may specify the ContentDatabase name if you want to restore the site to a specific database and should use the HostHeadeerWebApplication parameter if you want to restore the site as a Host Named Site Collection (HNSC).

For more information about Restore-SPSite, see https://technet.microsoft.com/en-us/library/ff607788.aspx

Remove-SPSite

Once you have verified that they restored site is functioning as expected you can delete the old site using the Remove-SPSite command.  If the site collection is very large it is highly recommended that you specify the –GradualDelete option so as not to overburden the system while the site collection is deleted.

For more information about Remove-SPSite, see https://technet.microsoft.com/en-us/library/ff607948.aspx

Scenarios

Each of the usage examples below are based upon the following:

• Contoso has three SharePoint farms:  SP-dev.contoso.net, sp-test.contoso.net and sp.contoso.net
• There is an existing site sp.contoso.net/sites/HR that needs to renamed to sp.contso.net/HumanResources
• A site called sp-test.contoso.net/sites/research needs to be moved from test into prod.

Rename Existing Site

The following command can be used to rename https://sp.contoso.net/sites/Hr to https://sp.contoso.net/sites/HumanResources

Backup-SPSite https://sp.contoso.net/sites/HR `

  –Path E:\Backup\HRBackup.bak -UseSqlSnapshot

Restore-SPSite https://sp.contoso.net/sites/HumanResources `

  –Path E:\Backup\HRBackup.bak

Remove-SPSite https://sp.contoso.net/sites/HR –GradualDelete

Move Site Collection from Test to Prod

The following command can be used to move https://sp-test.contoso.net/sites/research to https://sp.contoso.net/sites/research

From Test

Backup-SPSite https://sp-test.contoso.net/sites/research `

  –Path \\BackupServer\BackupShare\ResearchBackup.bak `

  -UseSqlSnapshot

From Prod

Restore-SPSite https://sp.contoso.net/sites/research `

  –Path \\BackupServer\BackupShare\ResearchBackup.bak

Move Site Collection from path based URL in Test to Host Name Site Collection in Prod

The following command can be used to move https://sp-test.contoso.net/sites/research to https://research.contoso.net

From Test

Backup-SPSite https://sp-test.contoso.net/sites/research `

  –Path \\BackupServer\BackupShare\ResearchBackup.bak `

  -UseSqlSnapshot

From Prod

Restore-SPSite https://research.contoso.net `

  –Path \\BackupServer\BackupShare\ResearchBackup.bak `

  -HostHeaderWebApplication https://sp.contoso.net 

One of the great about utilizing the commands described here is that, as you can see, they can be used for essentially all of your site move and rename needs and won’t be subject to the limitations of the Copy-SPSite commands.

Hope you found this post helpful and I look forward to reading your comments.

# # # # #

The requirement of interest for the blog post is:

• There is a highly consistent intra-farm latency of <1ms one way, 99.9% of the time over a period of ten minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and the database servers.)

In order to ensure proper functioning of the SharePoint farm this requirement must be met.  However, how do you know if the requirement is met if you can’t test it?  Well, Alex Strachan, a clever colleague that works in MCS, wrote a PowerShell script that does exactly that.  I have made some modifications to the script to better suit my preferences but the credit for this idea all goes to Alex.  Thanks Alex for sharing.  If you’d like to see his evolving version of the script please see his blog at https://blogs.technet.com/b/alexst/.

I recommend that this script be run during validation of new deployments as well as on a regular frequency post-deployment to test and verify that there are not any network latencies that have crept into the environment that could be hindering SharePoint operations.

The script performs the following steps:

1. Ping each of the server in the “server list” to make servers are reachable.
2. Connect to the SQL server to verify DB connectivity.
3. Run a 10 minute ping test against each to ensure that the environment meets the <1 ms latency requirement
4. Generates output to show the percentage of pings that complete in 5 ms, 4 ms, 3 ms, 2 ms and 1 ms respectively

Here is sample output from the script:

Test Connectivity:
Testing Ping
  Pinging SP2013DC
  Pinging SP2013SPS
  Pinging SP2013SQL
 - Succeeded 
Testing SQL Connection
 - Succeeded 
Starting network consistency tests @ 11/11/2013 14:00:28
Id              Name            State      HasMoreData     Location             Command                  
--              ----            -----      -----------     --------             -------                  
1               SP2013DC.lat... Running    True            localhost            ...                      
3               SP2013SPS.la... Running    True            localhost            ...                      
5               SP2013SQL.la... Running    True            localhost            ...                      
Gathering statistics for 10 minutes... 
Processing Data... 
SP2013DC meets the latency requirements with 0.01% of pings >1ms
SP2013SPS DOES NOT meet the latency requirements with 25.55% of pings >1ms
  (1.68% > 5ms, 3.16% > 4ms, 5.98% > 3ms, 11.86% > 2ms, 25.55% > 1ms)
SP2013SQL DOES NOT meet the latency requirements with 28.36% of pings >1ms
  (1.76% > 5ms, 3.18% > 4ms, 5.96% > 3ms, 12.47% > 2ms, 28.36% > 1ms)

To run the script, you need to edit the following variable(s) as appropriate for your environment

$hostname – a list of SharePoint server names and/or IP addresses

$SQLName – the name of the SQL server that contains the farm config DB

<#
//*********************************************************
// THIS CODE IS PROVIDED AS IS WITHOUT WARRANTY OF
// ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANY
// IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR
// PURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.
// ©2013 Microsoft Corporation. All rights reserved.
//*********************************************************
#>
# Edit these variables to match your environment
$SPServerNames = "SP2013DC", "SP2013SPS", "SP2013SQL"
$SQLServername = "SP2013SQL"
#Edit this if you want to change the durations of the ping test (in minutes)
$RunTime = 10
### test connectivity ###
Write-Host "Test Connectivity:"
Write-Host "Testing Ping"
$ping = New-Object System.Net.NetworkInformation.ping
for($i=0; $i -le $SPServernames[$i].Length-1; $i++){
    Write-Host "  Pinging $($SPServerNames[$i])"
    $status = $ping.send($SPServernames[$i]).Status
        
    if($status -ne "Success"){
        throw "Ping Failed to $($SPSServernames[$i])"
        }
    }
    
Write-Host " - Succeeded `n"
### test SQL connectivity ###
Write-Host "Testing SQL Connection"
#Connect to SQL using SQlCLient the same way that SharePoint Does
$SQLConnection = New-Object System.Data.SQLClient.SQLConnection("Data Source=$SQLServername;Integrated Security=True")
$SQLConnection.Open()
if($SQLConnection.state -ne "Open"){
    throw "SQL Connection Failed"
    }
Write-Host " - Succeeded `n"
### Intra-server latency consistency test ###
Write-Host "Starting network consistency tests @ $([DateTime]::Now)"
$ScriptBlock = {
    # accept the loop variable across the job-context barrier
    param($InHost, $RunTime) 
    $start = [DateTime]::Now
    $ping = New-Object System.Net.NetworkInformation.ping
    
    $PingResults = @()
    while([datetime]::now -le $start.AddMinutes($RunTime)){ 
        $outping = $ping.send($InHost)
        if($outping.Status -ne "Success"){
            $PingResults = $PingResults + 100
            } else{
            $PingResults = $PingResults + $outping.RoundtripTime
            }
        Start-Sleep .1
        } 
    return $PingResults
    }
#run ping jobs in parallel
foreach($i in $SPServernames){
    Start-Job $ScriptBlock -ArgumentList $i, $RunTime -Name "$i.latency_test"
}
Write-Host "`nGathering statistics for $($RunTime) minutes... `n"
#wait and clean up
While (Get-Job -State "Running") { Start-Sleep $($runTime/2) }
$output = @{}
foreach($i in $SPServernames){
    $output[$i] = Receive-Job -Name "$i.latency_test"
}
Remove-Job *
#test results
Write-Host "Processing Data... `n"
$BadPings = @{}
$PercentBadPings = @{}
foreach($i in $SPServernames){
    $BadPings[$i] = $output[$i] | ?{$_ -ge 1}
    $TotalPings = $output[$i].Length
    $PercentBadPingsOver5Ms =  ($BadPings[$i] | ?{$_ -ge 5}).length/$TotalPings * 100
    $PercentBadPingsOver4Ms =  ($BadPings[$i] | ?{$_ -ge 4}).length/$TotalPings * 100
    $PercentBadPingsOver3Ms =  ($BadPings[$i] | ?{$_ -ge 3}).length/$TotalPings * 100
    $PercentBadPingsOver2Ms =  ($BadPings[$i] | ?{$_ -ge 2}).length/$TotalPings * 100
    $PercentBadPingsOver1Ms =  ($BadPings[$i] | ?{$_ -ge 1}).length/$TotalPings * 100
      
    if($PercentBadPingsOver1Ms -ge .1)
    {
        "{0} DOES NOT meet the latency requirements with {1:N2}% of pings >1ms" -f $i, $PercentBadPingsOver1Ms  
        "  ({0:N2}% > 5ms, {1:N2}% > 4ms, {2:N2}% > 3ms, {3:N2}% > 2ms, {4:N2}% > 1ms)`n" -f $PercentBadPingsOver5Ms,$PercentBadPingsOver4Ms,$PercentBadPingsOver3Ms,$PercentBadPingsOver2Ms,$PercentBadPingsOver1Ms
    } 
        else
        {
        "{0} meets the latency requirements with {1:N2}% of pings >1ms`n" -f $i, $PercentBadPingsOver1Ms
        }
    $LatencyTestFailed = 1
    }
    
#if($LatencyTestFailed -eq 1){
#    throw "Farm Latency Test Failed"
#    } 

I hope you find this post useful and I look forward to reading your comments.

# # # # #

Office & Office 365

SharePoint

For the more complete list of e-books for other Microsoft technologies such as SQL Server, System Center, Visual Studio, Web Development, Windows, Windows Server  and Windows Azure,  see Eric Ligman’s post at   https://blogs.msdn.com/b/mssmallbiz/archive/2013/06/18/huge-collection-of-free-microsoft-ebooks-for-you-including-office-office-365-sharepoint-sql-server-system-center-visual-studio-web-development-windows-windows-azure-and-windows-server.aspx

# # # # #

For information about the latest updates available please see “Updates for SharePoint 2013” at https://technet.microsoft.com/en-US/sharepoint/jj891062 

SharePoint Foundation Server 2013

Release	Version	KB Article	Download
RTM	15.0.4420.1017	N/A
Mar 13 PU *	15.0.4481.1005	2768000
Apr 13 CU	15.0.4505.1002	2751999
June 13 CU	15.0.4517.1003	2817346
Aug 13 CU	15.0.4535.1000	2817517
Oct 13 CU	15.0.4551.1001	2825674
Dec 13 CU	15.0.4551.1508	2849961
Feb 14 CU	Not released	N/A
Service Pack 1 (Recalled)	15.0.4569.1506	2817439
Service Pack 1	15.0.4569.1506	2880551
Apr 14 CU	15.0.4605.1004	2863892
June 14 CU	15.0.4623.1001	2881063
July 14 CU	15.0.4631.1001	2882999

* The March 2013 PU is required for all subsequent updates.  This is the new baseline.

SharePoint Server 2013

Release	Version	KB Article	Download
RTM	15.0.4420.1017	N/A
Mar 13 PU *	15.0.4481.1005	2767999
Apr 13 CU	15.0.4505.1002	2726992
June 13 CU	15.0.4517.1005	2817414
Aug 13 CU	15.0.4535.1000	2817616
Oct 13 CU	15.0.4551.1005	2825647
Dec 13 CU	15.0.4551.1511	2850024
Feb 14 CU	Not released	N/A
Service Pack 1 (Recalled)	15.0.4569.1506	2817429
Service Pack 1	15.0.4569.1506	288052
Apr 14 CU	15.0.4605.1004	2878240
June 14 CU	15.0.4623.1001	2881061
July 14 CU	15.0.4631.1001	2882989

* The March 2013 PU is required for all subsequent updates.  This is the new baseline

# # # # #

For information about the latest updates available please see “Updates for SharePoint 2010 Products” at https://technet.microsoft.com/en-US/SharePoint/ff800847.aspx.

SharePoint Foundation Server 2010 

Release	Version	KB Article	Download
RTM	14.0.4762.1000	N/A
June 2010 CU	14.0.5114.5003	N/A
Aug 2010 CU	14.0.5123.5000	2352346
Oct 2010 CU	14.0.5128.5000	2394323
Dec 2010 CU	14.0.5130.5002	2459125
Feb 2011 CU	14.0.5136.5002	2475880
April 2011 CU	14.0.5138.5001	2472804
Service Pack 1	14.0.6029.1000	2460058
June 2011 CU	14.0.6106.5000	2536601	Recalled
June 2011 CU	14.0.6106.5002	2536601
Aug 2011 CU	14.0.6109.5002	2553117
Oct 2011 CU	14.0.6112.5000	2596508
Dec 2011 CU	14.0.6114.5000	2596998
Feb 2012 CU	14.0.6117.5002	2597132
April 2012 CU	14.0.6120.5000	2536601	Recalled
April 2012 CU	14.0.6120.5006	2598321
June 2012 CU	14.0.6123.5002	2598373
Aug 2012 CU	14.0.6126.5000	2687355
Oct 2012 CU	14.0.6129.5000	2687566
Dec 2012 CU	14.0.6131.5001	2596957
Feb 2013 CU	14.0.6134.5000	2760791
Apr 2013 CU	14.0.6137.5000	2794728
June 2013 CU	14.0.7102.5000	2817392	Recalled
June 2013 CU	14.0.7102.5004	2817552
Service Pack 2 *	14.0.7015.1000	2687464
Aug 2013 CU	14.0.7106.5000	2817594	Recalled
Aug 2013 CU	14.0.7106.5000	2825990
Oct 2013 CU	14.0.7110.5000	2825824
Dec 2013 CU	14.0.7113.5000	2849990
Feb 2014 CU	14.0.7116.5000	2863938
Apr 2014 CU	14.0.7121.5000	2878270
June 2014 CU	14.0.7125.5002	2880975
July 2014 CU	14.0.7128.5001	2883026

* All the public updates that were released through May 2013, and all the cumulative updates that were released through April 2013 are included in Service Pack 2.  However, even though the June 2013 Cu was released prior to Service Pack 2, the service pack does NOT contain the fixes included in the June CU.  In order to get the fixes included in June 2013 CU you must install both the June 2013 CU AND Service Pack 2.

SharePoint Server Server 2010

Release	Version	KB Article	Download
RTM	14.0.4762.1000	N/A
June 2010 CU	14.0.5114.5003	N/A
Aug 2010 CU	14.0.5123.5000	2352342
Oct 2010 CU	14.0.5128.5000	2394320
Dec 2010 CU	14.0.5130.5002	2459257
Feb 2011 CU	14.0.5136.5002	2475878
April 2011 CU	14.0.5138.5001	2512800
Service Pack 1	14.0.6029.1000	2460045
June 2011 CU	14.0.6106.5000	2536599	Recalled
June 2011 CU	14.0.6106.5000	2536599
Aug 2011 CU	14.0.6109.5002	2553048
Oct 2011 CU	14.0.6112.5000	2596505
Dec 2011 CU	14.0.6114.5000	2597014
Feb 2012 CU	14.0.6117.5002	2597150
April 2012 CU	14.0.6120.5000	2598151	Recalled
April 2012 CU	14.0.6120.5006	2598151
June 2012 CU	14.0.6123.5002	2598354
Aug 2012 CU	14.0.6126.5000	2687353
Oct 2012 CU	14.0.6129.5000	2687564
Dec 2012 CU	14.0.6131.5001	2596955
Feb 2013 CU	14.0.6134.5000	2767793
Apr 2013 CU	14.0.6137.5000	2775353
June 2013 CU	14.0.7102.5000	2817363	Recalled
June 2013 CU	14.0.7102.5004	2817527
Service Pack 2 *	14.0.7015.1000	2687453
Aug 2013 CU	14.0.7106.5000	2817570	Recalled
Aug 2013 CU	14.0.7106.5000	2825949
Oct 2013 CU	14.0.7110.5000	2825786
Dec 2013 CU	14.0.7113.5000	2849971
Feb 2014 CU	14.0.7116.5000	2863913
Apr 2014 CU	14.0.7121.5004	2878250
June 2014 CU	14.0.7125.5002	2880972
July 2014 CU	14.0.7128.5001	2883005

All the public updates that were released through May 2013, and all the cumulative updates that were released through April 2013 are included in Service Pack 2.  However, even though the June 2013 Cu was released prior to Service Pack 2, the service pack does NOT contain the fixes included in the June CU.  In order to get the fixes included in June 2013 CU you must install both the June 2013 CU AND Service Pack 2.

# # # # #