SQL Server 2012 не может запускаться из-за сбоя входа в систему

Ответ 1

Ответ на этот вопрос может быть идентичен проблеме с полностью раздутым SQL Server (NTService\MSSQLSERVER), и это означает reset пароль. Ирония заключается в том, что пароля нет.

Шаги:

• Щелкните правой кнопкой мыши Сервис в Сервисах mmc
• Нажмите "Свойства"
• Нажмите вкладку "Вход в систему" ​​
• В полях пароля появятся записи в них...
• Пустое поле "Пароль"
• Нажмите "ОК"

Это должно повторно предоставить доступ к службе, и она должна снова запуститься. Weird?

ПРИМЕЧАНИЕ. Если проблема вернется через несколько часов или дней, у вас, вероятно, есть групповая политика, которая переопределяет ваши настройки, и она приближается и снова уходит.

Ответ 2

В то время как ( "работать как SYSTEM" ), людям следует сообщить, что это означает переход от учетной записи с минимальным разрешением к учетной записи, которая имеет все разрешения в мире. Это не рекомендуемые рекомендации или рекомендации по безопасности.

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

Это, кажется, ошибка в части Microsoft, и люди должны знать о последствиях опубликованного обходного пути.

Ответ 3

Это случилось со мной. Политика в домене отнимала учетную запись пользователя SQL Server "Войти как услуга". Вы можете обойти это с помощью решения JLo, но не решаете проблему групповой политики, и он будет возвращен в следующий раз, когда политики группы будут обновлены на машине.

Конкретная политика, вызывающая проблему для меня, была: В разделе "Конфигурация компьютера" → "Параметры Windows" → "Параметры безопасности" → "Локальные политики" → "Назначения прав пользователя": выполните вход в систему как служба

Вы можете видеть, какие политики применяются к вашему компьютеру, выполнив команду "rsop" из командной строки. Следуйте по пути к политике, указанной выше, и вы увидите ее текущее значение, а также какой GPO установили значение.

Ответ 4

У меня была аналогичная проблема, которая была решена следующим образом:

• В Service.MSC перейдите на вкладку "Вход в систему" ​​и добавьте пользователя с минимальными привилегиями и паролем (в службе, которая бросает ошибку входа).
• Запуск сервера Sql для запуска в качестве администратора

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

Ответ 5

Краткий ответ:
установите инструменты удаленного администрирования сервера на своем SQL Server (это дополнительная функция Windows Server), перезагрузитесь, затем запустите диспетчер конфигурации SQL Server, получите доступ к настройкам службы для каждой из служб, чья учетная запись входа начинается с "NT Service...", очистите поля пароля и перезапустите службу. Под обложками диспетчер конфигурации SQL Server назначит этим виртуальным учетным записям "Вход в систему как право службы", и вы будете в пути.

ТЛ; дг;

Существует привязка-22 между настройками по умолчанию для домена Windows и стандартной установкой SQL Server 2012 по умолчанию.

Как уже упоминалось выше, настройка домена Windows по умолчанию действительно не позволит вам определить "войти в систему как услугу" прямо с помощью редактирования групповой политики на локальном компьютере (по крайней мере, через графический интерфейс), если вы установите модуль Powershell ActiveDirectory (через Remote Server Загрузка инструментов администрирования), вы можете сделать это с помощью сценариев.

И, по умолчанию, установка SQL Server 2012 запускает службы в "виртуальных учетных записях" (префикс NT Service \, например, NT Service\MSSQLServer). Это как учетные записи локальных компьютеров, а не учетные записи домена, но вы по-прежнему не можете назначить они регистрируются как права службы, если ваш сервер подключен к домену. Настройка SQL Server пытается назначить право при установке, а средство управления конфигурацией SQL Server также пытается назначить право при изменении учетной записи входа.

И красивый catch-22 таков: инструменты SQL Server зависят от (некоторых компонентов) RSAT, чтобы назначить вход в систему как право на обслуживание. Если на вашем сервере-члене не установлено RSAT, диспетчер конфигурации SQL Server не выполняет попытку применить эту настройку (несмотря на то, что она прошла все проверочные проверки перед установкой), и вы получите не запускаемые службы.

Единственным намеком на это требование, которое я смог найти в метели SQL Server и документа виртуальной учетной записи, было следующее: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, выполните поиск RSAT.

Ответ 6

Одна из возможностей заключается в том, что установленные серверные инструменты данных SQL, в то время как сервер sql уже настроен.

Решение: - 1. Просто восстановите сервер sql с установленным экземпляром

если решение не работает, чем это стоит ваше время, вмешиваясь в services.msc