Friday, May 13, 2011

GUIDs in SharePoint Database Names and DPM 2010 - Left hand doesn't know what the right hand is doing


One complaint about SharePoint 2010 that I have heard consistently for the last year from students in my Upgrading SharePoint 2007 to SharePoint 2010 class is that the "Configure Your Farm" wizard automatically adds GUIDs to the name of a number of the new Service Application databases:

SharePoint 2010 database names with GUIDs appended
  

This problem has been written about and discussed on many other blogs, and so I am not going to go into a full explanation here of why it happens.  Suffice it to say that it is a concern of varying degree for many SharePoint Server farm administrators and SQL Server DBAs.


My experience is that for organizations that used a shared SQL Server for their SharePoint databases, because of this issue, using the Configure Your Farm wizard can be a non-starter because of the inability to specify the database names in conformance with the organization's database naming standards.  In many of these organizations, the SharePoint Server administrators feel "cheated" by Microsoft because they can't take advantage of the time savings of the Configure Your Farm wizard.

For other organizations that have a dedicated SQL Server for their SharePoint databases, the issue may just be an annoyance and they will decide to take advantage of the Configure Your Farm wizard anyway and just live with the weird looking database names.  

So, to a certain extent, this issue can frequently boil down to personal preference, except when it starts to impact the ability to easily backup and restore the SharePoint databases.

Those GUIDs can really be a royal pain for a DBA when it comes to creating and maintaining backup and restore scripts.  And, as I found out this week, it can really be a royal pain when using Microsoft's own System Center Data Protection Manager 2010 backup and restore product. (This is where the "Left hand doesn't know what the right hand is doing" phrase comes from in the title of this post).

Apparently, the System Center Data Protection Manager 2010 product team did not communicate with the SharePoint Server 2010 product team all that well and vice versa, because here is the error message you get when you have DPM 2010 back up several of the wizard-created SharePoint Server 2010 databases:

Data Protection Manager (DPM) 2010 error message when SharePoint database names are too long


Those darn GUIDs make the names of several of the Service Applications databases too long for DPM 2010 to handle!  And, according to this post on Microsoft's SharePoint forums there is no solution besides renaming the databases and re-configuring SharePoint.  The prospects of having to rename the databases IS A BIG DEAL in my mind.  I have yet to see a really safe and sure fire procedure published anywhere that I would be all that comfortable following in a production environment.

Here is the thread from the Microsoft forums:


I will have to say that I love SharePoint Server 2010.  I also love Data Protection Manager 2010.  But, right now I am not loving them as a couple :(.