SharepointFlyHigh: 12/07/14

Sunday 7 December 2014

How to be sure that your SharePoint farm is fully protected

Certainly, you can use DPM 2010 to protect the content databases within the farm, and there is goodness in DPM 2010 such as auto-protection of new content databases within the farm and the one-click setup for farm content protection. But there are a few other aspects of the SharePoint farm that you need to consider when planning comprehensive protection and full-farm recovery. So, what will you need to do above DPM 2010? The real answer lies in how you have your farm configured and what kind of applications and collections you are using. This focuses on SharePoint 2010 protection in DPM 2010 but the ideas can easily go backwards to earlier versions (although some of the features like auto-add are specific to DPM 2010).
So, let’s look at this first in a simple light. I will touch very lightly on the basic configuration steps here as those are pretty well documented on the DPM TechNet Site. You are running a basic SharePoint farm with just the default web application(s). When you go to protect this in DPM, you simply need to push an agent to any servers that have data for this farm. At the very least, you will need an agent on the WFE (web front end) server as well as the SQL Server where the SharePoint databases are being housed. Now we run configuresharepoint.exe –enablesharepointprotection on the web front end and we are all set.
From DPM, we can go to create a protection group. When we expand our SharePoint farm WFE server in the DPM protection group creation wizard, we will see the SharePoint farm listed and that is what we need to select. This will pick up any content databases and the SharePoint_Config and SharePoint_AdminContent* databases. So, if you are using just the basic configuration, you are set. As a bonus, if you create any new content databases, they will be automatically added to the SharePoint protection without needing any user intervention provided they are located on a server that already has a DPM agent installed.

http://blogs.technet.com/blogfiles/dpm/WindowsLiveWriter/HowtobesurethatyourSharePointfarmistruly_7DE0/clip_image002_3.gif

This also assumes that you have not used any custom or third party templates. But, if you keep things simple, then full protection is simple as will be the recovery.
But, let’s be real. How many of us really keep things simple? By nature, the “computer nerd” in all of us screams to see what these things can really do. That is where we will need more consideration to protect our SharePoint farms. We will look at two different levels of “complexity” here. The first level is a farm that is using the other types of applications and databases (specifically search indexes and service applications). The second level is for those who are using third party or custom templates.
Focusing on the first scenario, we will look at how we need to ensure DPM is fully protecting SharePoint when you have some search indexes or service applications. These will both create databases, but when you just check the SharePoint box for protection it will not pick these databases up. As you can see in my screen shot, I have protected SharePoint and the content and config databases are protected. This was done automatically by DPM and these databases are no longer selectable. However, when I look at the database instance it is using, the additional databases I have created for some service applications (BDC_Service_DB_*) are not protected with SharePoint.

This is our cue that we need to protect them separately. The good news? We can just add them to the same protection group with the SharePoint farm. The bad news? We have an extra step in order to protect them and have auto protection enabled for them. The bottom line is this. If you create the SharePoint protection and at the same time try to add the rest of the instance by adding its SQL instance, it will fail to add the entire instance because some of it is being added with SharePoint. So, you can add individual databases, but this does not accomplish the addition of new databases that are not contentDBs because we can only use auto protect at the instance level.
Because of this, we have to create the protection group that includes SharePoint, and then go and modify the protection group to add the instance name. This will essentially allow auto protection for all new databases in this instance. If they are content databases created through SharePoint, then they will be automatically added each night to the SharePoint part of the protection group. If they are search indexes or application service databases added through SharePoint, then they will be automatically added each night to the SQL Server instance part of the protection group. Either way, you will be covered!

Above, the SharePoint datasource is already protected, so we have modified protection and are adding the remaining databases. Note that “Auto” is enabled for this instance which means that any databases that are added but not part of the SharePoint protection (any on content databases), they will be added to this group.
Finally we have our users who want to customize templates and use third party templates to help build their SharePoint farm. The database situation will not change here and the above rules apply. The additional caveats this adds deal with physical files. Quite often, these features will add physical files needed by SharePoint in order to accomplish the goal of creating the sites. Even if all of your database files are protected, if you have to do a disaster recovery restore, the site will be useless without these files. So, we will need to also grab those files.
Because these can be placed anywhere, it’s hard to say definitively where they will be, so I will write this based on the generally accepted location for them. Most often, the features and customization files will be installed and kept in the Program Files\Common Files\Microsoft Shared\Web Server Extensions\12 (for SharePoint 2007) (or \14 for SharePoint 2010), so we will need to capture that location as part of our protection group. Finally, we will need to know the location of the web site files and back up that directory. The notable file we really need is the web.config that contains any custom policies and permissions that may have been created for the site. The default location for these files will be the C:\inetpub directory (SharePoint admins will know if they changed it).

http://blogs.technet.com/blogfiles/dpm/WindowsLiveWriter/HowtobesurethatyourSharePointfarmistruly_7DE0/clip_image008_3.gif

The important note here is that the DPM admin and SharePoint admin need to talk. As long as they are communicating what is being protected, there shouldn’t be any need for panic if that sudden panic moment arrives.
Alternately, you can put all of your SharePoint farm into VM’s running on Hyper-V and protect the VM’s using DPM 2010 and also put an agent on the farm and protect it both ways. That way you can restore individual files from the backed up VHD using the new item level recovery in DPM 2010, and not worry if you missed some of the files or folders needed. But that’s a topic for another day!
Now, we can sleep better at night knowing that our complex SharePoint setup is better able to handle a catastrophic failure because DPM is protecting the full thing and a restore will be much more painless. Your SharePoint admins will be much happier knowing what they need is only a restore away.

Reference:

http://blogs.technet.com/b/dpm/archive/2010/05/10/how-to-be-sure-that-your-sharepoint-farm-is-fully-protected.aspx

Microsoft DPM - The best backup/restore solution for SharePoint 2010

We’ve all been in this situation – after a good long SharePoint based portal implementation – we start scratching our head to figure out what's the best way to back up the SharePoint farm and drown in the multitude of options – SharePoint native backup, stsadm or 3^rd party products like AvePoint or EMC.
Now, Microsoft makes our life very easy by announcing Data Protection Manager as the main backup/restore application for SharePoint 2010.
Well, you might think that’s just another one of the many methods to protect SharePoint 2010 but DPM hides under its hood some pretty cool features which make it the #1 backup/restore application for SharePoint 2010. Here are some of them:

Application Awareness – it is probably one of the most important features of DPM, DPM is aware that it's backing up SharePoint and not any other solution when backing up SharePoint databases. The meaning of this is that DPM works hand in hand with SharePoint and as the result of that the backed up data is more consistent as DPM makes sure that all the transactions that are occurring during the backup are taken into consideration.
Item Level Recovery – DPM enables to recover a single object out of a full farm backup of a wide variety of SharePoint objects, such as documents, lists, document libraries, sites and sites collections.
Protects SharePoint Search. In a large farm the search index can get rather big. In these situations - backing up search is crucial as in a case of disaster it could take very long time, even days, to index the farm again.
Better Performance – DPM runs a very light agent which almost does not affect the farm production environment, with very low I/O, as it scans memory blocks to track changes in real -time.
Self-Healing Backup Process – during the backup, if one of the backup objects, such as server or database, goes offline – DPM will proceed with the backup as planned and try to self-heal and add the offline object during the next planned backup.
Reduce Storage Costs – DPM aims to use disks as the main backup storage and tapes for archiving. It's very understandable as disks are cheaper and more common than tapes and it's very easy and quick to restore data from them.
Furthermore, DPM reduces storage costs by minimizing backed up data by backing up only the changed blocks of data, meaning that every backup after the first full backup is approximately 5% (average daily data change on a SharePoint farm) of the whole farm data. That saves about 75% of storage space comparing to differential SharePoint native backup over a one month period.
Search for Content (across Recovery Points). DPM enables to search the backed up data. It's very helpful if we want to perform an item level recovery, DPM search makes it very easy to locate an item to recover when needed and the time factor is crucial.

DPM is a great SharePoint 2010 backup/restore solution. And the fact it comes from Microsoft is a big advantage over other solutions as it integrates well with SharePoint within the backup/restore processes.
It very important to mention that DPM actually is the main Microsoft backup/restore solution for other Microsoft products such as Active Directory, Exchange, SQL, Virtual Server, file shares, System State and more. So it’s a great new backup/restore product family from Microsoft.
For more information – http://www.microsoft.com/dpm
Try it! There's also a 180 days evaluation download.

Reference:

https://www.infowisesolutions.com/blog/Comments.aspx?ArticleId=9

Integrating Sharepoint 2010 and SQL Reporting Services 2008 in 6 easy steps

Step by step article by Raymund

There are only 6 main steps to achieve this task assuming you already have an instance of SQL Server Reporting Services and SharePoint 2010.
I had created this starting from a clean installation of SQL Reporting Services so this guide will discuss the steps on configuring your SQL Reporting Services 2008 for integration with SharePoint 2010.

Step 1: Configuring SQL Reporting Services – Web Service URL

Simply go to Reporting Services Configuration Manager and choose Web Service URL and populate the following needed information. The fields are named properly so I guess there is no need for further explanation. What this does is that it configures the IIS for you depending on what Virtual Directory names you had declared.

Step 2: Configuring SQL Reporting Services – Create a Report Database

Same here, fields need no further explanation except for one which is Native Mode and SharePoint Integrated mode which I will explain below.
Choose create a database or if you already have one choose an existing one. For this example, we will create a new one:

Connect to the database where you want your Report Data to be stored:

Give it a Name and a Report Server Mode.
With SharePoint Integrated Mode the report RDLs are stored on SharePoint and not in the Report Database. For this instance, we will use the SharePoint Integrated Mode: