I am trying to protect a new SharePoint Foundation 2013 farm with it's databases stored on an SQL 2012 AlwaysOn Availability Group.  I've run configureSharePoint.exe -EnableSharePointProtection on my WFE and SharePoint shows up in DPM when I try to add it to a protection group.  But I get the 32008 referenced here: http://support.microsoft.com/kb/970641 when trying to select the farm to back up.

If I run ConfigureSharePoint.exe -resolveallSQLAliases on the WFE it doesn't return anything.

I'm directly backing up databases on the SQL 2012 server, but not any of the SharePoint DBs.

Hi,

Please try this and see if that works.

System Center 2012 - Data Protection Manager Release Notes
http://technet.microsoft.com/en-us/library/hh848297.aspx

SQL Server 2012
 Do the following to protect SQL Server 2012 database:

 Connect to the SQL Server 2012 instance through the Management Studio, then select and expand Security. Then select and expand Logins and right-click NT AUTHORITY\SYSTEM and select Properties. Click Serverroles, select sysadmin and click OK

If you are not comfortable with giving system account perms you can give to the DPMRA service instead.

Protection for SQL 2012 will require administrators to use the following steps:

1. On the SQL side the DPMRA service should run under Local system. You can verify this via services in computer management
Connect to the SQL 2012 instance with the help of SQL2012 Management Studio > select and expand Security > select and expand Logins > right click on the NT  AUTHORITY\DPMRA and select Properties > click on ServerRoles > check the sysadmin checkbox > click OK

I already had it set up that way to allow for the other SQL DBs to be backed up, so that's not the answer.  thanks for the suggestion though.

Hi,

Can you tell me how you have AlwaysOn Ag configured ?

what specifically are you looking for? 

I have two Windows 2008 R2 servers set up with SQL 2012 on them.  No shared storage.  I have databases on them that are synchronized.

Hi,

I'm looking for details for these settings:

Availability Mode:
Failover Mode:
Connections in Primary Role:
Readable Secondary:

Backup Preferences:
     Perfer 
     Priority: 
     Exclude Replica:

All the settings below are the same on both nodes

Availability Mode: Syncronous Commit
Failover Mode: Automatic
Connections in Primary Role: Allow All Connections
Readable Secondary: Yes
Backup Preferences: 
     Perfer: Prefer Secondary
     Priority: 50
     Exclude Replica: Not checked

Hi,

Ok, I'm trying to get some clarification on this fro the DPM Product group. Since sharepoint has it's own writer running on the WFE, it will pointing DPM to backup the databases on the primary SQL Server, so setting the backup preference to prefer secondary may be the cause of the problem.

Please try these steps and let me know if it helps.

1) Be sure you have DPM agents installed on all SQL Server nodes.
2) Change the backup Preference to, Prefer: Primary

Now try to reneumerate the Sharepoint WFE and see if you can protect it.

Hi,

I really appreciate how much you're looking in to this.

I tried the suggestions you mentioned and that didn't make a difference in either the DPM enumeration or the when running the ConfigureSharepoint.exe -ResolveAllSQLAliases on the WFE.

Hi,

OK, I will need some output of the VSS writers from both the Sharepoint web front end, and the SQL Server back end.

On the Sharepoint Web Front end, From an administrative command prompt run:

c:\>diskshadow /l c:\temp\wfewriters.txt

DISKSHADOW>List Writers

..... writer output....

DISKSHADOW>Exit

On the SQL Server hosting the primary copies of the sharepoint DB's, From an administrative command prompt run:

c:\>diskshadow /l c:\temp\P-SQLWriters.txt

DISKSHADOW>List Writers

..... writer output....

DISKSHADOW>Exit

On the SQL Server hosting the secondary copies of the sharepoint DB's, From an administrative command prompt run:

c:\>diskshadow /l c:\temp\S-SQLWriters.txt

DISKSHADOW>List Writers

..... writer output....

DISKSHADOW>Exit

Pkzip the 3 output files and upload them to this workspace:

https://sftus.one.microsoft.com/choosetransfer.aspx?key=4ad02e01-50fa-42cf-b2e6-15c6ed910284
Case sensative password: 0G{h]0hbMa*p

I'll see if I can discover a problem.

Mike,

I've uploaded the files you requested.

HI,

Thanks kindly, I can't get to it until Monday.

Hi,

I'm having some trouble understanding what I'm seeing in the writer output from the WFE server.  Specifically the machine names that the writer is reporting.

If you look in the wfewtiters.txt, What is the machine that ends in 02 ?  Is that a physical machine or an alias ?
The machine ending in 06 is the Secondary SQL Server and that is what the Sharepoint writer is pointing to.

The WFE VSS Sharepoint writer shows this for two content DBs

 * WRITER "SharePoint Services Writer"
  - Writer ID   = {da452614-4858-5e53-a512-38aab25c61ad}
  - Writer instance ID = {c0c46d7b-1c01-44bd-8353-e3433f5b8f07}
  - Supports restore events = TRUE
  - Writer restore conditions = VSS_WRE_ALWAYS
  - Restore method = VSS_RME_RESTORE_AT_REBOOT_IF_CANNOT_REPLACE
  - Requires reboot after restore = FALSE
  - Excluded files:

...

..

+ Component "SharePoint Services Writer:\XXXX02\WSS_Content_at.contoso.local"
                                                - Name: WSS_Content_at.Contoso.local
                                                - Logical path: XXXX02
                                                - Full path: \XXXX02\WSS_Content_at.Contoso.local
                                                - Caption: Content Database WSS_Content_at.Contoso.local
                                                - Type: VSS_CT_DATABASE [1]
                                                - Is selectable: TRUE
                                                - Is top level: TRUE
                                                - Notify on backup complete: FALSE
                                                - Paths affected by this component:
                                                - Volumes affected by this component:
                                                - Component Dependencies:
                                                                - Dependency to "{a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}:\\YYYY06\YYYY06\WSS_Content_at.contoso.local"
                                + Component "SharePoint Services Writer:\XXXX02\WSS_Content_fw.Contoso.local"
                                                - Name: WSS_Content_fw.contoso.local
                                                - Logical path: XXXX02
                                                - Full path: \XXXX02\WSS_Content_fw.Contoso.local
                                                - Caption: Content Database WSS_Content_fw.Contoso.local
                                                - Type: VSS_CT_DATABASE [1]
                                                - Is selectable: TRUE
                                                - Is top level: TRUE
                                                - Notify on backup complete: FALSE
                                                - Paths affected by this component:
                                                - Volumes affected by this component:
                                                - Component Dependencies:
                                                                - Dependency to "{a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}:\\YYYY06\YYYY06\WSS_Content_fw.contoso.local"

the "02" machine is the alias name for the SQL Availability Group. "06" is the active SQL server and "05" is the readable secondary.

Hi,

We're going to set this configuration up in the lab and see what we come up with.  So you just used default instances when you installed SQL 2012 ?

Thank you so much!

Yes, default instance.

HI,

OK - After reproducing the issue and working with the DPM product group, at this time using SQL 2012 availability groups (AG) for Sharepoint back end is not supported by DPM 2012 Sp1.  We will have some public facing content on the limitation shortly.  I cannot say at this time if this will be fixed in a future rollup, it needs to be investigated by the product group.

Well, not the answer I was hoping for, but glad you could confirm it and I can't wait to see the rollup hit the site.  

thanks again for researching it.

Hoi Mike,

Is there any news yet about the investigation and date for a patch?

Kind regards,

Marinus Witbraad

Yes, I am also looking to a solution for this issue since it was stated that Always On was supported in SP1.

Hello All,

At this point, we believe it is a limitation in the sharepoint writer that prevents DPM 2012 Sp1 from protecting SQL 2013 Always-on databases. I don't have additional information at this time regarding any kind of fix.

Hello Mike,

can you contact me via Lync :). I would like discuss the issue with you.

Many Thanks

Stefan 

Hello,

We have a customer who would like to know when an update will fix this issue?

Thanks,

Dave.

I would like to know too.  It's getting to the point that people want to throw out DPM for our critical applications because it cannot adequately support them.  You'd think the DPM product group would have worked with the Sharepoint group on this.  Then again, DPM doesn't do native backup for any of the System Center products either... there's a good chance we will use it for file shares only and look at best-of-breed solutions for the other products.

Hello,

We are facing the same problem, currently we can only backup the database from AlwaysOnSQLCluster.

We can't backup using the farm protection.

Do you have some news about an update in order to fix this issue?

Thanks

Raphal

Hi,

This issue will not be fixed in System Center DPM 2012 R2, but possibly post R2. 

Hi Mike

Is backup of Sharepoint 2013 on a SQL 2012 AG-backend possible in DPM 2012 without SP1? I havent been able to find any information clarifying if this problem arised with SP1 or if it has been there from the initial DPM 2012-release.

And in that case, is it possible to downgrade DPM 2012 SP1 to DPM 2012 by  uninstalling it and reinstalling using the backed up DPMDB from DPM 2012 SP1?

Is there btw some site where its possible to find more information regarding this problem?

Regards

Matthias

Hi,

No versions of DPM (including DPM 2012 R2) support protecting SharePoint when using SQL always on AG.

Mike,

Do you know if there is any intention on MS behalf to add the support to protect SharePoint when using SQL always on AG in the near future (within the next 3-6 months)?

 

Any insight is appreciated.

Regards,

John

Hi,

It is my understanding that they plan to add support for protecting sharepoint using SQL always-on in DPM Vnext.  With that said, I do not have the timeline for that release and new features can sometimes get cut so  unfortunately I don't really have a good story you to tell at this time - sorry.

Mike,

I appreciate the follow-up. We are going to have to look at other 3rd party solutions in the meantime.

It will be interesting to hear technically why there is this limitation.

Wow, is this still the case?

We are just looking at creating a redundant back-end for our SharePoint 2013 farm, and AlwaysOn seems to be the best choice. But this is a bit of a brick wall.

So what are the supported options for a redundant SQL back-end backed up by DPM??

Still can't believe this is true tbh :-/

Just stumbled on this thread.. see this update on DPM with AOAG for SharePoint

https://technet.microsoft.com/en-gb/library/dn554221.aspx#BKMK_Sharepoint