I have run into this issue and I am stuck with it for hours. I have 2 databases one which is publisher and distributor and second which is subscriber I am going to use them as snapshot replication. Installation went without issues but when I look in Replication monitor publication status is ok but a subscription is «uninitialized subscription».
I checked sqlagent errorlog and I get same error
Error: 15404, Could not obtain information about
Windows NT group/user‘MicrosoftAccountMyEmail’, error code 0x54b.[SQLSTATE 42000] (ConnIsLoginSysAdmin).
This really boggles me since I am being logged to the database through windows authentication but I am being seen as ADMINRG-XXXXXXYYYYY.
In my security properties on «Specify the domain or machine account under which Distribution/Snapshot Agent will run» I have set it on Run under SQL Server Agent service account, but when I tried using windows account either ADMINRG-XXXXXYYYYY or MicrosoftAccountMyEmail It puked out error 3930 which I also couldn’t manage to fix.
I also looked in generated scripts when I was installing publication and subscriptions, they both have parameters @job_login and @job_password set to null could this be source of issue?
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
-
I always get the following error when backing up a database:
Date 2/9/2011 10:39:11 AM
Log SQL Server Agent (Current — 2/9/2011 10:39:00 AM)Message
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘MyMachineAdministrator’, error code 0x54b. [SQLSTATE 42000] (ConnIsLoginSysAdmin)The original owner of the database is MyMachineAdministrator, but I have changed it to another SQL login which is not a domain user.
Any tip would be greatly appreciated.
hz
Answers
-
Hi,
It should not affect database backup operations after database owner changed and any user (SQL Server Login or Windows user) can access server can be the woner of the databse.
From the error message, it seems that the bakcup agent job is trying to use ‘MyMachineAdministrator’ to perform backup operation, please double check the job to see if you have any inapporpriate security setting (like job owner, step proxy). You may also
try to recreate job to see if that works.Hope this helps.
Best Regards,
Chunsong FengPlease remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Proposed as answer by
Thursday, February 10, 2011 5:47 AM
- Marked as answer by
Hong (MA, USA)
Thursday, February 10, 2011 12:38 PM
- Proposed as answer by
- Remove From My Forums
-
Question
-
I always get the following error when backing up a database:
Date 2/9/2011 10:39:11 AM
Log SQL Server Agent (Current — 2/9/2011 10:39:00 AM)Message
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘MyMachineAdministrator’, error code 0x54b. [SQLSTATE 42000] (ConnIsLoginSysAdmin)The original owner of the database is MyMachineAdministrator, but I have changed it to another SQL login which is not a domain user.
Any tip would be greatly appreciated.
hz
Answers
-
Hi,
It should not affect database backup operations after database owner changed and any user (SQL Server Login or Windows user) can access server can be the woner of the databse.
From the error message, it seems that the bakcup agent job is trying to use ‘MyMachineAdministrator’ to perform backup operation, please double check the job to see if you have any inapporpriate security setting (like job owner, step proxy). You may also
try to recreate job to see if that works.Hope this helps.
Best Regards,
Chunsong FengPlease remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Proposed as answer by
Thursday, February 10, 2011 5:47 AM
- Marked as answer by
Hong (MA, USA)
Thursday, February 10, 2011 12:38 PM
- Proposed as answer by
- Remove From My Forums
-
Question
-
Hello,
I’m having trouble running jobs with my active directory (ADS) account. I’ve setup my SQL services to run under an ADS account, but jobs cannot seem to query ADS for user information. We’re running Windows Server 2003 and SQL Server 2005 SP2.
Here is the error message:
==
The job failed. Unable to determine if the owner (ADSme) of job eFASRtest has server access (reason: Could not obtain information about Windows NT group/user ‘ADSme’, error code 0x5. [SQLSTATE 42000] (Error 15404)).
==
also this message in log:
==
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘ADSme, error code 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
==
I already tested the suggested:
execute as login=’adsme’ and I get the same error on both (my local installations and production)
appreciate your help
Answers
-
Most likely the machine account doesn’t have permission to query the AD.
I would recommend requesting access to the AD administrator or change SQL Server and run the service as a low-privileged domain account that has proper permissions on the AD.
-Raul Garcia
SDE/T
SQL Server Engine
- Remove From My Forums
-
Question
-
I always get the following error when backing up a database:
Date 2/9/2011 10:39:11 AM
Log SQL Server Agent (Current — 2/9/2011 10:39:00 AM)Message
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘MyMachineAdministrator’, error code 0x54b. [SQLSTATE 42000] (ConnIsLoginSysAdmin)The original owner of the database is MyMachineAdministrator, but I have changed it to another SQL login which is not a domain user.
Any tip would be greatly appreciated.
hz
Answers
-
Hi,
It should not affect database backup operations after database owner changed and any user (SQL Server Login or Windows user) can access server can be the woner of the databse.
From the error message, it seems that the bakcup agent job is trying to use ‘MyMachineAdministrator’ to perform backup operation, please double check the job to see if you have any inapporpriate security setting (like job owner, step proxy). You may also
try to recreate job to see if that works.Hope this helps.
Best Regards,
Chunsong FengPlease remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Proposed as answer by
Thursday, February 10, 2011 5:47 AM
- Marked as answer by
Hong (MA, USA)
Thursday, February 10, 2011 12:38 PM
- Proposed as answer by
-
#1
Добрый день, коллеги! Помогите с проблемой — не получается выполнить план обслуживания SQL server 2019. Ошибка внутри Агента
Сообщение
[298] Ошибка SQLServer: 15404, Не удалось получить сведения о пользователе или группе Windows NT «DOMENJulia», код ошибки: 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
Подскажите что не так…
Последнее редактирование: 20.09.2021
-
#2
Еще вижу пару ошибок, не ясно относится это к делу или нет
Дата 20.09.2021 11:35:22
Журнал Агент SQL Server (Текущий — 20.09.2021 11:35:00)
Сообщение
[408] SQL Server MSSQLSERVER является кластеризованным сервером — возможность автозапуска (AutoRestart) отключена
Дата 20.09.2021 11:35:22
Журнал Агент SQL Server (Текущий — 20.09.2021 11:35:00)Сообщение
[396] Не определено условие простоя процессора — расписания заданий типа OnIdle использоваться не будут
-
#3
Попробуйте использовать SA а не «DOMENJulia
-
#4
Можно попробовать пересоздать план обслуживания
-
#5
Попробуйте использовать SA а не «DOMENJulia
А где это делать ??
-
#7
Создала план обслуживания заново, заработало)
-
#8
Как я понял, это происходит из-за изменения названия домена или имени ПК (при этом изменяется имя сервера). А у пользователя остаётся предыдущее имя. Например, у вас было имя «DOMENJulia», соответственно имя сервера «DOMEN». Вы меняете имя компьютера на другое, имя сервера тоже меняется на «дргуое», а ваше имя остаётся «DOMENJulia», вместо «другоеJulia». Точнее, оно меняется, но при создании объектов в поле «владелец» записывается старое имя, которое уже не проходит проверку безопасности.
Вот что у меня сейчас и вот что показывает, когда создаю новую БД:
Помогло изменение владельца на sa.
-
#1
Добрый день, коллеги! Помогите с проблемой — не получается выполнить план обслуживания SQL server 2019. Ошибка внутри Агента
Сообщение
[298] Ошибка SQLServer: 15404, Не удалось получить сведения о пользователе или группе Windows NT «DOMENJulia», код ошибки: 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
Подскажите что не так…
Последнее редактирование: 20.09.2021
-
#2
Еще вижу пару ошибок, не ясно относится это к делу или нет
Дата 20.09.2021 11:35:22
Журнал Агент SQL Server (Текущий — 20.09.2021 11:35:00)
Сообщение
[408] SQL Server MSSQLSERVER является кластеризованным сервером — возможность автозапуска (AutoRestart) отключена
Дата 20.09.2021 11:35:22
Журнал Агент SQL Server (Текущий — 20.09.2021 11:35:00)Сообщение
[396] Не определено условие простоя процессора — расписания заданий типа OnIdle использоваться не будут
-
#3
Попробуйте использовать SA а не «DOMENJulia
-
#4
Можно попробовать пересоздать план обслуживания
-
#5
Попробуйте использовать SA а не «DOMENJulia
А где это делать ??
-
#7
Создала план обслуживания заново, заработало)
-
#8
Как я понял, это происходит из-за изменения названия домена или имени ПК (при этом изменяется имя сервера). А у пользователя остаётся предыдущее имя. Например, у вас было имя «DOMENJulia», соответственно имя сервера «DOMEN». Вы меняете имя компьютера на другое, имя сервера тоже меняется на «дргуое», а ваше имя остаётся «DOMENJulia», вместо «другоеJulia». Точнее, оно меняется, но при создании объектов в поле «владелец» записывается старое имя, которое уже не проходит проверку безопасности.
Вот что у меня сейчас и вот что показывает, когда создаю новую БД:
Помогло изменение владельца на sa.
ГлавнаяФорумПри создании резервного копирования sql сервера возникает ошибка error code 0x54b. [SQLSTATE 42000] (Error 15404)).
Важно! На нашем форуме собраны тысячи вопросов и ответов (с 2015 года). Но часть из них может оказаться не актуальными с позиции сегодняшнего дня. Если у вас нет времени искать нужный ответ и проверять его актуальность, то просто оставьте ваши координаты, мы с вами свяжемся и поможем в решении вопроса.
При создании резервного копирования sql сервера возникает ошибка error code 0x54b. [SQLSTATE 42000] (Error 15404)).
Поможем с поиском решения
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,6624 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
287k40 gold badges437 silver badges567 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,7711 gold badge30 silver badges52 bronze badges
Just follow this steps in images
answered Mar 8, 2019 at 7:32
TuanDPHTuanDPH
4615 silver badges14 bronze badges
- Remove From My Forums
-
Question
-
I always get the following error when backing up a database:
Date 2/9/2011 10:39:11 AM
Log SQL Server Agent (Current — 2/9/2011 10:39:00 AM)Message
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘MyMachineAdministrator’, error code 0x54b. [SQLSTATE 42000] (ConnIsLoginSysAdmin)The original owner of the database is MyMachineAdministrator, but I have changed it to another SQL login which is not a domain user.
Any tip would be greatly appreciated.
hz
Answers
-
Hi,
It should not affect database backup operations after database owner changed and any user (SQL Server Login or Windows user) can access server can be the woner of the databse.
From the error message, it seems that the bakcup agent job is trying to use ‘MyMachineAdministrator’ to perform backup operation, please double check the job to see if you have any inapporpriate security setting (like job owner, step proxy). You may also
try to recreate job to see if that works.Hope this helps.
Best Regards,
Chunsong FengPlease remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
-
Proposed as answer by
Thursday, February 10, 2011 5:47 AM
-
Marked as answer by
Hong (MA, USA)
Thursday, February 10, 2011 12:38 PM
-
Proposed as answer by
I am trying to create a maintenance plan that will run automatically and back up my SQL Server 2005 databases automatically.
I create a new maintenance plan and add a «Back Up Database Task», select all User databases, and choose a path to back up to.
IMAGE in http://www.freeimagehosting.net/uploads/16be7dce43.jpg [new user limitation]
When I save and try to execute this plan, I get the following error message:
===================================
Execution failed. See the maintenance plan and SQL Server Agent job history logs for details.
===================================
Job 'Backup.Subplan_1' failed. (SqlManagerUI)
I’ve checked the maintenance plan log, the agent log, and just about every log file I can find and there are no entries at all to help me figure out why this is failing.
If I right-click on a specific database and select «Back Up», the task succeeds. I tried changing the plan to back up just that one database and it still failed.
I’ve tried running the plan with both Windows authentication and SQL Server authentication with the sa account. I also tried specifically granting the SQL Server Agent user account full privileges on the backup folder, but it still failed.
Thanks for any suggestions!