Here While I am trying to connect SQL server after installation I am getting the following error.
How to rectify the error, I have tried to restart the SQL service but it is also showing logon Failure.
Then I found out a solution for the logon failure error is that we
need to rewrite the password again in Logon tab and save it. But my
problem is that where can I get the password or which password I need
to rewrite because I don't know the actual password written on that,
So ho Please help me on this.
As this is clearly a SQL Server configuration and not a database related question you should untag everything but sql-server ASAP. Also, you might want to ask future questions like these in the https://dba.stackexchange.com/ forum as StackOverflow is more development focused.
Having said that, to reconfigure the SQL Server service account you need to go to the SQL Server configuration manager via Start Menu or Computer Management. There you can double click the service to see its details. In this case you can (re)set the service account from the Log On tab (see screenshot), here you can choose between a built-in or a managed account. Important note: it is preferred to use a domain account. Managed or Local Service account with minimal privileges are second best. It is ill-advised to use Local System for security reasons.
Related
I can't connect to my Azure SQL Database that I have hosted on MS Azure.I have tried with Visual Studio and MSSM with no luck.
I can't seem to work out how I could possibly be going wrong. I allowed access to the server on all IPs.
I am using the correct login info.
I dont seem to be even able to ping the server, despite it showing no issues in the Azure interface.
The server is located at: kkbpeyaf0t.database.windows.net
I tried to connect to the URL you provided using SSMS and it gave me a login failed (which I expected), so that tells me that the database is running and that you did indeed open up the IP ranges to allow anything (which isn't a best practice, but I'm assuming you did this as part of your troubleshooting). IF the Azure SQL DB firewall was still in the way it would block immediately indicating so.
I would think that if you have the correct username and password combination it should connect. Make sure that your outbound port 1433 isn't being blocked by your own firewall (machine, work, ISP, etc.).
Azure SQL Database won't respond to pings.
Docs can be found on MSDN.
When I try to debug an Stored Procedure using Microsoft SQL Server Management Studio, I encounter this error message: Unable to start T-SQL Debugging. Could not connect to computer ("*"). The dubugger cannot connect to the remote computer. This may be because the remote computer does not exist or a firewall may preventing communication to the remote computer. Please see help for assistance.
I really appreciate any help.
SSMS needs to be able to find your SQL Server by DNS. When you connect to the DB in SSMS, you can use (local), but (local) does not resolve on your network so the debug program can not find it. Try connecting to localhost or your computer's name on the "Connect to Server" screen.
You should not have to run as administrator.
I just wanted to pay this forward, as after searching for quite some time I've yet to see anyone mention the problem that I encountered here.
I ran into this issue while connected to SQL using a SQL Server Authenticated user. Once I tried using a Windows Authenticated user I was able to debug without issue. That user must also be assigned the sysadmin role.
Hope this helps someone.
There's still problem in MSSQL 2012 if you want to debug a query connected to server via some defined alias. You need to connect to that server with the full name of the server first and then the debugger finds the server - otherwise it doesn't.
Simple way to just go to the database-> security->login->right click on the login and add your name and check the service role as public and sysadmin. more reference Unable to start T-SQL Debugging
I had this issue, I was connected to the server through RDC, and when connected to the instance I simply used '.', which failed. Then I tried 'SQL12P1' with and without port number, which failed. I then used 'localhost' and this solved my issue.
For local debugging (and I think for remote debugging too?) the Windows account under which you are running SSMS also needs to be set up as a SQL Server login and be a member of the SQL Server sysadmin role, in addition to this being required for the account (Windows or SQL Server) which you are more apparently using to connect to SQL Server, where these are different!
If not, you still get the same error message asked about in this question.
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/s0fk6z6e(v=vs.100)
Run Microsoft SQL Server Management Studio as User Administrator mode. You will not get this error while debugging. And You can debug stored procedure. This helps to solve my problem.
I have been trying to run debugging within SQl server management studio and for some reason the debugger has just stopped working.
This is the message I get:
Unable to start the Transact-SQL debugger, could not connect to the
database engine instance 'server-sql'. Make sure you have enabled the
debugging firewall exceptions and are using a login that is a member
of the sysadmin fixed server role. The RPC server is unavailable.
Before this I get two messages, one requesting firewall permissions and the next says 'usage' with some text that makes little sense.
I have looked at the other similar answers on there for the same message which suggest adding the login as a sysadmin but that is already set. I also tried adding sysadmin to another account but that also didn't work.
In the end I was able to start it by right clicking and selecting run as administrator.
I encountered this issue while connected to SQL using a SQL Server Authenticated user. Once I tried using a Windows Authenticated user I was able to debug without issue. That user must also be assigned the sysadmin role.
This happened to me and I could not find the resolution anywhere. My firewall is disabled so I knew that couldn't be the issue.
According to Microsoft: Configure firewall rules before running the TSQL Debugger:
The server needs to communicate back to the client via RPC. The
account under which SQL Server service is running should have
authenticate permissions to the client.
We had a group policy that was preventing this:
Deny access to this computer from the network (Local account, Guests)
In order to resolve the issue, I had to add the SQL Server service account to the local group "Remote Desktop Users" on my desktop. Hope this helps someone else resolve this frustrating issue.
I try with the following steps, but it did not work (maybe because I'm on a PC in a office and I don't have control of the firewall). But you can try the following.
Check the users role:
IF IS_SRVROLEMEMBER ('sysadmin') = 1
print 'Current user''s login is a member of the sysadmin role'
Follow these instructions:
configure the transact-SQL Debugger
Run SQL Server Management Standard Edition 64 bits (with SQL Server Account)
In my case, I received this error message:
Unable to start the Transact-SQL debugger, could not connect to the computer "local".
I end up close the existing connection, then reconnect to my local SQL server using IP 127.0.0.1 and it works.
What helped me, was from here:
SQL Server Management Studio must be running under a Windows account that is a member of the sysadmin fixed server roll.
The Database Engine Query Editor window must be connected by using
either a Windows Authentication or SQL Server Authentication login
that is a member of the sysadmin fixed server role.
So, I've added sysadmin role to my windows account and run ssms as administrator. Debugger started working normally.
In addition to above works, what make our 2 computers remote debug able, was running: (right click on Window's Start button)
System--> Advanced System Properties-->Computer Name-->Click on Network ID... button
and running that wizard to join workgroup on both computers.
I found this solution by looking at my Windows' Event Viewer and looking for a solution to errors with NetBT Source, that is related to workgroup and computer Name.
Update: after some days, it stop working again.
I had the same problem and double checked al recommended settings. At some point I disabled the firewall on the database server and it worked like a charm. By enabling and checking the Firewall log I noticed this entry:
2019-10-31 16:07:50 DROP TCP 192.168.xxx.xxx 192.168.xxx.xxx 65231 61214 52 S 56576751 0 8192 - - - RECEIVE
When I allowed TCP port 61214 (Inbound rule) and switched the firewall back on, it worked. I don't know why this port is needed, maybe some here on SO?
Anyway, maybe the firewall log can be of help too.
Struggled through many hours and got the answer
You can do the configuration through this doc
https://learn.microsoft.com/en-us/sql/ssms/scripting/configure-firewall-rules-before-running-the-tsql-debugger?view=sql-server-ver15
(1) 2 settings need to done on the remote server where Sql server is installed
(2) 1 setting at client computer (i.e) our computer
I installed Windows Server 2008 and SQL Server 2008 R2, after joining to domain I changed computer name and mistakenly I deleted the administrators group from SQL Server login users and now I am not able to login.
Any suggestion?
I know this is old but I just used the Gui instead.
Step 1. Start SSMS
Step 2. Select the server name drop down and click browse more.
step 3. select local or network tab based where the server is and expand Database engine and select the correct computer name\sql server
Follow the steps in this article: http://v-consult.be/2011/05/26/recover-sa-password-microsoft-sql-server-2008-r2/
Basically you have to modify the SQL Server Service settings so that it starts in admin mode. This will only allow one connection to it. Once you start it up you can create a new sysadmin user that you can use from then on.
Also I do know that you need to run certain scripts on a SQL Server if you change the hostname of the server. You should find them if you google them.
If you have mixed mode authentication enabled on the SQL Server instance, you can login using the sa account, with the password that you specified during installation.
If you have only Windows authentication enabled, I'm not sure. You could try running setup again and seeing if it will let you change the authentication mode, but somehow I doubt that it will let you do anything without first connecting to the instance with your Windows identity.
As a last resort, you could try uninstalling and re-installing the SQL Server instance, then re-attaching all your databases.
Add the new name of the computer and you should be able to login again..
Is it wise to use Domain Administrator as a SQL Windows Authentication log-in?
No. Local admin, perhaps, yes: never domain admin
For example, xp_cmdshell would allow complete control over AD and your environment. CLR code could do the same. Although these are disabled by default, you can't rely on that to protect your entire network.
Edit:
Logging in as a user as domain admin is no different to using Exchange or similar with the same acount. For SQL Server. no extra rights are conferred or implied because all permissions are defined within SQL Server.
So if you only have a "SQL Server Admin" group as sysadmin, and the domain and local admins are not in this group or set up as logins, then they get normal user rights as per their login. Or they can't even connect.
Of course, as domain or enterprise admins they could just add themselves to the "SQL Server Admin" group... but this requires an extra step and restricts your sysadmin to the correct admin group.
After all, you wouldn't let me as SQL God near your Exchange server...
I think some of the posts have assumed you mean to run the SQL Server service under a domain administrator account (which I agree, would be a security hole), but as you have said in your clarification, it is just to log in to do stuff against the database, I don't see a problem with it....As long as the user in question (I'm guessing it's you here), knows not to drop the production database etc.!
Certain things you need to do against an install require DBA priveleges, if you acquire those by being a domain admin, then what difference does it make?
a. If you have no security problems than - it doesn't matter.
b. if you are connected to the internet, you shouldn't. someone can attack your domain using holes in sql code if the app you're using uses the domain admin authentication. or if someone get access to your administration machine.
c. there is no linkage between domain admin and sql server admin - so why do it ?
Just to be clear - It is not wise !
In my opinion, I wouldn't use an Administrator account for anything management related (that's my Linux background telling me that root accounts shouldn't be used).
It depends a lot about - well - your size and security practices. It does show a security risk, but whethe rit is wise o wnot depends on the rest of the setup.