Could not obtain information about Windows NT group/user
Sql ServerSql Server-2008SharepointSql Server Problem Overview
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 'DOMAIN\user', error code 0x5." It can be 20 such messages every second!
(...and the 'DOMAIN\user' 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?
Sql Server Solutions
Solution 1 - Sql Server
Change the owner to sa
. Here are the steps I took to solve this issue:
-
Right-Click on the database and select properties
-
Click on Files under the
Select a page
-
Under the
Owner
, but just below the Database Name on the right-hand pane, selectsa
as the owner.
Solution 2 - Sql Server
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. Hope it helps.
Solution 3 - Sql Server
In my case the owner of the database was a domain account Domain\Me.
The error message was
> Error: 15404, State: 19. Could not obtain information about Windows NT > group/user 'Domain\MyAccount'
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
I also set the Broker to Enabled in the settings
Thing started magically working after this
Solution 4 - Sql Server
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 'DOMAIN\user' needed to be authenticated by AD on the corporate network.
Error was resolved as soon as I reconnected and refreshed; the error disappeared.
Solution 5 - Sql Server
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 NEWHOSTNAME\username (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 OLDHOSTNAME\username. I connected to SQL using "sa" instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAME\username.
The error disappeared.
Solution 6 - Sql Server
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')
Solution 7 - Sql Server
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).
Solution 8 - Sql Server
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.
Solution 9 - Sql Server
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.
Solution 10 - Sql Server
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.
Solution 11 - Sql Server
You should be connected with your domain. (VPN)