Не удалось получить информацию о группе Windows NT/пользователе

У меня есть Windows 2012 Server, работающий под управлением SharePoint 2010 с использованием локального установленного SQL Server Express. К сожалению, мои журналы в настоящее время заливаются сообщением "Исключение произошло при размещении сообщения в целевой очереди. Ошибка: 15404, Состояние: 19. Не удалось получить информацию о группе Windows NT/пользователе" DOMAIN\user ", код ошибки 0x5". Это может быть 20 таких сообщений каждую секунду!

(... и "DOMAIN\user" - моя личная учетная запись.)

Есть ли работа, у которой отсутствуют права? "Qoute from https://serverfault.com/info/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e" Попробуйте изменить владельца заданий на учетную запись sa, на свойства задания". Если я прав, то экспресс-версия SQL Server не может запускать задания? Или есть кто-то, кто хочет получить доступ к нашему AD? Почему эта учетная запись хочет получать информацию о моей учетной записи 20 раз в секунду?

Я нахожу много блогов и подсказок об этой задаче, но я просто не понимаю решения. Один говорит: "Чтобы восстановить это, войдите в систему как один из счетов SA и предоставите доступ к SA для учетной записи, которая ему нужна". Но какой учет необходим для доступа?

ОТВЕТЫ

Ответ 1

Надеюсь, это поможет кому-то еще:

В моем случае, sa не был владельцем БД, я был. Когда я попытался выполнить конфигурацию CLR, которая требовала привилегий sa, я получил эту ошибку.

Решение:

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

Я использовал помощь от команды db на работе и этот пост, чтобы найти ответ. Надеюсь, что это поможет.

Ответ 2

Я знаю, что это долго, но я недавно столкнулся с одной и той же проблемой, и шаг, который я предпринял для решения этой проблемы, приведен ниже:

  • Щелкните правой кнопкой мыши по базе данных и выберите свойства

  • Нажмите "Файлы" в разделе "Выбрать страницу"

  • Под владельцем чуть ниже имени базы данных на правой панели выберите sa в качестве владельца.

Это решит проблему для вас.

Я надеюсь, что это поможет

Ответ 3

В моем случае владельцем базы данных была учетная запись домена Domain\Me.

Сообщение об ошибке было

Ошибка: 15404, Состояние: 19. Не удалось получить информацию о Windows NT group/user 'Domain\MyAccount'

Проблема заключалась в том, что база данных не знала, что делать с учетной записью домена, поэтому логической задачей было вместо этого использовать локальную учетную запись.

Я попытался изменить владельца базы данных, но все будет работать неправильно.

В конце я бросил и воссоздал всю базу данных. УБЕДИТЕСЬ, ЧТО ВЛАДЕЛЬЦЕ БЫЛО SA

enter image description here

Я также установил, чтобы брокер был включен в настройках

enter image description here

Thing начала волшебно работать после этого

Ответ 4

У меня была эта ошибка из запланированного задания в sql Server Agent, в моем случае, сразу после того, как я изменил имя хоста Windows Server. Я также запускал sp_dropserver и sp_addserver. Моя база данных принадлежала "sa", а не пользователю Windows.

Я могу войти в SQL в качестве пользователя Windows NEWHOSTNAME\username (думаю, после изменения имени хоста SID не меняется, почему он работал автоматически?).

Однако в SQL, в Security/Logins node, у меня были логики SQL, определенные как OLDHOSTNAME\имя пользователя. Я подключился к SQL, используя "sa" вместо Windows Integrated, сбросил старые логины и создал новые с именем NEWHOSTNAME\username.

Ошибка исчезла.

Ответ 5

чтобы выполнить массовое обновление для всех баз данных, запустите этот скрипт и затем выполните его вывод:

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

Ответ 6

У меня была такая же проблема, когда мой домен не распознавался. Все, что я сделал, это зашел в диспетчер конфигурации SQL Server и запустил службы в качестве сетевых служб вместо локальной службы. Сервер/агент sql смог распознать логины AD для заданий.