2008-07-29 04:52 AM - edited 2015-12-18 01:43 AM
I get an error when selecting a Remote Verification Server on my Snapmanager Backup Server. My customer network has a firewall and i believe that errors coming from blocking ports.
Error code is:
Failed to validate SQL Server for verification. The SQL server (or SmSqlSrvr) could not be contacted.
Error Code: 0x800706ba
The RPC server is unavailable.
Also on firewall we have open the ports 1433 and 1434 (TCP) to both servers.
Thanks in advance
2008-07-29 08:38 AM
This can be caused by a number of factors, especially if there is a firewall involved.
Being that this is a remote verification server, it would require access to the volumes on the Filer in order to perform verification on the LUN's following the SMSQL backup.
First couple things I'd check would involve -
What error messages am I getting to the EventLogs
Confirm that my Verification server has access to the filer in order to accomplish the type of operations it will be performing
If this continues to be an issue in a production or going-prod environment, I would advise opening a case with NetApp support 888-4NETAPP ( 888-463-8277)
Thanks and hopefully this can get resolved soon!
2008-07-29 02:38 PM
What I was meaning was this – Does your remote verification server meet the requirements as dictated by the AdminGuide for SMSQL
Here is a link to the guide, and the pertinent section(s) – Let me know if you are able to receive this.
“Requirements for a remote verification server” on page 23
Once you ensure that is validated - Ensure that you have access to the volumes, so that you can mount the snapshots in order to perform the verification.
All other information I've supplied you is out-of-band via email.
Be sure to let us know if we're able to resolve this issue!
2008-08-01 12:41 AM
First off all i appreciate that you interesting about my problem.
I validate that server have the permissions, and validate also that with SnapDrive can mount a lun snapshot (Userdata lun).
Also i add localcomputer\userprofile to usermap.cfg (root permissions),
but the problem is the same.
also i am getting DCOM errors from windows event viewer....
errors: DCOM was unable to communicate with the computer "SMSQLRVserver" using any of the configured protocols.
and Side by Side: Dependent Assembly Microsoft.VC80.MFCLOC could not be found and Last Error was The referenced assembly is not installed on your system.
Thank you in advance
2008-08-09 03:57 AM
In order to run the SnapManager Backup and Restore functions, the
SnapManager service account must have sysadmin fixed server role privileges on
the SQL Server. This is usually addressed by giving the Windows user account
administrator rights on the SQL Server. You can meet this requirement by adding
the Windows domain account used by SnapManager to the system
administrator’s server role on the SQL Server.
SQL Server authentication: When using SQL Server authentication, the
SQL Server administrator must have sysadmin server role privileges on the SQL
Server instance. SnapManager for SQL Server requires that the database
administrator have the required privileges to mount and dismount databases,
back up data and transaction log files, and restore those same files. The system
administrator role fulfills all these permissions requirements.
Windows authentication: When using Windows authentication, the
Windows account that you are logged onto the system with must have system
administrator privileges on the SQL Server. This account is presumably the same
account running SnapDrive. However, some organizations give different
categories of administrators different responsibilities and therefore different
levels of access. For example, one group of administrators might run
Chapter 2: Preparing to Install or Upgrade SnapManager 27
SnapManager to manage the SQL Server databases while another group of
administrators might run SnapDrive to manage the LUNs. In this case, separate
accounts would be used for SnapDrive and SnapManager. The SnapManager
server would still run under the SnapManager user account.
Finally in my case Snapmanager user account and service account didn't have system administrator privileges on the SQL Server.