Я создаю репликацию SQL Server с помощью сценария. Когда я пытаюсь выполнить
Это задание, созданное сценарием, определяющим репликацию.
Как мне отладить это?
Дата 20. 2021 11:35:22
Журнал Агент SQL Server (Текущий – 20. 2021 11:35:00)
Попробуйте использовать SA а не “DOMENJulia
Можно попробовать пересоздать план обслуживания
А где это делать ??
Создала план обслуживания заново, заработало)
Как я понял, это происходит из-за изменения названия домена или имени ПК (при этом изменяется имя сервера). А у пользователя остаётся предыдущее имя. Например, у вас было имя “DOMENJulia”, соответственно имя сервера “DOMEN”. Вы меняете имя компьютера на другое, имя сервера тоже меняется на “дргуое”, а ваше имя остаётся “DOMENJulia”, вместо “другоеJulia”. Точнее, оно меняется, но при создании объектов в поле “владелец” записывается старое имя, которое уже не проходит проверку безопасности. Вот что у меня сейчас и вот что показывает, когда создаю новую БД:Помогло изменение владельца на sa.
Время от времени (например, ~ месяцы) почасовое задание агента SQL Server начинает сообщать об ошибке 15404 и продолжает делать это, пока не вмешается. Иногда первый сбой происходит сразу после ручного перезапуска служб SQL Server Engine и агента SQL Server. Проблема может быть устранена путем перезагрузки машины. Владелец задания – это имя, указанное в сообщении об ошибке, и администратор SQL Server. Учетная запись службы SQL Server Engine выглядит как служебная учетная запись (я полагаю, что это учетная запись установки по умолчанию (на один уровень лучше, чем универсальная NetworkService для предотвращения помех между экземплярами Engine / Agent):Было бы одно, если бы задание всегда терпело неудачу, но, поскольку задание успешно выполняется после перезагрузки, это заставляет меня думать, что учетная запись службы, как предполагается, должна работать, и что есть некоторая проблема синхронизации A / D или, возможно, ошибка. Когда ИТ-специалисты спрашивают о конфигурации A / D, ответом обычно является «ничего не изменилось».
- Перезапуск службы ядра и агента может привести к сбою задания.
- Перезагрузка машины устраняет проблему.
- Немедленный последующий перезапуск двигателя и агента больше не приводит к сбою задания.
Не решение, но вы можете обойти эту проблему, сделав владельца задания учетной записью SQL. Каждый раз, когда задание запускается, SQL Server проверяет личность владельца задания и проверяет, есть ли у него разрешение на выполнение задания. Если владельцем является учетная запись Windows, ядро должно запросить Active Directory. Если по какой-либо причине произойдет сбой, задание не запустится. Это может быть связано с тем, что сервер AD занят, отключен или отключен от сети или что учетная запись службы SQL Server не имеет прав. Поскольку он работает сразу после перезагрузки, это заставляет меня думать, что это может быть связано с кэшированными учетными данными. Windows сохранит учетные данные, которые ищет, для последующего использования. Этот кэш очищается при перезагрузке. Возможно, что-то портит кеш.
9 ответов
Active Directory отказывает в доступе вашему агенту SQL. Агент должен работать под учетной записью, которая распознается контроллером домена STAR.
magnattic
24 Мар 2014 в 20:20
Мы столкнулись с аналогичными ошибками в тестовой среде на виртуальной машине. Если имя машины изменится из-за клонирования ВМ из шаблона, вы можете получить эту ошибку.
Если имя компьютера изменилось с СТАРЫЙ на НОВЫЙ.
Задание использует эту хранимую процедуру:
Который использует этот:
Craig Celeste
21 Фев 2012 в 22:45
Derreck Dean
8 Фев 2017 в 13:33
В моем случае я получал эту ошибку, пытаясь использовать функцию IS_ROLEMEMBER() в SQL Server 2008 R2. Эта функция недействительна до SQL Server 2012.
Вместо этой функции я использовал
Значительно более подробный, но он выполняет свою работу.
Raj More
8 Янв 2013 в 14:34
Просто решил эту проблему. В моем случае это был недоступен контроллер домена, потому что оба DNS-сервера были DNS-серверами Google.
Я просто добавляю в контрольный список для этой проблемы:
Rail
4 Авг 2014 в 11:26
У меня была такая же проблема, которая, как оказалось, была вызвана тем, что вход в домен, который запускает службу SQL, заблокирован в AD. Блокировка была вызвана несвязанным использованием учетной записи службы для другой цели с неправильным паролем.
В сообщениях об ошибках, полученных из журналов агента SQL, не упоминается имя учетной записи службы, только имя пользователя (владельца задания), который не может быть аутентифицирован (поскольку он использует учетную запись службы для проверки с помощью AD).
mniles
4 Мар 2015 в 00:51
Мне пришлось подключиться к VPN, чтобы сценарий публикации успешно развернулся в БД.
Pete
1 Июл 2019 в 17:32
В нашем случае учетная запись службы Windows, под которой работали SQL Server и агент SQL, была заблокирована в Active Directory.
Michael Ross
12 Июл 2019 в 12:57
Я только что получил эту ошибку, и оказалось, что мой администратор AD удалил учетную запись службы, используемую КАЖДЫМ экземпляром SQL Server во всей компании. Слава богу, у AD есть своя корзина.
Посмотрите, можете ли вы запустить утилиту Active Directory – пользователи и компьютеры (% SystemRoot% system32 dsa. msc), и убедитесь, что учетная запись, на которую вы полагаетесь, все еще существует.
Ken
26 Май 2020 в 22:03
Сведения
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, должен доверенную связь с компьютером.
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.
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, 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
EXECUTE AS LOGIN=’ADSme’ Go
I also executed that command with the service account:
EXECUTE AS LOGIN=’ADSmyserviceaccountname’
Command(s) completed successfully.
If it is a SQL issue, could it be that ADSme doesn’t have permission to execute a system stored procedure in order to perform the ADS query? To answer my own question, it seems like the service account would be doing this and not my ADSme account.
One more thing you can try: Can you install a test-only copy of SQL Server 2005 (i. SQL Server Express) using a different account for the service? (it could be a different machine). If you can install it, can you try the same EXECUTE AS LOGIN tests?
I’ll see if I can try that test on my local SQL instance.
Got it, I misunderstood that part; I apologize for the confusion. Thanks for the clarification.
I am having the same exact problem. I even test on my test SQL server and I get the same message. I am not sure where to start to solve this problem. Any help?
Please, if you need further assistance let us know the scenario that were you are hitting this issue.
Can you help me out?
Hello,I am also getting the same error (15404) as Syndrake. I have tried all of Raul’s suggestions with the same results.
Please correct me if my assumption is incorrect:
· Domain-A trusts Domain-B, but Domain-B doesn’t trust Domain-A
· SQL Server is installed on a Domain-A machine
In order to work, SQL Server should be running under a Domain-B service account, otherwise it is very likely that Domain-B will not accept the token from the service and fail.
Thanks for replying to my post.
Actually, Domain A trusts Domain B and Domain B trusts Domain A. Full 2-Way trust.
SQL Server machine was a member of Domain A but now has joined Domain B. Domain A will be going away.
Previous Working Scenario
Agent job runs successfully. Domain ASQLAgentAcct while logged into Domain A is able to get information about Domain BDeveloper. I assume because of the 2-way trust.
Non-working Scenario. Attempting to take Domain A out of the picture.
Like Syndrake, I was able to log into the server as Domain BSQLAgentAcct and add Domain BDeveloper to local groups. The check names function works great. So, you would think Domain BSQLAgentAcct would have adequate permissions to query AD.
What is the service account for SQL Server? The AD query should be running using the AD credentials (if coming from SQL Server Engine).
In the non-working scenario, the SQL Server service is running as a local account that does not have domain access to Domain B. I set it up this way because I thought it was the SQL Agent account that was actually doing the AD query.
I am going to do some more testing, but I think that the SQL Server service account was my problem.
Thank you very much, Raul.
We have this issue also. I’m going to try maybe setting the trust for delegation rights on the sql svc acct? Could this be a double hop kerberos issue?
Has anyone found any fix for this?
On The SQL Server, error 28005 was constantly logged in the event log:
On the Domain Controller(s) of domain «ALPHA» I could also find event id 4769 and Failure Code 0xc, which translates to KDC policy rejects request Workstation/logon time restriction.
Service Information: Service Name: cifs/DC1. alpha. corp Service ID: S-1-0-0
Enable ‘Allowed to authenticate‘ security setting for the service account BETAsqlservice on the domain controllers computer object in domain ALPHA:
Could not obtain information about Windows NT group user
I am creating a SQL Server Replication using a script. When I try to execute
This is a job created by a script that defines replication.
How do I debug this?
9 Answers 9
Active Directory is refusing access to your SQL Agent. The Agent should be running under an account that is recognized by STAR domain controller.
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:
Which uses this one:
Which I guess is correct, under the circumstances. We added a script to the VM cloning/deployment process that re-creates the SQL login.
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
Significantly more verbose, but it gets the job done.
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:
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.
I had to connect to VPN for the publish script to successfully deploy to the DB.
In our case, the Windows service account that SQL Server and SQL Agent were running under were locked out in Active Directory.
Ошибка 0x534 при создании схемы данных
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Ошибка при создании схемы данныхДобрый день! Помогите пожалуйста решить проблему! Я создаю базу данных в Access для производства.
Ошибка при создании базы данныхЗдравствуйте!Столкнулся с проблемой: при попытке добавить базу данных в решение(правой.
Ошибка при создании базы данныху меня одна проблема я удалил базу данный по имени ShopDB Сейчас хочу создать опять по такой же.
Ошибка при динамическом создании данныхПриветству. Ррешил я поставить альфа скин в программе, заменил pagecontrol на TsPageControl.
Добавлено через 23 минуты Удалось получить доступ, переименовав имя для входа в «безопасность, имена для входа». Не думал, что это как-то исправит ошибку
Ошибка при создании Базы ДанныхДоброго Времени Суток! Я установил MySQL Server и следующий код по плану должен был создавать файл.
Ошибка при создании базы данныхСоздаю базу данных следующей командой: create database имя базы;, но в ответ получаю сообщение об.
Ошибка при создании источника данныхЗдравствуйте, помогите пожалуйста. Проблема заключается в следующем: Создал обычное оконное.
Ошибка при создании базы данныхДоброй ночи! Все никак не могу совладать с ошибкой. Есть вспомогательный класс DBHelper public.
Microsoft. SQLServer. 2012. Could_not_obtain_information_about_Windows_NT_group_user_1_5_Rule (Rule)
и “ДОМЕН пользователь” оказался моей личной учетной записью
Я нахожу множество блогов и советов по этой задаче, но я просто не понимаю решений. Один говорит: «Чтобы исправить это, войдите в систему как одну из учетных записей SA и предоставьте доступ SA той учетной записи, которая в этом нуждается». Но какой учетной записи нужен доступ?
Создан 13 апр.
спросил 15 Сен ’14 в 10:22
Измените владельца на sa. Вот шаги, которые я предпринял для решения этой проблемы:
- Щелкните правой кнопкой мыши базу данных и выберите свойства.
- Нажмите “Файлы” под Select a page
- Под Owner, но чуть ниже имени базы данных на правой панели выберите saвладельца.
изменён 23 июн в 14:13
3k9 золотых значков83 серебряных знака101 бронзовый знак
ответил 21 августа ’17 в 10:09
5 0983 золотых значка23 серебряных знака25 бронзовых знаков
В моем случае saвладельцем БД был не я. Когда я попытался выполнить конфигурацию CLR, требующую saпривилегий, я тоже получил ошибку.
Я использовал помощь команды db на работе и этот пост, чтобы найти ответ. Надеюсь, это поможет.
изменён 23 июн в 14:10
ответил 17 ноября ’14 в 21:46
Хаим ЭлияChaim Eliyah
2,4444 золотых значка22 серебряных знака34 бронзовых знака
В моем случае владельцем базы данных была учетная запись домена Domain Me.
Сообщение об ошибке было
Проблема заключалась в том, что база данных не знала, что делать с учетной записью домена, поэтому логичным решением было использовать вместо нее локальную учетную запись.
Я попытался сменить владельца базы данных, но все равно не получилось.
В конце концов, я удалил и воссоздал всю базу данных УБЕДИТЕСЬ, ЧТО ВЛАДЕЛЕЦ БЫЛ SA
Я также установил для брокера значение Включено в настройках.
Вещь начала волшебным образом работать после этого
ответил 6 ’15 мая в 11:38
У меня была эта ошибка из-за запланированного задания в агенте sql Server , в моем случае, сразу после того, как я изменил имя хоста Windows Server. Я также запускал sp_dropserver и sp_addserver. Моя база данных принадлежала «sa», а не пользователю Windows.
Ошибка исчезла.
ответил 11 января ’16 в 14:26
1,35612 серебряных значков24 бронзовых знака
чтобы выполнить массовое обновление для всех баз данных, запустите этот сценарий, а затем выполните его вывод:
ответил 26 марта ’18 в 17:05
Бег 10,1 км5 золотых значков53 серебряных знака105 бронзовых знаков
Без аутентификации домена
Сбой в конечном итоге был связан с тем, что он не смог пройти аутентификацию, когда я не был подключен к корпоративной сети.
Поскольку я подключался к локальной базе данных на своем рабочем ноутбуке, однако пользователь «ДОМЕН пользователь» должен был пройти аутентификацию с помощью AD в корпоративной сети.
Ошибка была устранена, как только я снова подключился и обновился; ошибка исчезла.
изменён 23 июн в 14:17
ответил 26 июня ’20 в 7:59
У меня была такая же проблема. В моем случае это было связано с тем, что моя машина была частью домена, но я не был подключен к корпоративной VPN. Проблема была решена после подключения к VPN (поэтому SQLAgent мог разрешить пользователя домена).
ответ дан 1 мар в 16:41
1518 бронзовых знаков
ответил 14 июня ’19 в 12:42
В моем случае это была VPNпроблема. Когда я включил VPN для подключения к своей офисной сети, а затем снова попытался запустить агент моментальных снимков, он запустился успешно.
ответил 29 октября ’19 в 18:37
Анкуш ДжайнAnkush Jain
3 9164 золотых значка21 серебряный знак44 бронзовых знака
Я столкнулся с той же проблемой. Исправлением для меня было изменение входа с пользователя NT на глобального пользователя в Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.
Создан 04 апр.
Джитан ГуптаJitan Gupta
1262 серебряных значка10 бронзовых знаков