Недавно я установил Microsoft SQL Server 2012 на новую установку Windows 7, но всякий раз, когда я хочу запустить сервер, я получаю следующую ошибку:
Ошибка 1069: служба не запускалась из-за сбоя входа в систему.
Следующий пользователь настроен для запуска службы: NT Service\MSSQL$SQLEXPRESS
Как я могу исправить эту проблему?
Ответ на этот вопрос может быть идентичен проблеме с полностью раздутым SQL Server (NTService\MSSQLSERVER), и это означает reset пароль. Ирония заключается в том, что пароля нет.
Шаги:
Это должно повторно предоставить доступ к службе, и она должна снова запуститься. Weird?
ПРИМЕЧАНИЕ. Если проблема вернется через несколько часов или дней, у вас, вероятно, есть групповая политика, которая переопределяет ваши настройки, и она приближается и снова уходит.
В то время как ( "работать как SYSTEM" ), людям следует сообщить, что это означает переход от учетной записи с минимальным разрешением к учетной записи, которая имеет все разрешения в мире. Это не рекомендуемые рекомендации или рекомендации по безопасности.
Если вы знаете, что делаете, и знаете, что ваш SQL Server всегда будет работать в изолированной среде (то есть не в гостиничном или аэропортовом Wi-Fi), это, вероятно, прекрасно, но это создает очень реальный вектор атаки, который может полностью поставить под угрозу машину если в открытых интернетах.
Это, кажется, ошибка в части Microsoft, и люди должны знать о последствиях опубликованного обходного пути.
Это случилось со мной. Политика в домене отнимала учетную запись пользователя SQL Server "Войти как услуга". Вы можете обойти это с помощью решения JLo, но не решаете проблему групповой политики, и он будет возвращен в следующий раз, когда политики группы будут обновлены на машине.
Конкретная политика, вызывающая проблему для меня, была: В разделе "Конфигурация компьютера" → "Параметры Windows" → "Параметры безопасности" → "Локальные политики" → "Назначения прав пользователя": выполните вход в систему как служба
Вы можете видеть, какие политики применяются к вашему компьютеру, выполнив команду "rsop" из командной строки. Следуйте по пути к политике, указанной выше, и вы увидите ее текущее значение, а также какой GPO установили значение.
У меня была аналогичная проблема, которая была решена следующим образом:
Если пользователь является пользователем домена, используйте имя пользователя и пароль домена
Краткий ответ:
установите инструменты удаленного администрирования сервера на своем 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.
Одна из возможностей заключается в том, что установленные серверные инструменты данных SQL, в то время как сервер sql уже настроен.
Решение: - 1. Просто восстановите сервер sql с установленным экземпляром
если решение не работает, чем это стоит ваше время, вмешиваясь в services.msc