The error I'm running into first occurred when I tried to connect to my SQl server database in Toad for SQl Server. The error message stated The System cannot find the file specified.
I opened SQL Server configuration manager and the SQL Server was stopped. I tried to start it but it failed. Here is the error in the log:
2016-07-07 08:52:09.01 Server SQL Server is terminating because of a system shutdown. This is an informational message only. No user action is required
2016-07-07 08:52:10.25 spid20s Service Broker manager has shut down.
2016-07-07 08:52:10.25 spid20s Error: 17054, Severity: 16, State: 1.
Check the service account.
It might be invalid, wrong password or lack right to logon as a service.
Try login as localsystem just to eliminate this possibility.
Also check the SPNs.
Check if the SQL Browser service is running. If yes then stop it and
disable (if you are using only one default instance.)
I had the same issue and after stopping/disabling the SQL Browser
service; it worked for me.
The SQL Server Browser Service is installed often in Disabled state (It is preferred to be disabled unless required).
It is only required for named instances or instances listening on non-default ports.
Your application installer should only restart the Browser service if needed, and certainly should check for a disabled service and ask an administrator permission to enable the service .
Related
We're running SQL Server 2017 on EC2 instances in AWS, and the SQL log is showing these errors every minute or so:
Error: 18456, Severity: 14, State: 5. Login failed for user 'domain\computername$'. Reason: Could not find a login matching the name provided.
The SQL login that it's looking for doesn't exist, so that part isn't a mystery. The real questions are: what is looking for that login, why, and how do we re-configure things so that this login isn't required?
The IP ties back to the SQL Server machine itself. This is bloating our logs but also causing confusion and consternation downstream, as our SQL logs flow into SUMO (this is designed to audit for logins, detect penetration attempts, etc.)
After doing some research online, we stopped (and disabled) the Microsoft SQL Server "CEIP" services, as articles indicated that these could sometimes cause this, but the errors have continued.
I then ran a trace and, based on the process id that is consistently tied to these errors, determined that they are coming from Microsoft.SqlServer.IntegrationServices.MasterServiceHost.exe.
I've found various pieces of information online, like this (from https://social.technet.microsoft.com/Forums/en-US/e2d819ed-49dd-4e18-87f1-05a6dc86a8c6/error-18456-severity-14-state-5?forum=sqldatabaseengine): "NETWORK SERVICE and LocalSystem will authenticate themselves always as the corresponding account locally (built in\network service and built in\system) but both will authenticate as the machine account remotely.If you see a failure like Login failed for user 'DOMAIN\MACHINENAME$' it means that a process running as NETWORK SERVICE or as Local System has accessed a remote resource, has authenticated itself as the machine account and was denied authorization."
But I haven't found anything actionable relative to our specific case, where the source appears to be Microsoft.SqlServer.IntegrationServices.MasterServiceHost.exe, and/or what change(s) we can make to resolve this and eliminate the errors (we're really trying to avoid creating a "domain\computername$" SQL login just to resolve the issue).
SQL Server Integration Services 14.0 is running on the SQL Server machine under the account NT Service\MsDtsServer140. SQL Server Browser service is running under NT AUTHORITY\LOCALSERVICE. But the main SQL Server and SQL Server Agent services are running under dedicated AD accounts (and are administrators on the machine).
I am attempting to connect my Bamboo instance to SQL Server, but I am unable to do so because of the error Login failed for user 'Bamboo'. Investigation into the log files shown in the location
C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log\ERRORLOG
throws an error that I should not be getting at this stage of my attempted login. Server is configured for Windows authentication only. Currently able to login using same SQL Server credentials to access the database, just not via Bamboo.
The reason why this should not happen is because my server is already set up to do so, and I will list all of the steps that I have taken to prevent this error. In my localhost SQLEXPRESS server I have checked SQL Server and Windows Authentication mode. Once I restarted SQL Server, this worked as I was able to log in with the credentials that I added to a user called Bamboo.
The user I added is mapped to the database called BambooDatabase as a db_owner. The number of concurrent users is unlimited and I have tried disconnecting from SQL Server just to check if that was a problem, but still no difference. I added 2 more users with connect access and mapped to BambooDatabase.
I have went to the SQL Sever Configuration Manager and enabled TCP/IP and made sure that the IP addresses was pointing to 1433. And then configured my firewall to all access to 1433 as well. The fact that my error logs for SQL Server are appearing makes this seem that everything should be fine here. So with tested 3 users on SQL credentials everyone logged in successfully and all have the relevant permissions needed. All three gave the same error when trying to connect from Bamboo.
I am trying to connect to Bamboo like this:
Direct JDBC connection.
Driver class name: net.source.jtds.jdbc.Driver
Database URL: jdbc:jtds:sqlserver://localhost:1433;DatabaseName=BambooDatabase
User name: Bamboo
Password: SQL Server password
Checked overwrite existing data
Then once I click continue the log in error throws. Have I missed something here, I cannot see what I could do differently, I have tried to connect to SQL Server from Bamboo several different ways but have had no success. I am using SQL Server Express and the Bamboo version 5.11.3, I am testing upgrading from 5.11.3 to 5.15 with larges amounts of data which is why I am using that version.
Error from Bamboo is:
Error accessing database: java.sql.SQLException: Login failed for user 'Bamboo'.
Error from SQL logs is:
Login failed for user 'Bamboo' Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. [CLIENT: 127.0.0.1]
Are you running Bamboo en SQLExpress on the same machine? If not, you should look into the remote access configuration.
In the SQL Sever Configuration Manager, make sure that you entered 1433 for the IPAll entry as well. And start the SQL Browser service for good measure, this is especially important when using a names instance, but going after the errorlog folder you copy/pasted, that's not the case.
For testing purposes, you might want to disable the firewall all together and reactivate is after you get the connection up.
Another thing to try if you're connecting on the same machine, is use the loopback address 127.0.0.1 instead of the localhost alias.
I just rebooted my development server but when the server came back up, I can no longer connect to the DB.
I can't even connect from the Management Studio on the server.
So I check the services and the SQL Server (MSSQLSERVER) and SQL Server Agent (MSSQLSERVER) are not started. Starting them gives me an error
Windows could not start the XXX
service.
Any ideas?
EDIT: In addition, I ran the service from the command line and noticed this error:
2010-11-24 15:38:32.02 Server Error: 26055, Severity: 16, State: 1.
2010-11-24 15:38:32.02 Server The SQL Server failed to initialize VIA suppo
rt library [QLVipl.dll]. This normally indicates the VIA support library does no
t exist or is corrupted. Please repair or disable the VIA network protocol. Erro
r: 0x7e.
So I went into The Configuration Manager -> Network Configuration -> Protocols and disabed VIA. That allowed me to start it back up again... but I'm worried that is should be enabled...
-Evan
Check the event viewer and see if there's a reason logged for it not starting. I've seen something similar when the server runs out of available ram.
Since this is your dev server you probably don't need VIA service running, as long as SQL is started you should be ok.
Firstly check the event log
If these errors is shown
The SQL Server failed to initialize VIA support library [QLVipl.dll].
TDSSNIClient initialization failed with error 0x7e.
Then only disable your VIA protocol services from both.
SQL Native Client
SQL Server Network Configuration
After that restart you SQL browser service and SQL server agent service from SQL server configuration manager
SQL Server Reporting Services, in SSRS it seems like Schedules never fire, however a look at the SQL Agent reveals a permission issue related to not being able to resolve a user account.
Seems SQL Agent does not rely on caching or whatever voodoo Windows magically works.
link text
Fix is listed here...
edit --
Above is the fix I used to workaround this issue, has any one found any other work arounds or resolutions to this issue?
It seems that by default the SSRS Generated Schedules are run as this phantom user account. How do I change this default? Is SSRS creating the jobs as the user the service runs as?
Thanks Remus
I was running into the same issue. Here is how I fixed it.
Problem description
When setting an SSRS report subscription to run at a given time, I would wait for the time to pass and then find that the "Last Run" timestamp did not change. My subscription appears not to have run.
Relevant troubleshooting info
SSRS report subscriptions are executed as SQL Jobs that the Report Server web UI creates for you behind the scenes.
When looking at the job that was created for my report subscription, I saw that it always failed with the error:
The job failed. Unable to determine if the owner (domain\userName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user 'domain\userName', error code 0x5. [SQLSTATE 42000] (Error 15404)).
In the Sql Server Configuration Manager I could see that the "SQL Server Reporting Services" service was configured to run using an AD user account.
In the Sql Server Configuration Manager I could see that the "SQL Server" service was configured to run using a local Windows account.
As #Remus Resanu pointed out, the SQL error 15404 refers to an exception when EXECUTE AS context cannot be impersonated.
Solution
Bingo! #4 and #5 are the key to the problem. The SQL Server service (a local Windows user account) was trying to authenticate the user "domain\userName" in AD, which it could not do because it does not have the right/permission to access AD resources.
I changed the SQL Server service to us an AD user account, restarted the SQL Server and SQL Server Agent services, re-ran the SQL job and, blamo, success!
15404 is the exception when EXECUTE AS context cannot be impersonated. Reasons for these error are plenty. The most common reasons are:
when the SQL Server instance does not have access to the AD server because is running as a local user or as 'local service' (this would have an error code 0x5, ACCESS_DENIED)
when the SQL Server is asked to impersonate an unknown user, like an user from a domain the SQL Server has not idea about (this would have the error code 0x54b, ERROR_NO_SUCH_DOMAIN)
The proper solution is always dependent on the error code, which is the OS error when trying to obtain the impersonated user identity token: one searches first for the error code in the System Error Codes table (or fires up windbg, does a loopback non-invasive kernel debug connection and goes !error, which is what I prefer cause is faster...).
So, John... do you actually have a question, or just posted a random piece of partial information?
I did 2 things and it's now working.
1) Go to "SQL Server Configuration", change the "SQL Server Agent" - "Log On As" to match the "SQL Server" above.
2) Secondly, open "Microsoft SQL Management Studio", at the "SQL Server Agent", expand the "Jobs" and you should be able to see your created job. Right click on it and go to "Properties".
3) Change the owner to also match the "SQL Server Agent" above.
After, I'm able to execute the Maintenance Plan without any issue.
Just follow this steps in images
Greetings – To automate testing of our database SPROCs, we’ve been using dynamically created databases inside of a User Instance. This has been working very well – the build server and, until very recently, all the developers could all run the tests. However, one of our developer machines is now returning the following error when we try to connect to the user instance:
Failed to generate a user instance of
SQL Server due to a failure in
starting the process for the user
instance. The connection will be
closed.
Here is what the log file says:
2008-12-04 10:46:29.77 Logon
Error: 15372, Severity: 16, State: 1.
2008-12-04 10:46:29.77 Logon
Failed to generate a user instance of
SQL Server due to a failure in
starting the process for the user
instance. The connection will be
closed. [CLIENT: ]
What I’ve done to fix it so far
Deleted C:\Documents and Settings[username]\Local Settings\Application Data\Microsoft\Microsoft SQL Server Data
Changed SQL Service to run as “Local System” instead of “Network Service”
Uninstalled SQL Express, deleted ALL data directories (e.g. “MSSQL.1”), and reinstalled SQL Express
None of these “fixes” have fixed the problem. It used to work on the machine in question, and we would like not to have to repave it.
Please help!!!
Thanks - Jordan
Okay, I tried all of the above fixes again, and then I restarted the entire system and it appears to work. Strange! I had restarted my system in the past, but it looks like you have to apply these fixes first and then restart. I think I'll try switching the service back to logging in as Network Service.
Thanks - Jordan
I found the same issue on my azure VM. Then I opened the SQL Server Configuration Manager, opened SQL Server Network Configuration, -Protocols for and found that "Named Pipes" and "TCP/IP" were disabled. I enabled them, and the error went away.