March 13, 2009 at 2:54 pm
I'm in process of trying to install Symantec's Backup Exec software. The installation process requires the creation of an MSSQL database either locally or remotely. I'm
trying to connect to a SQL 2005 ( not sql express ) box to allow the Backup Exec software to create the database. I keep getting a connection failure message.
I've checked all the well known causes for this error and still can't seem to obtain
a connection to the the SQL box. I've been using a domain account that also has
local admin privileges on both the Backup Exec and SQL boxes. The domain account
has also been added SQL as a "Login" account with "sysadmin" rights.
If the following info helps. I'm trying to install Backup Exec v12.5 on a W2K3 w/SP2.
I would like to create a database on a remote SQL 2005 w/SP3 installed on a W2K3 w/SP2.
Any suggestions or help would be appreciated.
March 13, 2009 at 4:02 pm
John an errors in the SQL Server error log? Can the two servers communicate? Firewall issue? Port issue?
Thanks.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
March 13, 2009 at 4:18 pm
What is the error you are getting?
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 14, 2009 at 10:52 am
To answer both replies i've disabled the windows firewall on both boxes. This was my first guess.
The error message reads....
[font="Arial Black"]"Cannot connect to Microsoft SQL Server COM-COMSQL. On remote SQL Server, verify that:
- Remote client connections are allowed
- The user who is currently logged on this system is a member of the Administrators group on the SQL Server COM-COMSQL.
- If the SQL instance is behind a firewall.........etc."[/font]
March 14, 2009 at 1:20 pm
Verify that you have enabled remote connections to this instance of SQL Server. Also verify that you are connecting to the right instance.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 14, 2009 at 1:50 pm
It is enabled under the server properties. I've done some additional troubleshooting with the help of Symantec and noticed that a SQL account connects just fine. Created a "UDL"
file and noticed the "sa" sql account or any sql account i create works and connects.
There seems to be an issue with the Active Directory domain accounts i wish to use for
the setup of the database.
March 14, 2009 at 1:54 pm
Check the error logs to see if there are failed logins?
Check http://sqllearnings.blogspot.com/2008/10/error-18456-severity-14-login-failed.html. If there is an error 18456; that article can help you narrow down where the error is.
If there is another error in your SQL Error Logs post those here please. Thanks.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
March 14, 2009 at 2:04 pm
I've looked at both the SQL Logs and Event logs in Windows. It keeps indicating a failure to
logon the user account "AD\comcss". Once again, the account has local Admin privileges
and i've added it under SQL security "Logins".
March 14, 2009 at 2:49 pm
And what permision did you give it? When you try it from app does it return to you saying login failed with state information?
Mohit.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
March 14, 2009 at 7:16 pm
Thanks for all the assistance. Finally found the solution. The problem lied with the registration of the
Service Principle Name ( SPN ) for the SQL server instance with the SQL service account being used in the Active Directory.
The link to the article below explains it better than i ever can. Hope this helps others who come across the same issue. In essence if you change the account that the SQL services run under from either the "Local System" or "Network Service" account the SQL server instance does not get published in
the Active Directory to allow authentication via domain accounts.
[url=http://www.myitforum.com/articles/18/view.asp?id=10857][/url]
March 14, 2009 at 8:09 pm
Thanks for the link.
WHen you changed the service account for your SQL Server where did you change it from?
SQL Server Configuration Manager?
or
Windows Services?
Thanks.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
March 16, 2009 at 6:53 am
It appears it's best to make the change via the SQL Configuration Manager. According to some articles
the SQL utility ensures the account is updated in the required registry keys and other locations.
March 16, 2009 at 8:43 am
Yeap :). SQL Server uses local groups to grant permissions so most of them are there. If you change the service account the tool adds the new service account to the proper local group on the server.
Thanks.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
Viewing 13 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply