We have some deployment scripts that use a combination of dacpacs through sqlpackage and straight scripts using sqlcmd.
When I execute the sqlpackage dac\sqlpackage.exe /p:BlockOnPossibleDataLoss=False /p:BackupDatabaseBeforeChanges=True /a:Publish /sf:.\somedeploy.dacpac /tcs:"Data Source=MyDB;Initial Catalog=MyCatalog;Trusted_Connection=True;"
I get an error message *** Could not deploy package. Unable to connect to target server. I have login auditing turned on in sql and the message I am getting is Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 111.222.223.224]
However, I can run our sql scripts through sqlcmd no problem by using the -E argument.
sqlcmd -i Permissions\CreateSqlUser.sql -S MyDB -E
I am running from a commandline that is set to "Run As Administrator" and am currently signed in as the admin. This is running on a Windows Server 2012 VM. I am using sql 2014. We have other installs that haven't had problems but this is our first 2014 install so we are trying to determine if something changed or if we are missing something and if so what.
If I run from profiler I don't see any audit log error messages. I checked the filters and what events I'm listening for and they all look good. Inside sql when I run exec sys.sp_readerrorlog 0, 1, 'Login Failed' I do get the messgaes to show up. (I might be doign something wrong in profiler). Also they show up in the system event logs. I'm not seeing anyplace where it tells me anything about the user attempting to login though.
If don't use trusted connection for sqlpackage and instead use a username and password it works fine. However, part of what our deployment script does is create the users so our preference would be to not do this.
Related
I am a local Admin on my machine. Same old thing, my account wasnt added when SQL Server was installed, and I don't want to have to reinstall SQL Server. I went through this blog and it worked until I tried to log and run the commands via SQLCMD or SSMS. I got the error message
"Login failed for user '/'. Reason: Server is in single user mode. Only one administrator can connect at this time.."
I found this blog and added the application name after the m switch http://sqlserver-help.com/2013/12/06/help-how-to-fix-error-reason-server-is-in-single-user-mode-only-one-administrator-can-connect-at-this-time/. But no dice, I still get the above error. The User Account looks fine I guess, I am an Administrator.
Also, I had to start the cmd prompt as an Admin to start sqlserver in single user mode. OR else I couldnt have access to the log files that the instance was using and it was giving me an error to that. So I ran the cmd prompt as admin. But still, I am the same admin trying to run SQLCMD or SSMS. It shoudlnt be telling me there is already an admin logged in, because I am that admin. What am I missing?
This is on SQLExpress, I dunno if that matters
Thanks!
First login to the server: "sqlcmd –A –d master"
.
connect to the master database with the DAC because master is guaranteed to be available if the instance of the Database Engine is started.
Shut down the database server and restart it with minimal configuration:
sqlservr.exe -f -s <instancename>
If it works fine, then you have a problem with your startup configurations and you need to find out which is causing you the issues.
My stored procedure in SQL Server 2008 R2 runs queries on several local and several remote databases (via linked servers) and works fine when I exec it while in SSMS.
When I run the same exec from a sqlcmd script the linked server connections fail with error...
Cannot initialize the data source object of OLE DB provider "SQLNCLI10" for linked server "BLAHBLAH.BLAH.BLAH.ORG".
The sqlcmd invocation is...
sqlcmd -U sa -P myPassword-S localhost
-i C:\SS_DB_TRACK\job_run_periodic_nightly.sql
-o C:\SS_DB_TRACK\job_run_periodic_nightly.lst
Thanks much if someone can advise me on how to get the sqlcmd script to work.
Jay
The difference you are seeing is most likely due to running in a different security context. The sqlcmd parameters you have show it logging in as sa (usually not a good idea). So if you are seeing different behavior in SSMS then you are probably logging into that same server using Windows Authentication. If you logged into that server, via SSMS, using SQL Server Authentication as sa, then you should see the same error. Along those same lines, if you switch the sqlcmd authentication to be -E for Trusted Connection (i.e. Windows Authentication), then it should work (and it appears that this did, in fact, work). If you prefer that this process not be run under your security context then you need to check the security setup of the Linked Server to see why the two different Logins get different responses from using the Linked Server. Ideally you would use another non-sa Login for the process, possibly even create a Login (that is not a member of the sysadmin server role ;-) to handle this process.
Instead of "LinkedServerName" try [LinkedServerName]
In SQL server 2014, I try to invoke a sql script using command line:
~ osql -U sa -P passwd -i script.sql
and I get an error message:
Login failed for user 'sa'
OS Error 997 Overlapped I/O operation is in progress.
However, when I run the command in interactive mode:
~ osql -U sa -i script.sql
it asks for password and the command succeeds. Can someone please help me how to run sql scripts purely from command line without user intervention?
thanks.
I just ran into a 997 error when using osql as well. It would appear that osql is not reporting errors correctly, giving error 997 instead of a more helpful error. Presumably this is due to it being deprecated.
In my case, the actual cause was the Server Authentication mode being set to "Windows Authentication mode" rather than "SQL Server and Windows Authentication mode". This can be changed by connecting using SQL Server Management Studio and going into the top level properties for the connection, then selecting the Security page.
Additionally, I had to enable the sa login, via Security -> Logins -> sa -> right click -> Properties on the Object Explorer, then setting the login to Enabled using the Status page.
This happened to me, and it came down to the wrong password.
I also had the same issue. I tried sqlcmd instead of osql and it gave me a more understandable error, in my case the problem was that I was using the wrong password for that particular database.
My advise is that if anyone comes across a similar issue, use sqlcmd which is the successor to the osql command. Also use a -o so that you get a text file with the output of the problem.
I am working on SQL Server 2008 R2 Express, when I am using SQL Server debugging feature from client pc, this error occurs:
The EXECUTE permission was denied on the object 'sp_enable_sql_debug', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)
My user name is 'HALI' and permission is assigned to me is 'public' and 'db_Owner',
now after this error I have assigned all permissions available. And all server roles.
Now at this time I got new error message,
Error HRESULT E_FAIL has been returned from a call to a COM component. (mscorlib)
Now what the solution would be for this error.
I am not sure if disabling firewall is enough. if the user has sysadmin permissions and still getting this error means client is not able to connect to server in debugging mode. check this TCP and UDP ports are correctly open.
SQL remote debugging configuration
EDIT:1
I am sure you must have also googled a lot and tried to find out about the error messages.
What I have found so far is the Error in the OP you mentioned is misleading and from that error, we cannot tell what exactly is wrong or what to look next. But as you replied in the comments, after making changes to enable Remote Debugger; the mentioned error is more clear and I feel that proper permission is still an issue. Plenty of other suggestion you also might have tried so far, but if you haven’t done this, let's try one more time:
In one of the comments I mentioned you to try login using the windows user.
Now Keep the settings you already did for TCP ports, Firewall Exception, etc… explained in the above link.
you have windows 2012 server where you installed DB server. and windows 8 Prof where you have DB client and you connecting through SSMS. Now I believe both machines are in the same domain. Let’s say domain XYZ. You must have windows login on server, let’s say it is “XYZ\HALI” using which you can login to the Windows Server. log in and make sure that login also exists in SQL SERVER with sysadmin permission. Because client machine is also in same domain make sure you have logged in into the client machine using same user “XYZ\HALI”. Now start SSMS and choose windows authentication instead of SQL SERVER authentication. Try to start Debugging T-SQL code now.
if client and server machines are not in the same domain then we have to register server name on client machine as Linked Server, impersonate the login/user as local and then try the debugging.
Edit:2
I encountered this problem after generating a SQL 2012 script and running it in a SQL 2008 R2 database.
After some research, I found out that my target SQL 2008 R2 was running on a 32-bit OS which supports a file of up to 2GB in size. So I saved the script as C:\myScript.sql and successfully executed it in a command prompt with these steps:
Open a command prompt window.
In the command prompt window, type:
sqlcmd -S myServer\instanceName –U yourUserName –P yourPassword -i C:\myScript.sql
where myServer\instanceName is the instance name. Supply the user name and password for SQL server login, and finally the path of the file as indicated.
Press Enter.
References:
sqlcmd Utility | Microsoft Docs
Use the sqlcmd Utility | Microsoft Docs
The few times I've run across that error, it's always been firewall related. Are you working on a remote server, or your local machine? (Parenthetically, be careful assigning all possible roles. Some of them are ones you absolutely don't want. The one you need for SQL debugging is sysadmin - try disabling the rest of the roles you checked off and just assigning that one.)
Debugging procs is always a pain. This ASP.NET post helped me out substantially awhile ago.
We are running deployment scripts using pstrami. Part of the deployment is to execute database migrations. The migrations are using an connection string with Integrated Security.
When the script executes on the remote machine the migrations fail with a sql error saying Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
The person executing the script is a domain administrator. Other deployments that we run execute the remote scripts with the user who started the process.
The problem is that the credentials are not hopping to SQL Server for integrated security. You need to do the following:
On the server (the one that is making the SQL Server connection, as administrator run:
Enable-WSManCredSSP -Role server
On the client machine, as administrator run:
Enable-WSManCredSSP -Role client -DelegateComputer YOUR_SERVER_NAME
To open this up to all servers, you can run:
Enable-WSManCredSSP -Role client -DelegateComputer *
Finally, your invoke command make sure you run -authentication credssp. An example:
invoke-command -computername $remoteServer -authentication credssp -scriptblock { write-host "hello!" } -credential $credentials
This is the scenario:
You run the pstrami(deployment) script from desktopA. The script pushes your installation files to serverA. Then on serverA the scripts are run remotely as the person inititating the script from desktopA. One of the steps is to run a sql database upate with fluentmigrator using a connection string paramter using "integrated security" and the database is on serverB.
Connection string example:
$migration_db_connection = Data Source=serverB;Initial Catalog=PropertyDb;Integrated Security=SSPI;
.\migrate.exe /conn "$migration_db_connection" /db SqlServer /a $migration_assembly /profile DEBUG
Pstrami uses the powershell command invoke-command which uses the account you are running the script under as the default user. So, what happens is that when you run the script from desktopA as "jonDoe" it then authenticates on serverA. So your pstrami scripts run under "jonDoe" on serverA. When you execute the fluentmigrator script on serverA as "jonDoe", fluentmigrator returns an error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. In IIS, you run into an interesting situation when you need to access another resource off of the IIS server and certain fairly common situations occur. When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a Windows security measure kicks in and doesn't allow your site to access resources on any network servers. (http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx)
This is how I got around the Windows Authentication and the Double Hop problem I ran into. Run your migration scripts directly on your sql database server and include it as a server target in your pstrami environments.
Example:
Environment "dev" -servers #(
Server "serverA" #("InstallWeb")
Server "serverB" #("RunMigrations")
)
More on Double Hop
http://www.spdoctor.net/Pages/message.aspx?name=login-failed-for-user-bdc
http://www.sqlservercentral.com/blogs/sqlsandwiches/2011/06/20/double-hop-of-doom/
I am not able to comment on your question and posting this as an answer. I will update the same later.
It may be due to SQL Server not having the login account for your windows login account. If that is the problem please add the logged in user to the SQL Server in the remote machine.
If this is already addressed, then you have the option of giving Rights as DB_Owner to " NT AUTHORITY\ANONYMOUS LOGON " on the SQL Server as well as on the specific database you are using.