- Remove From My Forums
-
Question
-
Running SQL Server 2016 Developer version at home on Windows 10 Pro x64. I’ve added AdventureWorksDW2014, altered the DB Owner to my login name and tried to add a database diagram.
I get the error «Could not obtain informaton about Windows NT group/user ‘my machinemy name’, error code 0x534. (Microsoft SQL Server, Error:15404)»
References I’ve found on-line seem to refer to this problem in relation to SQL Server Agent and the account that is running under. When I installed SQL Server, I just accepted the defaults with regards accounts the various services run
under.Under security, I have my login listed as sysadmin so I think I should have permissions to create the DB diagram.
Nick Ryan MIS Programmer Analyst, ANZ Bank
Answers
-
-
Edited by
Tuesday, February 7, 2017 5:43 AM
-
Proposed as answer by
Sunil Gure
Tuesday, February 7, 2017 7:41 AM -
Marked as answer by
Nick Ryan
Wednesday, February 8, 2017 8:22 PM
-
Edited by
- Remove From My Forums
-
Question
-
I have created a Job which will run the script generated by LiteSpeed for a particular DB Restore. However when i run the job, it is failing with the following error:
The job failed. Unable to determine if the owner (REDMONDv-kamir) of job Restore_Job has server access (reason: Could not obtain information about Windows NT group/user ‘REDMONDv-kamir’, error code 0x5. [SQLSTATE 42000] (Error 15404)).
I ran the script through SSMS and it works fine. Any ideas how to fix this?
Answers
-
Hello,
Error 0x5 means access denied.
Try to changing the owner of the jobs to the sa account, on the properties of the job.
If the above does no help, please change the service account for the SQL Server agent service to account with proper permissions.
http://technet.microsoft.com/en-us/library/ms345578.aspx
Hope this helps.
Regards,Alberto Morillo
SQLCoffee.com
-
Proposed as answer by
Friday, December 31, 2010 3:20 AM
-
Marked as answer by
Kazim Ali Tabrez Mir
Friday, December 31, 2010 5:56 PM
-
Proposed as answer by
Permalink
Cannot retrieve contributors at this time
| description | title | ms.custom | ms.date | ms.service | ms.reviewer | ms.subservice | ms.topic | helpviewer_keywords | ms.assetid | author | ms.author |
|---|---|---|---|---|---|---|---|---|---|---|---|
|
MSSQLSERVER_15404 |
MSSQLSERVER_15404 | Microsoft Docs |
04/04/2017 |
sql |
supportability |
reference |
15404 (Database Engine error) |
69677f02-bc81-4e4a-99b8-5c1bd1de36df |
MashaMSFT |
mathoma |
MSSQLSERVER_15404
[!INCLUDE SQL Server]
Details
| Attribute | Value |
|---|---|
| Product Name | SQL Server |
| Event ID | 15404 |
| Event Source | MSSQLSERVER |
| Component | SQLEngine |
| Symbolic Name | SEC_NTGRP_ERROR |
| Message Text | Could not obtain information about Windows NT group/user ‘user‘, error code code. |
Explanation
15404 is used in authentication when an invalid principal is specified. Or, impersonation of a Windows account fails because there is no full trust relationship between the [!INCLUDEssNoVersion] service account and the domain of the Windows account.
User Action
Check that the Windows principal exists and is not misspelled.
If this error is the result of a lack of a full trust relationship between the [!INCLUDEssNoVersion] service account and the domain of the Windows account, one of the following actions can resolve the error:
-
Use an account from the same domain as the Windows user for the [!INCLUDEssNoVersion] service.
-
If [!INCLUDEssNoVersion] is using a machine account such as Network Service or Local System, the machine must be trusted by the domain containing the Windows User.
-
Use a [!INCLUDEssNoVersion] account.
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
asked Dec 15, 2009 at 4:28
![]()
john.da.costajohn.da.costa
4,6324 gold badges28 silver badges30 bronze badges
1
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 (domainuserName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user ‘domainuserName’, 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 «domainuserName» 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!
answered Jul 30, 2013 at 19:04
![]()
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?
answered Dec 15, 2009 at 5:13
Remus RusanuRemus Rusanu
285k40 gold badges429 silver badges564 bronze badges
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.
answered Dec 4, 2018 at 4:38
![]()
TPGTPG
2,4911 gold badge29 silver badges49 bronze badges
Just follow this steps in images

answered Mar 8, 2019 at 7:32
TuanDPHTuanDPH
4614 silver badges13 bronze badges
- Remove From My Forums
-
Question
-
Hello,
Thank you all in advance for a reply (and hopefully a solution!).
Intermittently, we receive the following error when a SQL Agent Job is started:
The job failed. Unable to determine if the owner (DOMAINsvcaccount) of job SolveMe has server access (reason: Could not obtain information about Windows NT group/user ‘DOMAINsvcaccount’, error code 0x3a. [SQLSTATE 42000] (Error 15404)).
Again, the key word is intermittently. Our processes work most nights, but sometimes the above error pops up. This happens for various jobs at various times.
Additionally, this error has been seen with DTS packages in SQL Server 2000.
I do not believe this is a permissions issue with the service account, because as I said, most of the time it works. However when it doesn’t, our on call gets paged in the middle of the night to simply restart the process. That is no fun at all!
Any ideas??
- Remove From My Forums
-
Question
-
Hello,
Thank you all in advance for a reply (and hopefully a solution!).
Intermittently, we receive the following error when a SQL Agent Job is started:
The job failed. Unable to determine if the owner (DOMAINsvcaccount) of job SolveMe has server access (reason: Could not obtain information about Windows NT group/user ‘DOMAINsvcaccount’, error code 0x3a. [SQLSTATE 42000] (Error 15404)).
Again, the key word is intermittently. Our processes work most nights, but sometimes the above error pops up. This happens for various jobs at various times.
Additionally, this error has been seen with DTS packages in SQL Server 2000.
I do not believe this is a permissions issue with the service account, because as I said, most of the time it works. However when it doesn’t, our on call gets paged in the middle of the night to simply restart the process. That is no fun at all!
Any ideas??