The first SharePoint Saturday Albany will take place on Saturday, February 1st, 2014, from 8:30 am to 4:00 pm at Microsoft Albany Office located at 54 State Street, 7th Floor, Albany, NY.
SharePoint Saturday is FREE, open to the public and is your local chance to immerse yourself in SharePoint!
SharePoint Saturday is an educational, informative, and lively day filled with sessions from respected SharePoint professionals and MVPs, covering a wide variety of SharePoint-orientated topics. Mingle and learn with SharePoint business users, architects, developers, and other professionals that work with SharePoint everyday, and who can share insights into the new SharePoint 2013.
I’m speaking…. To register click here
You don’t read about this functionally much, but the sitemanager in SharePoint is a little germ if you want to do the following:
-Copy files to a different site, by view or library, something that the explorer view can’t do.
-Move files, by view or library, something that the explorer view can’t do.
-Quickly navigate around not just a site but an entire site collection
1. Go to http://your site path/_layouts/sitemanager.aspx
2. Click on the library from which you would like to move the documents and this should provide you the list of the all documents
3. Select all/documents you would like to move
4. From the menu, under “Actions” there is option to Move/Copy.
5. Select the destination document Lib
This feature has been in SP since 2003, is never discussed. The really cool part is the Content and Structure reports. They’re a little contrived but you can do a fair amount of datamining.
This article is the fourth and final article that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.
Testing your Disaster Recovery Plan
After taking the time to create a SharePoint DR plan, the last thing you want to do is file it away (outside of your SharePoint environment) and hope you never have to use it. You need to establish the plan works as expected so if or when the time comes that you need to activate the plan you and the stakeholders have confidence that the plan, if executed properly, will deliver the expected results.
As a best practice you should test your DR plan on an on-going basis. It is recommended that larger organizations test their DR plan at least twice a year. Smaller organizations should test their DR plan annually.
Planning your Test
Testing your SharePoint DR plan will help identify any missing steps, potential problems with existing steps, missing dependencies, and potential bottlenecks. Testing will also help you determine the timings associated with each step of the recovery plan so you know whether the plan will meet your RTO and RPO goals.
It is important to determine when and where your tests will be conducted. You should try to conduct your tests in an environment that resembles your normal production environment so you can get a realistic feel for the plan and how it will work if your production environment went down.
Determine your Test Scopes
In order to test your SharePoint DR plan you need to define the scope of the tests you will be conducting. Begin by identifying the types of outages your SharePoint environment may experience. Some examples of common types of outages include:
- Configuration Database Corruption
- Content Database Corruption
- Application Server
- Database Server
- Web Front End
- Application Server
- Virtual Host Failure
- Datacenter Failure
For each test, the appropriate resources will be needed to help conduct the test and determine if the test was a success. For example if testing the scenario of a failed application server your plan calls for the relevant services that were running on the failed server to be moved to a server that is still up and running in the farm. Once the services have been moved and configured the appropriate resources would validate the services are up and running and the SharePoint farm is behaving as expected.
Performing the Test
Once you have finished planning your test and your test scopes have been defined, you need to perform a full test of your SharePoint DR plan.
Your tests should be conducted in the context of the overall BCP so you get a feel for how the plan fits in and works with your company’s BCP. Involve your key stakeholders from both IT and the business and be sure to include the communications plan.
All tests should be thoroughly documented by creating a checklist to record the following information for each test and each step within a test:
- Test ID (sequentially numbered, e.g. 001, 002, 003, etc.)
- Test Name
- Test Description
DR Plan Reference
- Step ID
- Step Description
- Expected Results
- Actual Results
- Expected Duration
- Actual Duration
- Step ID
Analyzing the results
Once you have completed all of the tests in your test scope, it is time to go back and analyse the test results. In all cases, you will be measuring the results of the test against the defined success criteria including the RTO and RPO goals.
Regardless of whether the test passed or failed, all test results should be well documented and shared with the key stakeholders so everyone has an understanding of what worked and what did not.
Maintaining your Disaster Recovery Plan
Your SharePoint DR plan should be considered a living document, meaning it will continue to evolve over time as your farm continues to grow and new technologies are introduced into the environment.
Over time you may find that budget constraints that at one point limited your RTO and RPO goals may no longer be a concern and your RTO and RPO goals can be adjusted according as new funding is made available for things such as a standby datacenter.
You should schedule periodic reviews of the plan and adjust the plan as necessary. It is important to continue to test your SharePoint DR plan as it continues to evolve over time.
For example, you should plan to review your SharePoint DR plan at least once a quarter. You should review all aspects of the SharePoint DR plan including your recovery targets, RTO, and RPO.
You should plan on performing a full test of your SharePoint DR plan at least once or twice a year depending upon the size of your organization, number of systems to be tested, amount of data to be recovered and the complexity of your SharePoint DR plan.
After each test, you will need to update your SharePoint DR plan according to the results of your test. This will assure your SharePoint DR plan is properly maintained and will be ready in the event of a disaster.
This article and the previous related ones has defined what it takes to create, test, and maintain a SharePoint DR plan. As the reader can see, it is not a 30-minute exercise where one person creates, test and maintains the DR plan alone, but an on-going activity that has a number of stakeholders and key individuals that will responsible for ensuring your organization is continually working to have the best plan in place in case of a SharePoint disaster.
This article is 3 of 4 articles that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.
Creating an Effective Disaster Recovery Plan
Now that you have an inventory of each of the components of your SharePoint environment identified threats to the key components of your environment, the next step is to develop your SharePoint DR plan.
One thing you should never do is create your SharePoint DR plan in a vacuum. This means you should not develop your SharePoint DR plan without input and feedback from other key stakeholders whether they are IT stakeholders or business stakeholders.
Your SharePoint DR plan should be part of a larger business continuity plan (BCP) which is typically driven by business stakeholders. The BCP will identify what sites and components within the SharePoint environment are most critical and what the acceptable levels of downtime are for these items. The BCP should also contain the plan for communicating any downtime to the end users.
Identifying Key Stakeholders
The first step in creating an effective SharePoint DR plan is to define the overall scope of the plan and to define the key components that must be restored in the event of a disaster. Having a well-defined scope and knowing the key components will allow for a more productive process of developing your SharePoint DR plan. You begin by working with the key stakeholders within your organization that would be affected if your SharePoint environment were to become unavailable as a result of a disaster. In addition to the individuals responsible for administering and maintaining SharePoint itself, other key stakeholders will play a key role in developing the SharePoint DR plan.
From an IT perspective the key stakeholders are typically represented by individuals from the three key components of the physical architecture described earlier; Servers, Database and Network. In addition, there may be stakeholders from Messaging and Development depending upon the configuration of your SharePoint environment and if there is any custom developed code running in your SharePoint environment.
The server support team will typically consist of individuals that are responsible for installing and maintaining the servers in your SharePoint environment from an operating system and hardware perspective. This holds true for both physical and virtual servers however there may be other individuals responsible for installing and maintaining the virtual hosts if you have virtual servers in your SharePoint environment.
The database support team will typically consist of DBAs who are responsible for installing, configuring, and maintaining the SQL Server databases in your SharePoint environment. The DBAs are often responsible for monitoring the health of the SQL Servers as well as creating and maintaining database level backup schedules.
The network support team consists of individuals responsible for the connectivity between the systems and services that make up your SharePoint environment. Included in this group are the individuals responsible for configuring and maintaining DNS, hardware load balancers and associated virtual IP (VIP) addresses.
SharePoint supports both incoming and outgoing e-mails therefore if your SharePoint environment is using either or both then there should be a stakeholder from the messaging support team to make sure all matters regarding SharePoint and messaging are covered.
The features and functionality of SharePoint can be enhanced and extended through custom developed features, solutions and apps. If your SharePoint environment makes use of custom developed code then your stakeholders should include representation from the development support team.
From a business perspective, the number of key stakeholders can range from just one or two individuals in a small company to a significant number of individuals in a very large company. Regardless of the number of key business stakeholders, they will play the biggest role in defining the scope of your SharePoint DR plan. The key business stakeholders will identify the individual SharePoint sites and services that will need to be available and how soon they will need to be available in the event of a disaster. The results of this Business Impact Analysis (BIA) will be the foundation upon which your SharePoint DR plan will be developed.
The above examples of key stakeholders are typical of very large and large organizations. If you are a small or medium size organization these key stakeholders will most often be roles filled by the same person or may not even be filled by anyone. For example in a small organization there may not be a DBA. SQL Servers may have been set up by an outside consulting organization that is no longer engaged with your organization.
Regardless of whether your organization has these key stakeholders or not this section provides an example of the types of individuals and roles that will play a part in developing your SharePoint DR plan.
Developing the Plan
The BIA will have a direct impact on the RTO and RPO goals of your SharePoint DR plan as it will define the recovery targets of the individual components of your SharePoint environment.
Defining Recovery Targets
Recovery targets are defined as the key pieces of functionality and data identified in the Business Impact Analysis (BIA) that need to be restored in the event of a disaster in relation to the components of your SharePoint environment identified earlier in this article. You will need to work with the key stakeholders to establish the recovery targets for each component of your SharePoint environment in order to build your SharePoint DR plan.
In some cases, such as when you have a large SharePoint farm, your recovery targets may only represent a subset of the total functionality of your SharePoint farm. This will certainly be the case if the RTO is very aggressive and a full recovery will take more time that what the RTO will allow.
It is important to remember that each decision made during the development of your SharePoint DR plan will have an associated cost. One must understand the cost of downtime in order to understand the cost impact of how you handle a SharePoint disaster. If your SharePoint farm contains mission or business critical data or applications then the cost of downtime should be considered high. This means that the investment in developing a SharePoint DR plan that includes investments in additional hardware can be offset by the impact of downtime.
If you have a high RPO then you might need additional space for more frequent backups. This might mean an additional investment is storage space, third party backup/restore software or a SQL Server with failover clustering, database mirroring or AlwaysOn Availability Groups.
AlwaysOn Availability Groups is a feature of SQL Server 2012. It is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring that maximizes the availability of a set of user databases for an enterprise.
The following diagram shows a SharePoint farm configured for high availability. The diagram shows how complex a SharePoint farm can get if you are building for high availability. Looking at the number of servers and components involved in a high availability farm shows just how costly this kind of solution could be.:
Planning for high availability (HA) requires redundancy in your physical architecture such as failover SQL clusters and redundant application servers. It is important to know that HA could have some significant costs associated with it depending upon which components of your physical architecture you will build for HA.
The following diagram shows a SharePoint farm with a redundant farm in a secondary datacenter. The diagram shows the redundant farm and how it is physically and potentially geographically separated from your primary farm. The advantage if this kind of redundancy comes in to play in the event of a disaster in which you lose your primary datacenter. An example of this would be in the event of a natural disaster such as a hurricane or flood where you could lose your primary datacenter and your physically and geographically separated datacenter is unaffected so it would then become your primary datacenter until your primary datacenter is back up and running.
Virtualization provides a workable cost effective option for a recovery solution. You can use virtualization technology such as Hyper-V or VMware as an on-premise solution or tools such as Windows Azure or Amazon Web Services (AWS) as a hosted solution to provide necessary infrastructure for recovery.
You can create virtual images of the production servers and ship these images to a secondary datacenter. By using the virtual standby solution, you have to make sure that the virtual images are created often enough to provide the level of farm configuration and content freshness that you must have for recovering the farm in order to meet your recovery targets and RTO and RPO goals.
A Virtual Standby Solution maintains up-to-date standby virtual machines for fast push button disaster recovery. The bootable virtual machine is an exact clone of the production server as of the last snapshot or backup.
Service Level Agreements
A Service Level Agreement (SLA) is a written agreement that specifies the requirements for server or application uptime and the penalties for not meeting those requirements. Two of the most specific and important components within an SLA are RPO and RTO. Both components are extremely important in developing your SharePoint DR plan
The RPO is retroactive from the moment of actual failure. It can be set in seconds, minutes, hours, or days but must correspond to the amount of tolerable lost data.
The RTO is typically based on lost revenue or productivity measured in seconds, minutes, hours, or days and corresponds to the measurable uptime (99.99%, 99.999% etc.) within an SLA.
The following table shows a very basic sample SharePoint SLA.
|SERVICE ITEM||SERVICE COMMITMENT|
|Recovery Time Objective (RTO)||< 5 Hours|
|Recovery Point Objective (RPO)||30 Minute Data Loss Window|
Although a SharePoint SLA contains many more service items, the above sample shows the availability components only.
Planning for Recovery
Now that you have set the RPO and RTO for your SharePoint environment, established the recovery targets and understand the costs associated with these recovery targets it’s time to begin planning for recovery. Recovery is defined as the steps that must be taken in order to get the SharePoint environment back to an acceptable level of functionality as defined in the BIA.
Be sure your plan for recovery includes a communications plan. It will be important to keep the key stakeholders as well as end users up to date on the recovery process especially if there are mission critical applications that have been affected by the disaster.
In order to begin planning for recovery you must begin by identifying the resources, such as people, hardware and software, that will be needed to start the recovery process.
Your SharePoint DR plan should include a list of key individuals and stakeholders that will be part of the recovery process. This list should include the following:
- Primary Phone Number
- Backup Phone Number
- E-Mail Address
- Recovery Responsibilities
Once you have established what additional hardware will be needed for recovery you should begin the process of acquiring the hardware so it is on hand as soon as possible. Whether the hardware is dedicated hardware or shared hardware make sure it is clearly identified as hardware associated with the SharePoint recover process.
If any additional software is required for a secondary datacenter or failover farm then you must acquire and maintain a sufficient amount of licenses to support the secondary datacenter or failover farm in accordance with the software vendor’s licensing policy.
You also need to ensure that you maintain a copy of each Service Pack, patch, hotfix, and Cumulative Update (CU) installed on your farm. Sometimes hotfixes are superseded later by other hotfixes or even retracted and can no longer be downloaded in the original form so maintaining copies will ensure you can return back to the exact patch level you had before you had the disaster if you find yourself in a DR scenario.
SharePoint depends on a number of services that may not be covered by the SharePoint DR plan. Services such as SQL Server, Active Directory (AD), DNS, SMTP might have their own individual DR plans. It is important to make sure the RTO and RPO values for these services are in line those of the SharePoint environment. If they are not in line with each other then you must look at what needs to be done to get them in line even if it means adjusting the RTO and RPO of the SharePoint environment or increasing the budget set aside for the SharePoint DR plan.
Establishing and Documenting your Recovery Procedures
The next step in developing your SharePoint DR plan is to establish and document the procedures required for recovery. It is important to document these procedures as clearly and concisely as possible with the understanding that individual or individuals executing these procedures may not have been a part of developing the SharePoint DR plan. They are also most likely to be under a great deal of pressure during the execution of the plan so the more clearly the procedures are written, the better the chance for success within the expected timelines.
It is important to socialize your SharePoint DR plan so those that have a stake in the plan or will be a part of the testing or execution of the plan are aware of it and know where to go to see the latest copy as you SharePoint DR plan will be an ever evolving and changing document.
Define Success Criteria
How do you know your recovery is a success without defining success criteria? The criteria for determining whether your recovery was a success or not should be clearly defined in your SharePoint DR plan. Typically success criteria are derived from the recovery targets established during the development of the plan. For example if you have a recovery target for the corporate Intranet defined as one business day, when executing or testing your SharePoint DR plan you are able to have your corporate Intranet up and running in one business day or less the recovery is considered a success.
Success criteria can vary for different applications and sites that are part your SharePoint farm. As you are defining your recovery targets when developing your DR plan you will identify the various components of your SharePoint farm including individual application and sites and what will define a successful recovery in the event of a disaster.
Reviewing the Plan
Once you have completed your SharePoint DR plan it is important that the plan is thoroughly reviewed for accuracy and clarity. This review should be completed by a third party, or if that’s not possible, a qualified person or group that was not involved with creating the plan.
You should never consider your SharePoint DR plan complete until it has been checked and verified by parties that were not involved with creating the plan.
For more information please refer to:” Plan for high availability and disaster recovery for SharePoint 2013″ http://technet.microsoft.com/en- us/library/cc263031.aspx.
Date: Saturday, December 14
- Time: 2:00 PM – 4:00 PM
- Category: Cloud Services
10 steps to know how to make the move to the cloud: The word ‘cloud’ is often thrown around in conversation as if this knowledge is given. But when it comes to file storage, email and instant messaging, screen sharing, life gets a bit complex and daunting. The workshop style presentation introduces you to the : 1. The confusing terms demystified 2. Compare and contrast: a. Drop box, SkyDrive b. Yammer, Facebook c. Google docs and Office 365 d. SharePoint 3. Where to start This is ideal for anyone who is thinking of moving their business activities to the cloud, whether you work for a Fortune 500, or are a Fortune 500,000.
This is an ideal workshop to explain the what, where and how of the cloud. This workflow is presented by: Peter Ward a SharePoint architect and coauthor of 4 SharePoint books and works for the Microsoft partner Soho Dragon Solutions. www.sohodragon.com
For further details, click here
This article is 2 of 4 articles that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.
Identifying Threats to your SharePoint Environment
Now that you have an inventory of each of the components of your SharePoint environment, the next step is to identify threats to the key components that should be included in your SharePoint DR plan. The primary threats that could affect your SharePoint environment and put you in a DR situation are typically related to your physical architecture as opposed to the logical architecture. This section focuses on threats to your physical architecture although you should be aware that threats to your logical architecture such as issues with web application, service applications and apps could affect your SharePoint environment and put you in DR situation.
Any disruption or failure in the physical architecture of your SharePoint environment can cause downtime which would necessitate activating the SharePoint DR plan if the issue could not be resolved through normal troubleshooting. Such a situation could be a natural disaster such as a flood, hurricane or earthquake that would knock your primary datacenter offline.
The following identifies the key components of the physical architecture and the threats to each that should be considered in your SharePoint DR plan.
A SharePoint farm consists of any number of servers from a single server farm to a large scale multi-server enterprise farm. A failure of any of these servers can have a dramatic effect on the farm from degraded performance to complete failure. Typically the biggest failure at the server level is hardware related. Whether it is a bad NIC, a failed drive, a drive that’s run out of space or some other hardware issue, a failure of any one of these key components can cause downtime in your SharePoint farm and should be accounted for in your DR plan.
It is recommended that on-going monitoring and periodic testing of your hardware health can go a long way to prevent the kind of hardware failure that could cause a disaster in your SharePoint farm. Items that should be monitored and tested would include:
- Hard Drives
The heart of any SharePoint implementation is the database. A failure at the database level would have a significant effect on the performance and/or availability of the related SharePoint farm. Failures that typically occur at the database level involve a drive failure (local or SAN), a corrupted database or transaction log file, a full transaction log, a hung database transaction, a hung database lock or the SQL Server service has stopped running.
Database administrators should set up monitors and jobs to identify and eliminate issues that could pose a risk to the health of the database that could cause a disaster in your SharePoint farm. Items that should be monitored would include:
- Drive Space
- Log Size
- Disk I/O
- Database Locks
If your SharePoint servers cannot communicate with each other or cannot be reached by end users this is a certain a recipe for disaster. Preparing for a network failure including a network hardware failure such as switches, routers, load balancers or a network software failure such as DNS or Directory Services such as Active Directory will be a key piece of your SharePoint DR plan.
Setting up monitoring of your network and key components of your network infrastructure can help in identifying potential disasters in your SharePoint environment before they occur. Items that should be monitored should include:
- Network Latency
- Network Speed
For more information please refer to: “Plan for monitoring in SharePoint 2013″ http://technet.microsoft.com/en-us/library/jj219701.aspx