Меню

Ошибка входа пользователя nt authority система

Имею в своем распоряжении два сервер A и B. Имею права для чтения на обоих сервера как (DomainUser.Name). При чтении таблиц индивидуально, то есть
Select * From A или Select * From B (не смотрите на синтаксис, это просто пример), я получаю данные без проблем. Когда же я хочу с сервера A прочитать что на сервере B получаю ошибку

Message 18456, level 14, status 1, line 1
Logon failed for user 'NT-AUTORITY  ANONYMOUS LOGON'.

Если ли какие-то специальные настройки для того, чтобы все это заработало или что нужно сделать?

задан 20 янв 2020 в 14:45

Insider's user avatar

Мб:

Login failed for user ’NT AUTHORITYсистема’. Причина: не удалось открыть явно указанную базу данных.

Причина: Авторизация верная, запуск происходит с правами администратора, но база данных недоступна (или нет разрешения).

Решение: Группе NT AUTHORITYсистема необходимо добавить роль sysadmin на SQL сервере. Для этого зайдите Microsoft SQL Server Management Studio, раздел Безопасность – Имена входа и выберите свойства группы NT AUTHORITYсистема. В меню Роли сервера установите флажок напротив роли sysadmin.

ответ дан 20 янв 2020 в 15:26

Coder's user avatar

CoderCoder

2,7202 золотых знака9 серебряных знаков16 бронзовых знаков

I have posted a related question few days back and provided its answer as well.

I am facing a strange issue, I have 2 servers first one is dev server and second is QA

When I execute the below line on dev server it works fine, but when I execute it on QA, it gives me the error Login failed for user 'NT AUTHORITYANONYMOUS LOGON', as I posted in my previous question.

EXEC master.dbo.xp_cmdshell ‘sqlcmd -D db_name -S server_name -i sqlfile’ 

To resolve the above issue I have provided the username and pwd in the above query and it is working fine on both DEV and QA server. But to provide the username and pwd is not a nice approach as if we will change the server or pwd it directly impacts my query. So I want to execute the cmdshell command without using username and pwd on QA as well.

Can anyone please tell me what I am missing on QA. I have already provided the permissions to cmdshell on QA

ANY QUICK HELP

Community's user avatar

asked Apr 29, 2014 at 7:17

user3124690's user avatar

4

This is because the user the command runs as is NT AUTHORITYANONYMOUS LOGON, and this login does not have access to the DB.

Consider this: everything must run under a user context. Every process needs a to have a windows user owning it.

The SQLCMD you are running — who is the windows user running it? it isn’t you. It is the SQL Server service. (do some research on xp_cmdshell)

You first need to do some research on windows service accounts and understand what they are.

Then, some possible solutions:

A. Check what your QA SQL Server service is running as (in the logon tab in services.msc)
B. USe a linked server insteadm which can use your logon instead
C. You might also be able to use some kind of proxy (a windows user to override the SQL Service user just for this pupose) but I haven’t investigated that.

answered Apr 29, 2014 at 10:13

Nick.McDermaid's user avatar

Nick.McDermaidNick.McDermaid

17.6k6 gold badges55 silver badges89 bronze badges

I have posted a related question few days back and provided its answer as well.

I am facing a strange issue, I have 2 servers first one is dev server and second is QA

When I execute the below line on dev server it works fine, but when I execute it on QA, it gives me the error Login failed for user 'NT AUTHORITYANONYMOUS LOGON', as I posted in my previous question.

EXEC master.dbo.xp_cmdshell ‘sqlcmd -D db_name -S server_name -i sqlfile’ 

To resolve the above issue I have provided the username and pwd in the above query and it is working fine on both DEV and QA server. But to provide the username and pwd is not a nice approach as if we will change the server or pwd it directly impacts my query. So I want to execute the cmdshell command without using username and pwd on QA as well.

Can anyone please tell me what I am missing on QA. I have already provided the permissions to cmdshell on QA

ANY QUICK HELP

Community's user avatar

asked Apr 29, 2014 at 7:17

user3124690's user avatar

4

This is because the user the command runs as is NT AUTHORITYANONYMOUS LOGON, and this login does not have access to the DB.

Consider this: everything must run under a user context. Every process needs a to have a windows user owning it.

The SQLCMD you are running — who is the windows user running it? it isn’t you. It is the SQL Server service. (do some research on xp_cmdshell)

You first need to do some research on windows service accounts and understand what they are.

Then, some possible solutions:

A. Check what your QA SQL Server service is running as (in the logon tab in services.msc)
B. USe a linked server insteadm which can use your logon instead
C. You might also be able to use some kind of proxy (a windows user to override the SQL Service user just for this pupose) but I haven’t investigated that.

answered Apr 29, 2014 at 10:13

Nick.McDermaid's user avatar

Nick.McDermaidNick.McDermaid

17.6k6 gold badges55 silver badges89 bronze badges

Я
   imepic

13.01.15 — 10:47

Идет примерно через 1 мин.

Текст: «Ошибка входа пользователя «NT AUTHORITYсистема». Причина: не удалось открыть явно указанную базу данных. [КЛИЕНТ: 127.0.0.1]»

Профайлером нашел, что источник — 1CV83 Server

На сервере типовые Дилион УМ, БП, ЗУП. Где еще можно поискать?

   Бубка Гоп

1 — 13.01.15 — 10:49

Идет примерно через 1 мин

после чего?

   imepic

2 — 13.01.15 — 10:51

с интервалом в 1 мин. после переноса диска с ОС на SSD несколько дней назад…

   Бубка Гоп

3 — 13.01.15 — 10:53

база на SQL?

   imepic

4 — 13.01.15 — 10:55

да базы на MS SQL Server 2008 R2

   imepic

5 — 13.01.15 — 20:51

переустановка платформы не помогла… ну что совсем никто ничего не знает? весь лог этой ошибкой забит…

   krbIso

6 — 13.01.15 — 21:03

на сервере 1С есть зерегенная база, которая ломится в SQL и данную базу там не находит (либо прав нет, либо базы нет)

  

imepic

7 — 13.01.15 — 21:33

krbIso спасибо! это и было! базу, похоже, кто-то удалил через sql serv managment studio..

TurboConf — расширение возможностей Конфигуратора 1С

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.



приложение, которое работает без проблем (и не было никакой активной разработки сделано на нем около 6 месяцев или около того) недавно начал не удается подключиться к базе данных. Администраторы операций не могут сказать, что могло бы измениться, что вызвало бы проблему.

клиентское приложение использует жестко закодированную строку подключения с Integrated Security=True, но когда приложения пытаются создать соединение с базой данных, оно выдает исключение SQLException со словами » ошибка входа для пользователя ‘NT AUTHORITYANONYMOUS LOGON».

Я могу войти в базу данных через Management Studio на этой учетной записи без проблем. Все вещи, которые я видел для этой проблемы, предназначены для ASP.NET проекты, и это, по-видимому, «проблема двойного прыжка», которая является клиентским приложением чертовски хорошо, лучше не быть проблемой. Любая помощь будет очень признательна.

Edit

клиентская машина и серверная машина, а также учетные записи пользователей находятся на одном и том же домен.
Это происходит, когда Брандмауэр Windows выключен.

ведущая теория:
Сервер был перезапущен около недели назад, и не удалось зарегистрировать имя участника-службы (SPN). Сбой регистрации имени участника-службы может привести к возвращению встроенной проверки подлинности в NTLM вместо Kerberos.


925  


5  

5 ответов:

Если ваша проблема связана с серверами, вы должны смотреть на несколько вещей.

во-первых, ваши пользователи должны иметь делегирование включено, и если единственное, что изменилось, это, вероятно, они делают. В противном случае вы можете снять флажок «учетная запись чувствительна и не может быть делегирована» — это свойства пользователя в AD.

во-вторых, ваша учетная запись(ы) службы должна быть доверенной для делегирования. Поскольку вы недавно изменили свою учетную запись службы, я подозреваю, что это виновник. (http://technet.microsoft.com/en-us/library/cc739474 (v=ws.10).aspx)

вы упомянули, что у вас могут быть некоторые проблемы с SPN, поэтому обязательно установите SPN для обеих конечных точек, иначе вы не сможете увидеть вкладку делегирование в AD. Также убедитесь, что вы находитесь в расширенном виде в «Active Directory-пользователи и компьютеры.»

Если вы все еще не видите вкладку делегирование, даже после исправления SPN, убедитесь, что ваш домен не в режиме 2000. Если это так, вы можете «повышение уровня функционирования домена.»

теперь вы можете отметить учетную запись как доверенную для делегирования:

в области сведений щелкните правой кнопкой мыши пользователя, которому вы хотите доверять
делегирование и нажмите кнопку Свойства.

перейдите на вкладку делегирование, выберите Учетная запись доверена для делегирования
установите флажок и нажмите кнопку ОК.

наконец, Вам также нужно будет установить все машины как доверенные для делегирования.

Как только вы это сделаете, снова подключитесь к sql server и протестируйте свои любимые серверы. Они должны работать.

во-первых: моя проблема не такая же, как у вас, но этот пост-первое, что появляется в google для Login failed for user 'NT AUTHORITYANONYMOUS LOGON' ошибка в то время, когда я написал это. Решение может быть полезно для людей, ищущих эту ошибку, поскольку я не нашел это конкретное решение в любом месте в интернете.

в моем случае я использовал Xampp / Apache и PHP sqlsrv, чтобы попытаться подключиться к базе данных MSSQL с помощью проверки подлинности Windows и получил Login failed for user 'NT AUTHORITYANONYMOUS LOGON' ошибка, которую вы описали. Я, наконец, нашел проблему быть самой службой Apache, работающей под пользователем «LOCAL SERVICE»вместо учетной записи Пользователя, в которую я вошел. Другими словами, он буквально использовал анонимный аккаунт. Было принято решение ехать в сервис.msc, щелкните правой кнопкой мыши службу Apache, перейдите в Свойства, перейдите на вкладку Вход в систему и введите учетные данные для пользователя. Это соответствует вашей проблеме, связанной с SPN, поскольку ваши SPN настроены для запуска от определенного пользователя в домене. Поэтому, если правильное имя участника-службы не работает, окна аутентификация будет по умолчанию для неправильного пользователя (вероятно, пользователя «локальной службы») и даст вам анонимную ошибку.

вот где это отличается от вашей проблемы. Ни один из компьютеров в локальной сети не находится в домене, они находятся только в рабочей группе. Чтобы использовать проверку подлинности Windows с рабочей группой, как компьютер с сервером (в моем случае MSSQL Server), так и компьютер со службой запроса данных (в моем случае Apache) должны иметь пользователя с одинаковым именем и идентичный пароль.

подведем итоги:Login failed for user 'NT AUTHORITYANONYMOUS LOGON' ошибка в обоих наших случаях, по-видимому, вызвана не запущенной службой и/или не на правильном пользователе. Обеспечение правильного SPN или другой службы выполняется и под правильным пользователем должно решить анонимную часть проблемы.

Я думаю, что должно было быть какое-то изменение в группе объявлений, используемой для аутентификации в базе данных. Добавить название веб-сервера, в форматесервера домен$, в группе объявлений, которые имели доступ к базе данных. Кроме того, также попробуйте установить веб.config атрибут «false». Надеюсь, это поможет.

EDIT: идя по тому, что вы редактировали.. это, скорее всего, указывает на то, что протокол проверки подлинности вашего SQL Server откатился от Kerberos(по умолчанию, если вы использовали встроенную проверку подлинности Windows) для NTLM. Для использования Kerberos имя участника-службы (SPN) должно быть зарегистрировано в службе каталогов Active Directory. Имя участника — службы (SPN) — это уникальные идентификаторы служб, запущенных на серверах. Для каждой службы, которая будет использовать проверку подлинности Kerberos, необходимо задать имя участника-службы, чтобы клиенты могли идентифицировать службу в сети. Он зарегистрирован в Active Directory под учетной записью компьютера или учетной записью пользователя. Хотя Протокол Kerberos используется по умолчанию, если по умолчанию происходит сбой, процесс проверки подлинности будет опробован с помощью NTLM.

в вашем сценарии клиент должен устанавливать tcp-соединение, и он, скорее всего, работает под учетной записью LocalSystem, и для экземпляра SQL не зарегистрировано SPN, следовательно, используется NTLM, однако учетная запись LocalSystem наследует от системного контекста вместо истинного пользовательского контекста, таким образом, не удалось выполнить «анонимный вход».

чтобы решить эту проблему, спросите свой домен администратор вручную зарегистрировать имя участника-службы, если SQL Server работает под учетной записью пользователя домена.
Следующие ссылки могут помочь вам more:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801

У одного из моих заданий SQL была такая же проблема. Он включал в себя загрузку данных с одного сервера на другой. Ошибка произошла, потому что я использовал учетную запись службы агента sql Server. Я создал учетные данные, используя идентификатор пользователя (который использует проверку подлинности окна), общий для всех серверов. Затем создал прокси-сервер, используя эти учетные данные. Использовал прокси-сервер в задании sql server, и он работает нормально.

вам, вероятно, просто нужно указать имя пользователя и пароль в вашей connectionstring и установить Integrated Security=false

В этой статье мы рассмотрим часто встречающиеся ошибки и методы их устранения.

1. Ошибка: Ошибка инициализации конфигурации ELMA —> System.InvalidOperationException: Cannot check database exists —> System.Data.SqlClient.SqlException: Ошибка входа пользователя «IIS APPPOOLElma3-Standart».

Причина: Авторизация на сервере IIS осуществлена под пользователем не имеющим прав администратора.

Решение: Для устранения данной ошибки IIS сервера необходимо зайти в Диспетчер служб IIS (стандартно на сервере в Пуск – Администрирование). В нем на вкладке Пулы приложений у пула «ELMA3-Standart» выбрать в контекстном меню пунк Дополнительные параметры. В нем, в таблице Модель процесса, в поле Удостоверение указать учетную запись LocalSystem либо реальную учетную запись с правами администратора, после чего следует перезапустить веб-сервер.

2. Ошибка: The underlying connection was closed: An expected error occurred on a receive: Unable to read data from the transport connection: Удаленный хост разорвал существующее подключение: Удаленный хост разорвал существующее подключение.

Причина: Сервер ELMA запущен с недостаточными правами доступа.

Решение: В случае, если сервер располагается на базе Cassini, Вам необходимо нажать клавишу с логотипом Windows (флажок Microsoft) + R и ввести следующую команду в диалоговое окно: «services.msc» (без кавычек), после чего появится окно служб Windows. В нем Вы сможете найти строчку Веб-сервер ELMA, кликнуть правой кнопкой мыши и выбрать пункт Свойства, в котором и располагается искомая вкладка Вход в систему. Если же сервер основывается на базе IIS, то в этом случае необходимо так же открыть меню Выполнить (клавиша Windows + R) и ввести команду inetmgr. Откроется окно диспетчера служб IIS, в окне Подключения найдите пункт Пулы приложений, выделите его, откроется список текущего пула, где и должна быть запись о сервере ELMA. Также кликнув правой кнопкой мыши на записи, выберите пункт Дополнительные параметры. Нужная запись находится в строке Удостоверение указажите учетную запись LocalSystem либо реальную учетную запись с правами администратора, после чего следует перезапустить веб-сервер.

3. Ошибка: *System.UnauthorizedAccessException: Отказано в доступе по пути «С:ELMA3-ExpressUserConfigconfiguration.packges».

Решение: Удаление файла с расширением .packages из папки UserConfig.

4. Ошибка: Сервер не запущен из-за ошибки.

Причина: Имена в SQL Server Management Studio базы и файле configuration.config не совпадают.

Решение: Изменение названия БД в файле configuration.config.

5. Ошибка: Ошибка создания резервной копии данных.

Причина:Недостаточно места на диске.

Решение: Освободить место для корректного создания бекапа базы.

6. Ошибка: EleWise.ELMA.Runtime.Db.DbStructureException: Ошибка обновления структуры БД —> System.Data.DataException: Не удалось выполнить запрос DROP INDEX UK_principal_name ON sysdiagrams —> System.Data.SqlClient.SqlException: Явная инструкция DROP INDEX недопустима в индексе «sysdiagrams.UK_principal_name». Он используется для принудительного применения ограничения UNIQUE KEY.

Причина: В SQL Server Management Studio, в разделе Системные таблицы не должно быть таблиц.

Решение: Остановите сервер ELMA и откройте SQL Server Management Studio, в списке баз данных выберите нужную БД и разверните список таблиц. В разделе Системные таблицы не должно быть таблиц. Если они там есть, удалите их. Запустите сервер ELMA.

7. Ошибка: Ошибка из-за наличия активных подключений к БД.

Причина: После восстановления базы из бекапа на сервере со временем отличным от предыдущего может остаться информация об активном подключении.

Решение: Создание резервной копии и выполнение запроса в БД. Текст запроса: Delete from DB_ACTIVECONNECTIONS.

8. Ошибка: EleWise.ELMA.Runtime.Db.DbStructureException: Ошибка обновления структуры БД —> NHibernate.TransactionException: Commit failed with SQL exception —> FirebirdSql.Data.FirebirdClient.FbException: unsuccessful metadata update

object INDEX is in use —> FirebirdSql.Data.Common.IscException: unsuccessful metadata update

Причина: Ошибка обновления.

Решение: Сделайте резервное копирование базы и восстановите ее. (Для корректной работы системы на FireBird данную операцию необходимо производить с периодичностью раз в две недели).

9. Ошибка: *EleWise.ELMA.Runtime.Exceptions.ConfigurationInitializeException: Ошибка инициализации конфигурации ELMA —> System.InvalidOperationException: Не удалось подключиться к базе данных —> FirebirdSql.Data.FirebirdClient.FbException: Unable to complete network request to host «127.0.0.1». —> FirebirdSql.Data.Common.IscException: Unable to complete network request to host «127.0.0.1».

Причина: Ошибка в файле configuration.config в строке <add name=»MainDB» connectionString=»data source=127.0.0.1;initial catalog={CONFIGDIR}base.fdb;user id=sysdba;password=masterkey;character set=UNICODE_FSS;dialect=3;server type=0″ />.

Решение: Убедиться, что в строке<add name=»MainDB» connectionString=»data source=127.0.0.1;initial catalog={CONFIGDIR}base.fdb;user id=sysdba;password=masterkey;character set=UNICODE_FSS;dialect=3;server type=0″ /> отсутствуют опечатки, соблюден регистр символов.

10. Ошибка: *EleWise.ELMA.Runtime.Exceptions.ConfigurationInitializeException: Ошибка инициализации конфигурации ELMA —> System.InvalidOperationException: Не удалось подключиться к базе данных —> System.Data.SqlClient.SqlException: Не удается открыть базу данных «ELMA», запрашиваемую именем входа. Не удалось выполнить вход.
Ошибка входа пользователя «NT AUTHORITYсистема».

Причина: Авторизация на сервере Cassini осуществлена под пользователем не имеющим прав администратора.

Решение: Необходимо запустить сервер Elma от имени учетной записи, обладающей правами администратора в Windows. Для этого зайдите в Панель управления – Администрирование – Службы, найдите там Веб-сервер Elma, щелкните по нему правой кнопкой мыши, выберите Свойства, в открывшемся окне перейдите на вкладку Вход в систему, установите флажок С учетной записью и введите данные учетной записи, обладающей правами администратора.

Дополнение: Ошибка сервера MS SQL 2008 и выше Login failed for user ’NT AUTHORITYсистема’. Причина: не удалось открыть явно указанную базу данных «ELMA». [КЛИЕНТ: <local machine>]. Ошибка: 18456, серьезность: 14, состояние: 38.

Причина: Авторизация верная, запуск происходит с правами администратора, но база данных недоступна (или нет разрешения).

Решение: Группе NT AUTHORITYсистема необходимо добавить роль sysadmin на SQL сервере. Для этого зайдите Microsoft SQL Server Management Studio, раздел Безопасность – Имена входа и выберите свойства группы NT AUTHORITYсистема. В меню Роли сервера установите флажок напротив роли sysadmin.

11. Ошибка: *EleWise.ELMA.Runtime.Exceptions.ConfigurationInitializeException: Ошибка инициализации конфигурации ELMA —> System.InvalidOperationException: Не удалось подключиться к базе данных —> System.Data.SqlClient.SqlException: Разрешение CREATE DATABASE запрещено в базе данных «master».
Не удалось присоединить файл «F:ELMA3-StandartUserConfigELMA3.mdf» в качестве базы данных «ELMA3».

Причина: Ошибка в файле configuration.config в строке AttachDbFilename={CONFIGDIR}ELMA3.mdf;

Решение: Удалить строку «AttachDbFilename={CONFIGDIR}ELMA3.mdf» в конфигурационном файле configuration.config. После внесенных изменений файл необходимо сохранить и перезапустить веб-сервер.

12. Ошибка: При работе с веб-частью отображается всплывающее окно с ошибкой Не пройдена проверка предусловий запуска.

Соответственно, при попытке авторизации в Дизайнере возникает ошибка.

Причина: В окне ошибки виден пустой параметр – имя сервера.

Решение: подключиться к серверу MSSQL от имени администратора и выполнить правильный SQL-запрос:

EXEC sp_dropserver N'elma-local-loop'
GO

EXEC sp_addlinkedserver N'elma-local-loop', N' ', N'SQLNCLI', N'localhostSQLSERVER2014'
GO

EXEC sp_serveroption [elma-local-loop], N'remote proc transaction promotion', 'false'
EXEC sp_serveroption [elma-local-loop], N'rpc out', 'true'
GO

где localhostSQLSERVER2014 – имя сервера базы данных.

Чтобы убедиться, что ошибка исправлена, нужно выполнить запрос:

select * from sys.servers where lower([name]) = 'elma-local-loop'

Результат будет выглядеть следующим образом:

13. Ошибка: Ошибка Инициализации конфигурации ELMA: Версия БД <название версии> не подходит по минимальным требованиям (предоставлена версия – <используемая версия БД>, требуется как минимум <версия БД, необходимая для корректной работы системы ELMA>

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

Решение: необходимо обновить версию используемой базы данных до соответствующей минимальным системным требованиям для используемой редакции системы ELMA.

14. Ошибка: DbStructure files with the same GUID are found <uid>: <модуль1>;<модуль2> – в модулях системы содержатся xml-преобразования базы данных с одинаковыми uid.

Причина: в указанных модулях системы (модуль1, модуль2) содержатся xml-преобразования базы данных с одинаковыми uid.

Решение: изменить дублирующийся uid в одном из модулей.

15. Ошибка: Npgsql.NpgsqlException: No password has been provided but the backend requires one (in MD5).

Решение: Если отсутствуют права суперпользователя по умолчанию, если они не были указаны при установке, укажите их в файле configuration.config, который располагается в папке конфигурации ELMA, по умолчанию ../<Общая папка с файлами системы ELMA>/UserConfig:

  • в секции main добавьте ключи sysUser и sysPassword со значениями для пользователя – владельца базы данных;
  • для этого случая желательно отключить автоматическое резервное копирование данных, добавив ключ backupEnabled со значением false.

Пример настроек представлен на рисунке.

16. Иногда при работе в системе могут возникнуть ошибки из-за прав, которые настраиваются в IIS.

Например, если пул ELMA4 в IIS запускается под ApplicationPoolIdentity, то при импорте пакетов, требующем перезапуска сервера, возникает следующая ошибка:

«ERROR 2021-03-04 16:02:13,055 [5] EleWise.ELMA.Logging.Logger — Во время выполнения автоматического импорта произошла ошибка: В процессе импорта произошла ошибка: Не удалось проверить статус запуска сайта ‘ELMA-Enterprise-4_0_7’ в IIS. Скорее всего, у пользователя, под которым запущен пул приложений IIS, отсутствуют необходимые привилегии».

Оригинальный текст ошибки:
«Имя файла: redirection.config
Ошибка: Не удалось прочитать файл конфигурации из-за отсутствия необходимых разрешений».

При этом группе IIS_IUSRS выданы полные права на папку с системой и C:WindowsTempELMA.

В этом случае проблема возникает из-за отсутствия прав. Решение проблемы — это вопрос администрирования.

ApplicationPoolIdentity — учётная запись с минимальными правами. То, что требует ELMA4 (управление сайтом, чтение данных пула и др.), эта учётная запись по умолчанию не обеспечивает.

В этом случае варианта решения два:

1. Если политика безопасности позволяет, изменить удостоверение пула приложений.

2. Выдать права для работы под ApplicationPoolIdentity или той учётной записью, под которой работает администратор. Для IIS_IUSRS выдать права на %SystemRoot%System32inetsrvconfig.

17. Ошибка: *EleWise.ELMA.Runtime.Db.DbStructureException: Ошибка обновления структуры БД —> Oracle.ManagedDataAccess.Client.OracleException: ORA-00054: ресурс занят и задано его получение с параметром NOWAIT, либо истекло время ожидания.

Решение:

1. Убедиться, что в схеме нет блокировок.

2. Увеличить таймауты запросов в базу. Для этого в файле ~Websettings.config:

  • изменить значение value для ключа <add key=DbTransformCommandTimeout” value=“3600” />, например, выставить value=“7200”;
  • изменить значение value для ключа <add key=“Application.DbCommandTimeout” value=“30” />, например, выставить значение value=“120”.
  • Remove From My Forums
  • Общие обсуждения

  • Добрый день

    Тестируем новые продукты. Для этого развернут тестовый домен на 2 контроллерах W2008R2, на сервере с W2008R2 установлен SQL Enterprise 2008R2 с SP1 и всеми обновлениями.

    Развернуто 2 инстанса — по умолчанию и именованный. Для одного продукта используется дефолтный, для другого (SCCM 2012) — именованный. ПО требованиям установки SCCM на весь экземпляр выставлена соотв. сортировка (LATIN….)

    Экземпляр по умолчанию работает от имени local service и с ним проблем нет, а для именованного завели служебную учетку (хотя сначала пробовали и с local service), но по-прежнему в лог каждую минуту сыпятся
    ошибки:

    Успешно выполнен вход пользователя «NT AUTHORITYLOCAL SERVICE» в систему. Соединение установлено с использованием проверки подлинности Windows. [КЛИЕНТ: <local machine>]

    Ошибка входа пользователя «NT AUTHORITYLOCAL SERVICE». Причина: не удалось открыть явно указанную базу данных. [КЛИЕНТ: <local machine>]

    Права на базу master выставлены как и в дефолтном экземпляре — просто Public. Пробовали и давали права даже sysadm — не помогает.

    В случае перевод экземпляра на доменную учетку — ошибка та же самая.

    Что не так? Сервер перезагружали, учетки меняли, права даже самые максимальные выдавали. Ошибка постоянно идет.

    • Изменен тип

      26 февраля 2014 г. 10:00

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Ошибка входа пользователя nt authority анонимный вход
  • Ошибка второго цилиндра пежо 308