DPM 2007 protection Sharepoint 2007 -

We currently are unable to protect our sharepoint environment correctly through DPM 2007 SP1:

This is our setup:

SharePoint 2007
2 WFE servers and 1 Index server running on Hyper-V, farmed  and clustered via MAC address cloning
Windows 2008 R2
Domain : domain.ltd.uk

1 SQL 2005 cluster (2 SQL servers mirrored for failover) hosting the SharePoint DB's
Windows 2003 R2
Domain : domaininternal.co.uk

1 DPM 2007 with SP1
Windows 2008 R2
Domain : domaininternal.co.uk

The reason I mention the domains is that I think this is what’s causing the issue.

We’ve followed the guide to enabling protection on the SharePoint farm by running “configuresharepoint.exe –enablesharepointprotection”, etc and installed every hotfix/service pack we can find to hopefully resolve the following error to no avail.

The error we receive when trying to protect the FE server:

DPM is unable to protect your Windows SharePoint Services farm until you install agents on the following servers : OUTSQL.domain.LTD.UK.

To install agents on these servers, on the Agents tab in the Management task area, click Install in the Action pane. If any of the above servers correspond to a cluster or a mirror, you need to install the DPM protection agent on all the physical nodes of that cluster/mirror. If databases are mirrored and SQL aliasing is used then you can get more information on SQL aliases that could not be resolved for the SharePoint farm by running "ConfigureSharePoint.exe -ResolveAllSqlAliases" on the SharePoint front-end web server.

ID: 956

We have not setup aliasing but have run the command above just in case.  We have looked at aliasing as a possibility to resolving this issue.

What I think is happening is that DPM asks SharePoint where it's SQL DBs are, and it replies with "OUTSQL" (as this is what appears in the SharePoint farm, no FQDN), and DPM assumes that the SQL Cluster must be on the same domain as the SharePoint farm and so it cannot find the DB server (as the FQDN for our SQL server is OUTSQL.domaininternal.co.uk and not OUTSQL.domain.LTD.UK).

The SQL Cluster databases are being backed up so DPM can definitely see it. So this is why I think it's SharePoint feeding the wrong information to DPM.

If we ping OUTSQL from DPM and SharePoint it will resolve the correct SQL FQDN and IP addresses.

On a similar note, after installing the agent on the SharePoint servers, DPM does not recognize it as a farm ... we also think that this might be causing the issue.

I can provide more information or clarification of the above if necessary as I appreciate it's not well laid out.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ted BouskillSenior Software DeveloperCommented:
I think this is an issue with your use of DNS names.

I would have recommended setting up Sharepoint using the FQDN for the SQL servers.  That is what we did to avoid this type of problem.  I'm always recommending that entire Sharepoint installations be created using FQDNs.

I wonder if as you assert DPM somehow things the OUTSQL is simply a NetBIOS name and isn't resolving it correctly.

You could try adding an entry in the Hosts file for the servers to resolve OUTSQL to the IP of the SQL servers OR you could use the SQL Client to create an alias entry on each server to correctly resolve to the SQL servers
redfire0082Author Commented:
Thanks for that tedbilly.

I suspected as much and we attempted to edit the hosts file on 1 of the SharePoint front-end servers which didn't make a difference.  At this point we started to look into SQL aliasing but we're not sure of the implications.

From my limited understanding of aliasing, is it right to assume that we put the alias of "OUTSQL" pointing to the IP address of the cluster ? or is it better practice to use the FQDN of the SQL cluster as the pointer?  I also read that you can use MDAC instead of the SQL Client ...

I know that SQL aliasing is seperate to SharePoint but is there any possibility that it would stop the instance working?  What we don't really want is to find it doesnt work, try to back out and find that we need to re-configure sharepoint because it can no longer find the DB without an alias.

Any URLs would be greatly appreciated so that I can get a better understanding of aliasing.
Ted BouskillSenior Software DeveloperCommented:
Here is a link: http://blogs.msdn.com/sql_protocols/archive/2007/01/07/connection-alias.aspx

Sharepoint servers can handle loss of connectivity to the SQL server without requiring a rebuild.  For example, what if someone accidently unplugged the NIC card on you Sharepoint server or the switch died?  Connectivity would be lost but the farm shouldn't collapse.

There was another question on this site I participated in wherein the user wanted to move the Sharepoint SQL instance to a new server as an upgrade.  They used the server name in the original installation instead of a FQDN so they use SQL Client Aliases to redirect Sharepoint to the new SQL server without problems.
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

redfire0082Author Commented:
Thanks for keeping with this mate.

Today I setup a test Sharepoint site to see if the alias would work.  Once we created the SP site I installed the DPM agent, applied any patches, ran the configuration which MS recommends.

I then went into DPM to verify that this test SP site would give the same error, and it did.

Aliasing didnt seem to work for us though.  These are what we tried:

Alias    : OUTSQL
Server : OUTSQL.domaininternal.co.uk

Alias    : OUTSQL.domain.ltd.uk
Server : OUTSQL.domaininternal.co.uk

We configured these with cliconfg.exe then ran "ConfigureSharepoint.exe -ResolveAllSqlAliases".  DPM still returned the wrong FQDN.

On a plus note we have managed to get it working by running this command on the SP server:
stsadm -o renameserver -oldservername outsql -newservername outsql.domaininternal.co.uk

This allowed DPM to see the correct server and it worked fine.  Ideally though, we would really like this to work through aliasing.  

I'll continue looking for more info regarding SQL Aliasing but if you can see where I'm going wrong or have any other suggestions please let me know.
Ted BouskillSenior Software DeveloperCommented:
It looks like you are trying the correct steps.  I wonder if DPM is circumnavigating the alias by trying to consume the Sharepoint API.

It might be a flaw in the product.  I've experienced this exact same issue with a few products that were supposed to scan my Sharepoint farm and provide details and it never worked with my production farm which is clustered.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
redfire0082Author Commented:
Appologies for the late reply, I've been looking into the aliasing to see if there's any possible way we could use this process but it's looking more and more like a dead-end.

Just before we close this question though, can you give me an idea of what the following command will do:
stsadm -o renameserver -oldservername outsql -newservername outsql.domaininternal.co.uk

Obviously it just renames the current server to a new name (and this is what works in our test instance), but is there a chance that it'll have a negative effect?  

From what I've seen the command looks pretty standard.  And as we have 3 servers in the farm (2 Front Ends and and Index Server), I assume we would need to run the command against all 3?

Ted BouskillSenior Software DeveloperCommented:
I've never tried it so the risk is that it fails on your farm.  According to Microsoft it has to be run on every farm server if the SQL server hosts the configuration database.

I'd create very complete backups before trying it.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.