Thursday, December 13, 2007 4:05 PMOur site is connected to a SQL cluster. I followed the instructions for installing it using a SQL cluster and all seems to be working fine except for Site Backup. It keeps failing because it can't reach the registry on the SQL server. However, I've got components apparently installed on both SQL nodes.Is there some special consideration that needs to be given to backups using a clustered SQL DB? I don't recall reading that in the backup and recovery docs.
Tuesday, January 15, 2008 9:48 PM
In this case, I would recommend backing each up separately. Backup the files and registry keys on the SCCM server, along with IIS and then use a SQL maintenance plan on the SQL server. Check out the following documentation on what specific directories to backup on the SCCM server -- http://technet.microsoft.com/en-us/library/bb633229.aspx. No need to stop the SMS SQL Monitor service, as it no longer exists in 2007 -- Microsoft just hasn't updated the documentation as of this time.
Wednesday, January 16, 2008 1:57 AMModerator
If you plan to do any out of band backups, be aware that the site server file system and the site database need to be taken at the same time with no site activity in between (offline backups). We don't have a published and supported procedure for third party backups with Configuration Manager, the only method supported right now is the built-in backup task.
We would prefer to help you through the SQL cluster configuration rather than set up an unsupported backup process that could leave you unable to recover a site.
Wednesday, January 16, 2008 2:03 AMModeratorIs the site server machine account a local admin as well as sysadmin on all SQL nodes? Is the remote registry service enabled on the SQL nodes? Any errors in the site accessing the SQL Server other than backup?
Wednesday, January 23, 2008 7:48 PM
I am experiencing this same error. I'm running SCCM on one server connecting to a clustered SQL server. One the backup attempts to run it fails and leaves the following four lines in the smsbkup.log.
Info: Sending message to start the SQL Backup...
Couldn't connect to \\SQLcluster registry
STATMSG: ID=5049 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_SITE_BACKUP" SYS=SCCMserver SITE=LHT PID=3400 TID=924 GMTDATE=Wed Jan 23 19:21:16.539 2008 ISTR0="" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
Error: Failed to send start message to the SqlBackup.
In my instance...to answer your questions Stan...
The site server machine account is both local admin as well as sysadmin on the SQL nodes. Remote Registry service is enabled. No other errors access SQL except for backup.
Thanks in advance,
Thursday, January 24, 2008 10:37 PMModerator
Is Kerberos enabled on the cluster? That is a requirement to connect, of course the usual SPN registrations also and permissions which it looks like you've already done.
Monday, January 28, 2008 3:42 PM
This is the same server that you responded to a different thread on related to SPN registration last week. The backup was failing with these errors both before and now after moving the site DB and getting the SPN registration taken care of on the new DB location.
What registry access is SCCM requiring on the remote clustered SQL server? The SCCM server (computer account) is an admin on the clustered SQL server. Or for that matter...is this possibly a misleading message that is coming up as the result of something else failing? If so...where should I look for more info?
Monday, January 28, 2008 4:32 PM
One more bit of info. I can connect to the registry on the SQL server running as my user context. But if I start the registry editor as local system (using the AT command to schedule it to run), when I try to connect to the SQL server, I get an error stating:
Error Connecting Network Registry
Unable to connect to SQLSERVER. Make sure you have permission to administer this computer.
Since SCCM is trying to connect as it's computer account, this is likely the root cause...although I still don't know what to do with it.
Monday, January 28, 2008 5:56 PM
After re-reading your response...I realized another question...
I assumed that if the SPN thing was working that the Kerberos question was answered, but perhaps not. How would I check that? All other SCCM and SQL functions appear to be working except for backup.
Thanks in advance,
Monday, January 28, 2008 6:55 PM
Run this query: select auth_scheme from sys.dm_exec_connections where session_id=@@spid, it must return Kerberos.
On another note can you validate where your SMS provider is installed?
Monday, January 28, 2008 7:13 PM
Ran that on the SQL server...it returns Kerberos.
SMS Provider is on the SCCM server (I only have one SCCM server in this environment.). The SQL DB for that SCCM server is on a remote SQL cluster.
Monday, January 28, 2008 7:25 PM
It would appear that durring the SQL installation process the VSS component of SCCM did not get installed on the Clustered DB. See here: http://technet.microsoft.com/en-us/library/bb693554.aspx
You need to make the computer account an admin on the cluster until the configuration can be completed.
You may not have to do this depending on to what level you folowed this process for moving the DB:
Monday, January 28, 2008 8:10 PM
When I installed initially, I followed all the steps in the first link you posted. I have verified all of the roles and
that the machine account for the SCCM server is in the appropriate roles.
How would I confirm that the "VSS component of SCCM" got installed? It sounds like this is not the same as the "Volume Shadow Copy" service...is that correct?
The initial install of this SCCM server was done to a named instance on this SQL cluster...so I would assume that any of that would have been taken care of by the SCCM installer. The machine account for the SCCM server has been in the local admin group on the SQL server since before the initial install (and it is still there).
Since I didn't migrate the DB from a non-clustered SQL to the clustered SQL...but did the initial install on the clustered SQL server...I don't know that the second link applies. And actually...I was never able to get the backup to work in the first place, so using the "Backup Site Server" mainenance task in that second link isn't an option anyway.
Wednesday, January 30, 2008 4:55 PM
It would have really helped if I had understood that Stan's initial comment regarding Kerberos on the cluster and SPN registration was not the same thing. I knew that SPN registration was necessary for SQL to do Kerberos authentication, and I jumped to the conclusion that this was what Stan was referring to. It's not.
Stan...thanks for your very accurate response. It was definitely that Kerberos had not been enabled on the cluster.
I did a more complete write-up of what I did on this issue with links to this post and key KB articles on my blog if anyone is interested.