Sql ошибка 15404 как исправить

SQLServer Error 15404 can be resolved with Bobcares by your side. 

At Bobcares, we offer solutions for every query, big and small, as a part of our SQL Server Support.

Let’s take a look at how our Support Team is ready to help customers resolve SQLServer Error 15404.

How to resolve SQLServer Error 15404

SQL server error 15404 occurs due to the specification of an invalid principal. Furthermore, the error may also pop up when the impersonation of a Windows account fails due to no full trust relationship between the domain of the Windows account and the SQL Server service account.

For instance, suppose we run a few high privilege T-SQL statements like sp_addsrvrolemember or Create Login, we may find ourselves facing Error 15404.

In this scenario, we will see notice messages in PALLOG. In case the PALLOG is disabled, we have to enable it manually by creating /var/opt/mssql/logger.ini  with the following content:

How to fix SQLServer Error 15404

[Output:sql]
type=File
filename=/var/opt/mssql/log/pallog.txt

[Logger:security]
level=debug
outputs=sql

Let’s take a look at the messages in PALLOG:

03/12/2022 12:36:56.448761588 Debug [security.kerberos] <0000040947/0x00000200> Processing SSPI operation 0x0000000F

03/12/2022 12:36:56.439366379 Error [security.ldap] <0000040947/0x00000200> Initializing credentials for use in new cache failed: Keytab contains no suitable keys for red4$@SQLREPRO.EDU

03/12/2022 12:36:56.439613575 Debug [security.kerberos] <0000040947/0x00000200> Import name [ADMINISTRATOR@SQLREPRO.EDU] returned [ADMINISTRATOR@SQLREPRO.EDU]

03/12/2022 12:36:56.439633375 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]

03/12/2022 12:36:56.439753473 Debug [security.kerberos] <0000040947/0x00000200> Import name [RED4$] returned [RED4$]

03/12/2022 12:36:56.439905471 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]

03/12/2022 12:36:56.440014469 Error [security.kerberos] <0000040947/0x00000200> GSS MAJOR: 851968 GSS MINOR: 39756033 Error acquiring credentials in AcquireCredCaseInsensitive

03/12/2022 12:36:56.440029069 Error [security.kerberos] <0000040947/0x00000200> Unspecified GSS failure. Minor code may provide more information

03/12/2022 12:36:56.440039869 Error [security.kerberos] <0000040947/0x00000200> No key table entry found for red4$@SQLREPRO.EDU

03/12/2022 12:36:56.440053069 Debug [security.kerberos] <0000040947/0x00000200> SSPI operation 0x0000000F returned status: KerberosStream.cpp:2021 Operation unsuccessful

03/12/2022 12:36:56.440119868 Debug [security.kerberos.libos] <0000040961/0x0000020c> GetSecContextByUserABI() return value: 0x80090304

03/12/2022 12:36:56.468617991 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000

03/12/2022 12:36:56.468748289 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000

03/12/2022 13:56:26.489370580 Debug [security.kerberos.libos] <0000040961/0x0000020c> LookupAccountSid() return value: 0x00000001

As seen above, queries like Create login require checking permissions. The first time this is done, current permission is invalidated. When we repeat it, the permission check is rechecked. Furthermore, during the permission check, the SQL Server will go through the myssql.keytab to find the machine entry key or MSA key

In case the SQL Server cannot find the entries or finds invalid entries, it results in an error.

If we find ourselves facing this particular error, our Support Engineers suggest ensuring the Windows principal exists in addition to not being misspelled. Here are a few more troubleshooting tips courtesy of our Support Team to resolve this issue:

  • Ensure we use an account from the same Windows user domain for the SQL Server service.
  • If SQL Server uses a machine account like Local System or Network System, the machine has to be trusted by the Windows User domain.
  • Use a SQL Server account

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our skilled Support Engineers at Bobcares demonstrated how to fix SQLServer Error 15404.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

I am creating a SQL Server Replication using a script. When I try to execute

The job failed. Unable to determine if the owner (STARmoorer7) of job L3BPT2M-Atlas-14 has server access (reason: Could not obtain information about Windows NT group/user 'STARmoorer7', error code 0x5. [SQLSTATE 42000] (Error 15404)).

This is a job created by a script that defines replication.

How do I debug this?

asked Aug 5, 2009 at 17:13

Raj More's user avatar

Raj MoreRaj More

46.8k33 gold badges130 silver badges195 bronze badges

3

Active Directory is refusing access to your SQL Agent. The Agent should be running under an account that is recognized by STAR domain controller.

magnattic's user avatar

magnattic

12.5k13 gold badges62 silver badges114 bronze badges

answered Aug 5, 2009 at 17:30

Remus Rusanu's user avatar

Remus RusanuRemus Rusanu

287k40 gold badges437 silver badges567 bronze badges

7

For me, the jobs were running under DOMAINAdministrator and failing with the error message "The job failed. Unable to determine if the owner (DOMAINadministrator) of job Agent history clean up: distribution has server access (reason: Could not obtain information about Windows NT group/user 'DOMAINadministrator', error code 0x5. [SQLSTATE 42000] (Error 15404)). To fix this, I changed the owner of each failing job to sa. Worked flawlessly after that. The jobs were related to replication cleanup, but I’m unsure if they were manually added or were added as a part of the replication set-up — I wasn’t involved with it, so I am not sure.

answered Sep 19, 2016 at 15:00

Derreck Dean's user avatar

Derreck DeanDerreck Dean

3,6881 gold badge26 silver badges45 bronze badges

0

We encountered similar errors in a testing environment on a virtual machine. If the machine name changes due to VM cloning from a template, you can get this error.

If the computer name changed from OLD to NEW.

A job uses this stored procedure:

msdb.dbo.sp_sqlagent_has_server_access @login_name = 'OLDAdministrator'

Which uses this one:

EXECUTE master.dbo.xp_logininfo 'OLDAdministrator'

Which gives this SQL error 15404

select text from sys.messages where message_id = 15404;
Could not obtain information about Windows NT group/user '%ls', error code %#lx.

Which I guess is correct, under the circumstances. We added a script to the VM cloning/deployment process that re-creates the SQL login.

answered Feb 16, 2012 at 21:43

Craig Celeste's user avatar

Craig CelesteCraig Celeste

12.1k10 gold badges42 silver badges48 bronze badges

In my case I was getting this error trying to use the IS_ROLEMEMBER() function on SQL Server 2008 R2. This function isn’t valid prior to SQL Server 2012.

Instead of this function I ended up using

select 1 
from sys.database_principals u 
inner join sys.database_role_members ur 
    on u.principal_id = ur.member_principal_id 
inner join sys.database_principals r 
    on ur.role_principal_id = r.principal_id 
where r.name = @role_name 
and u.name = @username

Significantly more verbose, but it gets the job done.

Raj More's user avatar

Raj More

46.8k33 gold badges130 silver badges195 bronze badges

answered Jan 3, 2013 at 18:44

Bacon Bits's user avatar

Bacon BitsBacon Bits

30.5k5 gold badges58 silver badges65 bronze badges

Just solved this problem. In my case it was domain controller is not accessible, because both dns servers was google dns.

I just add to checklist for this problem:

  • check domain controller is accessible

answered Aug 4, 2014 at 11:26

Rail's user avatar

RailRail

7008 silver badges12 bronze badges

1

I was having the same issue, which turned out to be caused by the Domain login that runs the SQL service being locked out in AD. The lockout was caused by an unrelated usage of the service account for another purpose with the wrong password.

The errors received from SQL Agent logs did not mention the service account’s name, just the name of the user (job owner) that couldn’t be authenticated (since it uses the service account to check with AD).

answered Mar 4, 2015 at 0:51

mniles's user avatar

I had to connect to VPN for the publish script to successfully deploy to the DB.

answered Apr 25, 2015 at 17:42

Pete's user avatar

PetePete

1492 silver badges14 bronze badges

In our case, the Windows service account that SQL Server and SQL Agent were running under were locked out in Active Directory.

answered Jul 12, 2019 at 12:57

Michael Ross's user avatar

I just got this error and it turns out my AD administrator deleted the service account used by EVERY SQL Server instance in the entire company. Thank goodness AD has its own recycle bin.

See if you can run the Active Directory Users and Computers utility (%SystemRoot%system32dsa.msc), and check to make sure the account you are relying on still exists.

answered May 26, 2020 at 22:03

Ken's user avatar

Permalink

Cannot retrieve contributors at this time

title description author ms.author ms.date ms.service ms.subservice ms.topic helpviewer_keywords

MSSQLSERVER_15404

MSSQLSERVER_15404

MashaMSFT

mathoma

04/04/2017

sql

supportability

reference

15404 (Database Engine error)

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.

Every so often (e.g. ~months) a SQL Server Agent hourly Job will begin reporting an Error 15404 and continue to do so until intervened with.

[298] SQLServer Error: 15404, Could not obtain information about
Windows NT group/user ‘DOMAIN_NAMESomeDomainAccount’, error code
0x6e. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

Sometimes the first failure occurs immediately after a manual restart of the SQL Server Engine and SQL Server Agent services. The problem can be cleared by rebooting the machine.

The Job Owner is the name listed in the error message and is a SQL Server Admin.

The SQL Server Engine Service account looks to be a service account (I believe it is the default install account (one notch better than generic NetworkService to prevent interference between Engine/Agent instances):

   NT ServiceMSSQL$INSTNAME

It would be one thing if the job always failed but since the job succeeds after a reboot it makes me think that a service account like is supposed to be working and that there is some A/D timing issue or possibly a bug. When IT is asked about the A/D configuration, the response is usually «nothing has changed.»

  • Restarting the engine and agent services can cause the job to start failing.
  • A machine reboot clears the problem.
  • An immediate subsequent restart of the engine and agent no longer cause the job to fail.

Link:
How to troubleshoot a SQL Server 8198 error

I have a Windows 2012 Server running SharePoint 2010 using an SQL Server Express locally installed. Unfortunately my logs are currently flooding with message «An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘DOMAINuser’, error code 0x5.» It can be 20 such messages every second!

(…and the ‘DOMAINuser’ happens to be my personal account.)

Are there a job running that has missing rights? «Qoute from https://serverfault.com/questions/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e «Try to changing the owner of the jobs to the sa account, on the properties of the job.» If I’m correct the express version of SQL server cannot run jobs? Or is there someone/something that wants access to our AD? Why do that account wants to obtain information about my account 20 times every second?

I do find lot’s of blogs and hints about this task, but I just dont understand the solutions. One says «To repair this, login as one of the SA accounts and grant SA access for the account that needs it.» But what account needs sa access?

Community's user avatar

asked Sep 15, 2014 at 10:22

kolback's user avatar

1

Change the owner to sa. Here are the steps I took to solve this issue:

  1. Right-Click on the database and select properties

  2. Click on Files under the Select a page

  3. Under the Owner, but just below the Database Name on the right-hand pane, select sa as the owner.

ΩmegaMan's user avatar

ΩmegaMan

29.1k10 gold badges99 silver badges121 bronze badges

answered Aug 21, 2017 at 10:09

olammy's user avatar

olammyolammy

6,5284 gold badges25 silver badges32 bronze badges

6

In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.

The solution:

USE MyDB 
GO 
ALTER DATABASE MyDB set TRUSTWORTHY ON; 
GO 
EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false 
GO 
sp_configure 'show advanced options', 1; 
GO 
RECONFIGURE; 
GO 
sp_configure 'clr enabled', 1; 
GO 
RECONFIGURE; 
GO

I used help from the db team at work and this post to find the answer.

starball's user avatar

starball

15.1k6 gold badges28 silver badges134 bronze badges

answered Nov 17, 2014 at 21:46

Chaim Eliyah's user avatar

Chaim EliyahChaim Eliyah

2,7334 gold badges23 silver badges37 bronze badges

7

In my case the owner of the database was a domain account DomainMe.

The error message was

Error: 15404, State: 19. Could not obtain information about Windows NT
group/user ‘DomainMyAccount’

The problem was that the database didn’t know what to do with the domain account — so the logical thing to do was to use a local account instead.

I tried changing the owner of the database, but things still wouldn’t work correctly.

In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA

enter image description here

I also set the Broker to Enabled in the settings

enter image description here

Thing started magically working after this

answered May 6, 2015 at 11:38

Malcolm Swaine's user avatar

2

No Domain Authentication

Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.

For I was connecting to a local db on my work laptop, however the User ‘DOMAINuser’ needed to be authenticated by AD on the corporate network.

Error was resolved as soon as I reconnected and refreshed; the error disappeared.

ΩmegaMan's user avatar

ΩmegaMan

29.1k10 gold badges99 silver badges121 bronze badges

answered Jun 26, 2020 at 7:59

Ameet Bhat's user avatar

Ameet BhatAmeet Bhat

911 silver badge1 bronze badge

1

to do a bulk update for all databases, run this script and then execute its output:

 SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
 from sys.databases
     where name not in ('master', 'model', 'tempdb')

answered Mar 26, 2018 at 17:05

avs099's user avatar

avs099avs099

10.9k6 gold badges60 silver badges110 bronze badges

I had this error from a scheduled job in sql Server Agent, in my case, just after I changed the hostname of the Windows Server. I had also ran sp_dropserver and sp_addserver. My database was owned by «sa», not a Windows user.

I could login into SQL as the Windows user NEWHOSTNAMEusername (I guess after a hostname change, the SID doesn’t change, that’s why it worked automatically?).

However, in SQL, in Security/Logins node, I had SQL logins defined as OLDHOSTNAMEusername. I connected to SQL using «sa» instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAMEusername.

The error disappeared.

answered Jan 11, 2016 at 14:26

Thierry_S's user avatar

Thierry_SThierry_S

1,51616 silver badges25 bronze badges

I was having the same problem. In my case it was due to the fact that my machine was part of a domain, but I was not connected to the company VPN. The problem was solved after connecting to the VPN (so the domain user could be resolved by the SQLAgent).

answered Mar 1, 2021 at 13:41

erionpc's user avatar

erionpcerionpc

3563 silver badges14 bronze badges

I had the same issue where my domain login was not being recognized. All I did was go into the SQL Server configuration manager and start the services as Network Services instead of a local service. The sql server / agent was then able to recognize the AD logins for the jobs.

answered Jun 14, 2019 at 12:42

Hali's user avatar

HaliHali

413 bronze badges

In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.

answered Oct 29, 2019 at 18:37

Ankush Jain's user avatar

Ankush JainAnkush Jain

5,3214 gold badges32 silver badges52 bronze badges

2

I was facing the same issue.
Fix for me was changing the log-on from NT User to global user in Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.

enter image description here

answered Apr 4, 2020 at 9:10

Jitan Gupta's user avatar

Jitan GuptaJitan Gupta

4446 silver badges17 bronze badges

You should be connected with your domain. (VPN)

answered Feb 8, 2022 at 8:53

Wouter's user avatar

WouterWouter

2,48019 silver badges31 bronze badges

  • Remove From My Forums
  • Вопрос

  • I am trying to learn replication and using Agent jobs while attached to my corporate domain. Trying to use my personal domain account to run jobs or replication, I keep getting:

    SQL Server Error 15404, Could not obtain information about Windows NT groupuser ‘MyNameMyDomain’, error code 0x5 [SQLSTATE 42000] (ConnIsLoginSysAdmin)

    What might be preventing SQL Server from getting my account information from the domain? Group ploicy?

    Thanks in advance,

    Richard

Ответы

  • Changing the SQL Server Agent services (on both the publisher and subscriber) to run under my personal domain account has things working properly. I will have to experiment with other settings and the Local System account to see what exactly went wrong.

    Thanks you all for your advice (pre-holiday activities delayed getting this fixed — thanks for your patience and have a great holiday yourselves!)

    Richard

SQLServer Error 15404 can be resolved with Bobcares by your side. 

At Bobcares, we offer solutions for every query, big and small, as a part of our SQL Server Support.

Let’s take a look at how our Support Team is ready to help customers resolve SQLServer Error 15404.

How to resolve SQLServer Error 15404

SQL server error 15404 occurs due to the specification of an invalid principal. Furthermore, the error may also pop up when the impersonation of a Windows account fails due to no full trust relationship between the domain of the Windows account and the SQL Server service account.

For instance, suppose we run a few high privilege T-SQL statements like sp_addsrvrolemember or Create Login, we may find ourselves facing Error 15404.

In this scenario, we will see notice messages in PALLOG. In case the PALLOG is disabled, we have to enable it manually by creating /var/opt/mssql/logger.ini  with the following content:

How to fix SQLServer Error 15404

[Output:sql]
type=File
filename=/var/opt/mssql/log/pallog.txt

[Logger:security]
level=debug
outputs=sql

Let’s take a look at the messages in PALLOG:

03/12/2022 12:36:56.448761588 Debug [security.kerberos] <0000040947/0x00000200> Processing SSPI operation 0x0000000F

03/12/2022 12:36:56.439366379 Error [security.ldap] <0000040947/0x00000200> Initializing credentials for use in new cache failed: Keytab contains no suitable keys for red4$@SQLREPRO.EDU

03/12/2022 12:36:56.439613575 Debug [security.kerberos] <0000040947/0x00000200> Import name [ADMINISTRATOR@SQLREPRO.EDU] returned [ADMINISTRATOR@SQLREPRO.EDU]

03/12/2022 12:36:56.439633375 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]

03/12/2022 12:36:56.439753473 Debug [security.kerberos] <0000040947/0x00000200> Import name [RED4$] returned [RED4$]

03/12/2022 12:36:56.439905471 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]

03/12/2022 12:36:56.440014469 Error [security.kerberos] <0000040947/0x00000200> GSS MAJOR: 851968 GSS MINOR: 39756033 Error acquiring credentials in AcquireCredCaseInsensitive

03/12/2022 12:36:56.440029069 Error [security.kerberos] <0000040947/0x00000200> Unspecified GSS failure. Minor code may provide more information

03/12/2022 12:36:56.440039869 Error [security.kerberos] <0000040947/0x00000200> No key table entry found for red4$@SQLREPRO.EDU

03/12/2022 12:36:56.440053069 Debug [security.kerberos] <0000040947/0x00000200> SSPI operation 0x0000000F returned status: KerberosStream.cpp:2021 Operation unsuccessful

03/12/2022 12:36:56.440119868 Debug [security.kerberos.libos] <0000040961/0x0000020c> GetSecContextByUserABI() return value: 0x80090304

03/12/2022 12:36:56.468617991 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000

03/12/2022 12:36:56.468748289 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000

03/12/2022 13:56:26.489370580 Debug [security.kerberos.libos] <0000040961/0x0000020c> LookupAccountSid() return value: 0x00000001

As seen above, queries like Create login require checking permissions. The first time this is done, current permission is invalidated. When we repeat it, the permission check is rechecked. Furthermore, during the permission check, the SQL Server will go through the myssql.keytab to find the machine entry key or MSA key

In case the SQL Server cannot find the entries or finds invalid entries, it results in an error.

If we find ourselves facing this particular error, our Support Engineers suggest ensuring the Windows principal exists in addition to not being misspelled. Here are a few more troubleshooting tips courtesy of our Support Team to resolve this issue:

  • Ensure we use an account from the same Windows user domain for the SQL Server service.
  • If SQL Server uses a machine account like Local System or Network System, the machine has to be trusted by the Windows User domain.
  • Use a SQL Server account

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our skilled Support Engineers at Bobcares demonstrated how to fix SQLServer Error 15404.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

Содержание

  1. MSSQLSERVER_15404
  2. Сведения
  3. Объяснение
  4. Действие пользователя
  5. Fixing Maintenance Plan Error code 0x534
  6. Sql server error 15404 error code 0x534
  7. Answered by:
  8. Question
  9. Sql server error 15404 error code 0x534
  10. Answered by:
  11. Question
  12. SQLServer Error 15404 | How-to-fix
  13. How to resolve SQLServer Error 15404
  14. Conclusion
  15. PREVENT YOUR SERVER FROM CRASHING!

MSSQLSERVER_15404

Применимо к: SQL Server (все поддерживаемые версии)

Сведения

attribute Значение
Название продукта SQL Server
Идентификатор события 15404
Источник события MSSQLSERVER
Компонент SQLEngine
Символическое имя SEC_NTGRP_ERROR
Текст сообщения Не удалось получить сведения о пользователе/группе Windows NT «пользователь«, код ошибки код_ошибки.

Объяснение

15404 используется при проверке подлинности, если указан недопустимый участник. Или олицетворение учетной записи Windows не выполняется, так как не существует связи полного уровня доверия между учетной записью SQL Server и учетной записью домена Windows.

Действие пользователя

Убедитесь, что участник Windows существует и его имя указано верно.

Если эта ошибка — результат отсутствия связи полного уровня доверия между учетной записью службы SQL Server и учетной записью домена Windows, то ошибку можно устранить одним из следующих способов.

Используйте для службы SQL Server учетную запись из домена, к которому относится пользователь Windows.

Если SQL Server использует учетную запись компьютера, например Network Service или Local System, то домен, на котором находится пользователь Windows, должен доверенную связь с компьютером.

Источник

Fixing Maintenance Plan Error code 0x534

Have you ever changed Server name on which SQL Server instance is installed? One of my friends changed the hostname of a Windows server with SQL Server already installed. After this, the SQL Server maintenance plan jobs started to fail. As we know, internally SQL Server still shows the old hostname this must be dropped manually. Otherwise your SQL Server maintenance plan jobs fail with this error.

The Job failed: Could not obtain information about Windows NT group/user ‘XXXXXXAdministrator’, error code 0x534. [SQLSTATE 42000] (Error 15404))

In this post, I will show you the procedure to resolve the errors and execute the SQL Server Agent Maintenance Plan jobs successfully. Below is the error screenshot showing job failure in the SQL Server agent logs. The error is highlighted in the image in red.

First, connect to your SQL Server instance with SQL Server Management Studio and run the below queries to check SQL Server name:

In the below screenshot, the server name and machine name are different.

Run the below shown T-SQL scripts to drop the old server name, and then it add back the SERVERNAME to match the operating system’s hostname.

In the below screenshot, first we dropped old server name.

In the below screenshot, we have added new server name using T-SQL.

Now, log into the SQL Server with a “sysadmin” privileged user. Go to SQL Server logins, and you can still see the oldServernameadministrator login bound with the SQL Server engine.

Drop the login “OldServernameadministrator” and create a new windows login as “NewServernameadministrator”, adding the sysadmin Server role.

In the below screenshot, we have added “DB01administrator” login.

The owner of the job associated with maintenance plan is OldServernameadministrator. We need to reset the ownerid using the below T-SQL Update query.

Now, We need to reset the owner of the job associated with the maintenance plan by running the below T-SQL query. In below screenshot, reset the owner of the job.

Right click on SQL Server job and select properties and change the owner of job to “sa” login.

Delete old maintenance plan and re-create the maintenance plan. Right click and click execute maintenance plan. You can see maintenance plan executed successfully. J

Источник

Sql server error 15404 error code 0x534

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

== I asked this question directly to Remus and wanted to share the response to all of those people using this forum ==

We recently moved our database server from SQL Server 2000 to SQL Server 2005. All applications on our intranet development server stay the same [VS.NET 2003], but recently resources in our Dev DB server ran out of space. While doing a thorough investigation, I noticed ERRORLOG file was occupying about 35 Gig of HDD space. I immediately checked SQL Server error log and noticed an entry which says –

Date 7/7/2006 4:45:37 PM

Log SQL Server (Current — 7/7/2006 4:45:00 PM)

The activated proc [dbo].[SqlQueryNotificationStoredProcedure-5eaf8465-d0cb-4be7-93b6-44bb979dd41c] running on queue BW_Content.dbo.SqlQueryNotificationService-5eaf8465-d0cb-4be7-93b6-44bb979dd41c output the following: ‘Could not obtain information about Windows NT group/user ‘BWCINCHoffK’, error code 0x534.’

What is this SqlQueryNotificationService in my database? Is it a SQL Server 2005 thing? Why the same kind of stored procedure does not exist in other databases, but BW_Content? This error is getting repeated most probably every second and is filling up our server.

I believe our corporate IT people removed our domain accounts from BWCINC domain to BWCORP domain and probably some application which is using BWCINCHoffK credential is getting errored out. I tried to locate this application and was not successful.

Is there anyway that I can stop this ERRORLOG from growing? How can I delete these log entries so that I can make space on our Hard Drive? Is there an easy way in SQL Server 2005 to locate which application is creating this error?

Источник

Sql server error 15404 error code 0x534

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

== I asked this question directly to Remus and wanted to share the response to all of those people using this forum ==

We recently moved our database server from SQL Server 2000 to SQL Server 2005. All applications on our intranet development server stay the same [VS.NET 2003], but recently resources in our Dev DB server ran out of space. While doing a thorough investigation, I noticed ERRORLOG file was occupying about 35 Gig of HDD space. I immediately checked SQL Server error log and noticed an entry which says –

Date 7/7/2006 4:45:37 PM

Log SQL Server (Current — 7/7/2006 4:45:00 PM)

The activated proc [dbo].[SqlQueryNotificationStoredProcedure-5eaf8465-d0cb-4be7-93b6-44bb979dd41c] running on queue BW_Content.dbo.SqlQueryNotificationService-5eaf8465-d0cb-4be7-93b6-44bb979dd41c output the following: ‘Could not obtain information about Windows NT group/user ‘BWCINCHoffK’, error code 0x534.’

What is this SqlQueryNotificationService in my database? Is it a SQL Server 2005 thing? Why the same kind of stored procedure does not exist in other databases, but BW_Content? This error is getting repeated most probably every second and is filling up our server.

I believe our corporate IT people removed our domain accounts from BWCINC domain to BWCORP domain and probably some application which is using BWCINCHoffK credential is getting errored out. I tried to locate this application and was not successful.

Is there anyway that I can stop this ERRORLOG from growing? How can I delete these log entries so that I can make space on our Hard Drive? Is there an easy way in SQL Server 2005 to locate which application is creating this error?

Источник

SQLServer Error 15404 | How-to-fix

by Nikhath K | Apr 3, 2022

SQLServer Error 15404 can be resolved with Bobcares by your side.

At Bobcares, we offer solutions for every query, big and small, as a part of our SQL Server Support.

Let’s take a look at how our Support Team is ready to help customers resolve SQLServer Error 15404.

How to resolve SQLServer Error 15404

SQL server error 15404 occurs due to the specification of an invalid principal. Furthermore, the error may also pop up when the impersonation of a Windows account fails due to no full trust relationship between the domain of the Windows account and the SQL Server service account.

For instance, suppose we run a few high privilege T-SQL statements like sp_addsrvrolemember or Create Login, we may find ourselves facing Error 15404.

In this scenario, we will see notice messages in PALLOG. In case the PALLOG is disabled, we have to enable it manually by creating /var/opt/mssql/logger.ini with the following content:

Let’s take a look at the messages in PALLOG:

As seen above, queries like Create login require checking permissions. The first time this is done, current permission is invalidated. When we repeat it, the permission check is rechecked. Furthermore, during the permission check, the SQL Server will go through the myssql.keytab to find the machine entry key or MSA key

In case the SQL Server cannot find the entries or finds invalid entries, it results in an error.

If we find ourselves facing this particular error, our Support Engineers suggest ensuring the Windows principal exists in addition to not being misspelled. Here are a few more troubleshooting tips courtesy of our Support Team to resolve this issue:

  • Ensure we use an account from the same Windows user domain for the SQL Server service.

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our skilled Support Engineers at Bobcares demonstrated how to fix SQLServer Error 15404.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

I am creating a SQL Server Replication using a script. When I try to execute

The job failed. Unable to determine if the owner (STARmoorer7) of job L3BPT2M-Atlas-14 has server access (reason: Could not obtain information about Windows NT group/user 'STARmoorer7', error code 0x5. [SQLSTATE 42000] (Error 15404)).

This is a job created by a script that defines replication.

How do I debug this?

asked Aug 5, 2009 at 17:13

Raj More's user avatar

Raj MoreRaj More

46.5k33 gold badges128 silver badges195 bronze badges

3

Active Directory is refusing access to your SQL Agent. The Agent should be running under an account that is recognized by STAR domain controller.

magnattic's user avatar

magnattic

12.4k13 gold badges63 silver badges114 bronze badges

answered Aug 5, 2009 at 17:30

Remus Rusanu's user avatar

Remus RusanuRemus Rusanu

286k40 gold badges430 silver badges565 bronze badges

7

For me, the jobs were running under DOMAINAdministrator and failing with the error message "The job failed. Unable to determine if the owner (DOMAINadministrator) of job Agent history clean up: distribution has server access (reason: Could not obtain information about Windows NT group/user 'DOMAINadministrator', error code 0x5. [SQLSTATE 42000] (Error 15404)). To fix this, I changed the owner of each failing job to sa. Worked flawlessly after that. The jobs were related to replication cleanup, but I’m unsure if they were manually added or were added as a part of the replication set-up — I wasn’t involved with it, so I am not sure.

answered Sep 19, 2016 at 15:00

Derreck Dean's user avatar

Derreck DeanDerreck Dean

3,6481 gold badge26 silver badges45 bronze badges

0

We encountered similar errors in a testing environment on a virtual machine. If the machine name changes due to VM cloning from a template, you can get this error.

If the computer name changed from OLD to NEW.

A job uses this stored procedure:

msdb.dbo.sp_sqlagent_has_server_access @login_name = 'OLDAdministrator'

Which uses this one:

EXECUTE master.dbo.xp_logininfo 'OLDAdministrator'

Which gives this SQL error 15404

select text from sys.messages where message_id = 15404;
Could not obtain information about Windows NT group/user '%ls', error code %#lx.

Which I guess is correct, under the circumstances. We added a script to the VM cloning/deployment process that re-creates the SQL login.

answered Feb 16, 2012 at 21:43

Craig Celeste's user avatar

Craig CelesteCraig Celeste

12k9 gold badges41 silver badges48 bronze badges

In my case I was getting this error trying to use the IS_ROLEMEMBER() function on SQL Server 2008 R2. This function isn’t valid prior to SQL Server 2012.

Instead of this function I ended up using

select 1 
from sys.database_principals u 
inner join sys.database_role_members ur 
    on u.principal_id = ur.member_principal_id 
inner join sys.database_principals r 
    on ur.role_principal_id = r.principal_id 
where r.name = @role_name 
and u.name = @username

Significantly more verbose, but it gets the job done.

Raj More's user avatar

Raj More

46.5k33 gold badges128 silver badges195 bronze badges

answered Jan 3, 2013 at 18:44

Bacon Bits's user avatar

Bacon BitsBacon Bits

30k5 gold badges56 silver badges63 bronze badges

Just solved this problem. In my case it was domain controller is not accessible, because both dns servers was google dns.

I just add to checklist for this problem:

  • check domain controller is accessible

answered Aug 4, 2014 at 11:26

Rail's user avatar

RailRail

7008 silver badges12 bronze badges

1

I was having the same issue, which turned out to be caused by the Domain login that runs the SQL service being locked out in AD. The lockout was caused by an unrelated usage of the service account for another purpose with the wrong password.

The errors received from SQL Agent logs did not mention the service account’s name, just the name of the user (job owner) that couldn’t be authenticated (since it uses the service account to check with AD).

answered Mar 4, 2015 at 0:51

mniles's user avatar

I had to connect to VPN for the publish script to successfully deploy to the DB.

answered Apr 25, 2015 at 17:42

Pete's user avatar

PetePete

1492 silver badges14 bronze badges

In our case, the Windows service account that SQL Server and SQL Agent were running under were locked out in Active Directory.

answered Jul 12, 2019 at 12:57

Michael Ross's user avatar

I just got this error and it turns out my AD administrator deleted the service account used by EVERY SQL Server instance in the entire company. Thank goodness AD has its own recycle bin.

See if you can run the Active Directory Users and Computers utility (%SystemRoot%system32dsa.msc), and check to make sure the account you are relying on still exists.

answered May 26, 2020 at 22:03

Ken's user avatar

  • #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». Точнее, оно меняется, но при создании объектов в поле «владелец» записывается старое имя, которое уже не проходит проверку безопасности.

Вот что у меня сейчас и вот что показывает, когда создаю новую БД:

БД.png

Помогло изменение владельца на sa.

Понравилась статья? Поделить с друзьями:
  • Sql операционная система вернула ошибку 5
  • Sqlplus ошибка при запуске приложения
  • Sql обработка ошибок в триггере
  • Sqlite ошибка no such table
  • Sql обработка ошибок в запросе