I am doing a double hop kerberos authentication from my iis to my sql server and for that I need the SQLEXPRESS service to run under a domain user.
Domain name: domain.test
service user: sqlSrv
sql server computer name : SQL
When I try to start the service this is the error I get:
Windows Could not start the SQL Server (SQLEXPRESS) on Local Computer.
For more information, review the System Event Log.
If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 17058.
The error I see in the Event Log is:
initerrlog: Could not open error log file 'c:\Program Files\Microsoft SQL Server\MSSQ.1\MSSQL\LOG\ERRORLOG'.
Operating System error = 5 (Access is denied).
Source: MSSQL$SQLEXPRESS
Event ID: 17058
I've set up the following SPNs:
setspn -L domain.test\sqlSrv
setspn -A SQLEXPRESS/SQL:1433 domain.test\sqlSrv
setspn -A SQLEXPRESS/SQL.domain.test:1433 domain.test\sqlSrv
initerrlog: Could not open error log file 'c:\Program Files\Microsoft SQL Server\MSSQ.1\MSSQL\LOG\ERRORLOG'.
Operating System error = 5 (Access is denied).
Obviously you just replaced the service account on an existing installation. This is not supported. You need to install the service from scratch, using the desired service account.
While theoretically you could go through Configure Windows Service Accounts and Permissions and figure out what permissions are needed (in fact, figure out what local groups the service account needs to be member of), that would assume that you know what the heck you're doing.
Do it by the book. Install the service to use the desired service account. Read and follow Install SQL Server 2014 from the Command Prompt. The service account install command line parameters are described here:
SQL Server Database Engine:
Service account: /SQLSVCACCOUNT
Accountpassword: /SQLSVCPASSWORD
I had this problem when I wanted to start sqlserver service.The event viewer showed this message as you mentioned.I did my best to set permission unfortunately it did not work for me.The problem was related to "ERROLOG",its size was about 1G and it there was not the file name such as "ERRORLOG.1,ERROLLOG.2,..", so I deleted after making backup of it.at the problem disappeared.
I hope it is functional for you.
Related
I have SQL Server 2014 installed on a Windows Server 2012 R2, which is also an AD DC. When I try to connect to it using SQL Server Management Studio (SSMS) from a client desktop on the same local domain, I got this error message:
The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server)
So following other posts on the same issue, I downloaded Kerberos Configuration Manager on the SQL server, which found 2 Misplaced SPN. The SPN Script commands proposed by the Kerberos Configuration Manager are as follows:
SetSPN -d "MSSQLSvc/SERVERNAME.internal.domain.com" "internal\SERVERNAME$"
SetSPN -s "MSSQLSvc/SERVERNAME.internal.domain.com" "DOMAIN\SERVERNAME$"
But when I tried to run the first command in cmd on the server (the "SetSPN -d" one), I got this error:
FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x0000054B
Unable to locate account SERVERNAME$
I'm not sure how to move forward from here. Googling around hasn't turned out the right answer. Please help. The questions are:
1) Is the misplaced SPN the culprit? If so, how to correct?
2) If not, how can I connect to SQL Server from a client desktop on the same local domain, using Windows authentication?
Ensure you are running the script from a machine joined to the Active Directory domain and the machine's DNS is resolving to AD correctly. To find SERVERNAME$, the machine needs to ask DNS for the location of an Active Directory domain controller to query. The SPN Script is also wrong.
Get rid of the quotation marks, they're not needed in this context, especially given that there are no embedded spaces to enclose.
Ensure you are logged into the internal domain in order to run the first command. The 2nd command is run while logged into DOMAIN.
I think the suggested script of:
SetSPN -d "MSSQLSvc/SERVERNAME.internal.domain.com" "internal\SERVERNAME$"
SetSPN -s "MSSQLSvc/SERVERNAME.internal.domain.com" "DOMAIN\SERVERNAME$"
should have been this instead:
SetSPN -d MSSQLSvc/SERVERNAME.internal.domain.com internal\SERVERNAME$
SetSPN -s MSSQLSvc/SERVERNAME.internal.domain.com DOMAIN\SERVERNAME$
I just tested the second line in my environment and it worked. I don't need to obfuscate my test environment, so it actually was the following:
SetSPN -s MSSQLSvc/dc1.dev.local DEV\dc1$
...and the result:
Checking domain DC=dev,DC=local
Registering ServicePrincipalNames for CN=DC1,OU=Domain Controllers,DC=dev,DC=local
MSSQLSvc/dc1.dev.local
Updated object
C:\>
Per my last comment to #T-Heron's answer, the internal\SERVERNAME$ account does not exist. It should be internal.domain.com\SERVERNAME$, which is the same account as DOMAIN\SERVERNAME$, where DOMAIN is the pre-Windows 2000 name for internal.domain.com.
As a result, the misplaced SPN as identified by Kerberos Configuration Manager is not the root cause of the initial error message: The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server)
The solution to the initial problem came from this post, where several steps are performed on both the client and server side to resolve the issue.
I had a new machine which windows crashed and I had to do a Windows reset which reinstalled Windows. Afterwards I deleted the old app user accounts in the C:\Users folder since the reinstall didn't delete it, these included SQL Server MSSQLServer and .net accounts because I was going to install all the apps from scratch I decided to clear it up and delete it.
I then ran SQL Server 2014 SP1 setup selecting database engine, client connectivity and Management Studio on default instance MSSQLServer
using mixed mode authentication and added my own sa password and my current windows user.
At the end of my installation I notice the installer takes a very long time at the following step
SqlEngineDBStartConfigAction_install_configrc_Cpu64
I then get an error
The following error occurred:
Could not find the Database Engine startup handle.
Logs
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, uninstall this feature, and then run the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0019
Error description: Could not find the Database Engine startup handle.
Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=12.0.4100.1&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4025&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4025
I open SQL Server configuration manager Services and noticed my MSSQLServer doesn't start up because it runs as NT Service\MSSQLSERVER user. I change that to local system account and start the service and the service runs.
However when I open SQL Server Management Studio and try to connect to the database engine I can't connect with neither my windows user I added during the SQL Server setup nor the sa user with password I specified.
Cannot connect to PCName. Login failed for user PCName\User. Microsoft SQL Server Error 18456
When I uninstall SQL Server and reinstall it I get the same issue. Even when I delete the program files directory C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER
How do I get it to work?
Why does a new SQL Server 2014 SP1 installation not create the MSSQLServer user?
How to I create the MSSQLServer user manually and what permissions and groups do I assign to it?
I tried everything to resolve it. Delete all the SQL Server folders. Remove registry entries as mentioned in other stackoverlow answers. Installed SQL Server 2014 SP1 again and the problem still occurs.
Even when I installed SQL Server 2012 SP1 on the default instance I would still get the error.
The only workaround I could get it to work was to install SQL Server as a separate instance and not the default instance.
This made me thinking if the issue is only related to the default instance.
I looked at my C:\Users folder and the default instance MSSQL user folder was not there meaning the installer never created it. The problem must have occurred that I previously deleted the User folder to clean up the machine where I should have deleted the windows users from Control Panel Admin Tools instead.
Solution: Use regedit.exe
The problem entry should be the corresponding S Folder in.
HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft -Windows NT -CurrentVersion -ProfileList
Delete this user
Reinstall and verify in the C:\Users if the MSSQL user gets created.
I tried to be safe and deleted all references to the MSSQL user in the registry user after uninstalling all SQL Server references in Add/Remove Programs and clearing up the Program Files folders the one registry item is probably the cause.
This solution helped me to fix the issue.
I had deleted MSSQLServer and SQLAgent account while cleanup of SQLServer2016, but then MSSQLServer 2016 installer wasn't getting re-installed, reason being it could not create the service account, and my application is limited to support "only default SQL instance"
I have followed this and deleted the REG entries and this helped me to reinstall SQL Server smoothly.
Thank you so much .
Solution: Use regedit.exe
The problem entry should be the corresponding S Folder in.
HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft -Windows NT -CurrentVersion -ProfileList
The story:
Virtual environment SQL, SCOM, SCCM each on his VM, everything is working.
SCOM server gets deleted (the entire VM is gone).
In order to reinstall I delete old SQL databases and files (scom & scomDW).
Recreate a VM, install OS (2012R2), prerequisites, recreate accounts (action account, data access account, write account, read account).
Action account and data access account are local admins on the installation server.
Firewall rules ware verified.
Collation is correct.
The problematic update isn't installed.
The client is not installed on SQL server.
the setup is runed under a domain admin & SQL sysadmin.
The problem
When installing "management server" Management server returns a warning then passes to Data warehouse configuration just to fail.
First error from the log says : Error: :DB operations failed with SQL error 2812: Could not find stored procedure 'p_MOMManagementGroupInfoSelect'.
Last error says that it's unable to connect to management server.
Any idea is useful so THX!
The problem was fixed by checking the "security admin" tag in SQL for the account that was making the install.
I must mention that the account was already sa and dbcreator.
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.
I've just installed SQL Server 2008 Developer edition and I'm trying to connect using SQLCMD.exe, but I get the following error:
H:\>sqlcmd.exe -S ".\SQL2008"
Msg 18452, Level 14, State 1, Server DEVBOX\SQL2008, Line 1
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
The SQL Server instance is configured to use SQL Server and Windows Authentication mode. If I specify -U sa then I can log in successfully, but I'd like to use windows authentication. Connecting using SSMS with windows authentication seems to work fine.
I had this issue and it was because the machine running the application isnt trusted for delegation on the domain by active directory. If it is a .net app running under an application pool identity DOMAIN_application.environment for example.. the identity can't make calls out to SQL unless the machine is trusted.
You're not passing any credentials to sqlcmd.exe
So it's trying to authenticate you using the Windows Login credentials, but you mustn't have your SQL Server setup to accept those credentials...
When you were installing it, you would have had to supply a Server Admin password (for the sa account)
Try...
sqlcmd.exe -U sa -P YOUR_PASSWORD -S ".\SQL2008"
for reference,
theres more details here...
In my case, this error was caused by renaming my client machine. I used a new name longer than 13 characters (despite the warning), which resulted in the NETBIOS name being truncated and being different from the full machine name. Once I re-renamed the client to a shorter name, the error went away.
Just tried this:
H:>"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe" -S ".\SQL2008"
1>
and it works.. (I have the Microsoft SQL Server\100\Tools\Binn directory in my path).
Still not sure why the SQL Server 2008 version of SQLCMD doesn't work though..
Your error is quite literally saying "you're trying to use Windows Authentication, but your login isn't from a trusted domain". Which is odd, because you're connecting to the local machine.
Perhaps you're logged into Windows using a local account rather than a domain account? Ensure that you're logging in with a domain account that is also a SQL Server principal on your SQL2008 instance.
Do you specify a user name and password to log on? What exactly is your complete command line?
If you're running on your own box, you can either specify a username/password, or use the -E parameter to log on with your Windows credentials (if those are permitted in your SQL server installation).
Marc
I was getting this error too, although my issue was that I kept switching between two corporate networks via my Virtual Machine, with different access credentials. I had to run the command prompt:
ipconfig /renew
After this my network issues were resolved and I could connect once again to SQL.
Just found this thread and posted an alternative answer (copied below) here:
https://stackoverflow.com/a/37853766/1948625
Specifically on this question, if the dot "." used in the -S value of the command line means the same as 127.0.0.1, then it could be the same issue as the connection string of the other question. Use the hostname instead, or check your hosts file.
Old question, and my symptoms are slightly different, but same error. My connection string was correct (Integrated security, and I don't provide user and pwd) with data source set to 127.0.0.1. It worked fine for years.
But recently I added a line in the static host file for testing purposes (C:\Windows\System32\drivers\etc\hosts)
127.0.0.1 www.blablatestsite.com
Removing this line and the error is gone.
I got a clue from this article (https://support.microsoft.com/en-gb/kb/896861) which talks about hostnames and loopback.
Other possible fix (if you need to keep that line in the hosts file) is to use the hostname (like MYSERVER01) instead of 127.0.0.1 in the data source of the connection string.