Нещодавно я встановив Microsoft SQL Server 2012 на свіжій установці Windows 7, але щоразу, коли я хочу запустити сервер, я отримую таку помилку:
Помилка 1069: Служба не запустилася через помилку входу в систему.
Для запуску служби налаштовано наступного користувача: NT Service\MSSQL$SQLEXPRESS
Як я можу вирішити цю проблему?
Відповіді:
Відповідь на це може бути ідентичною проблемі з повнофункціональним SQL Server (NTService \ MSSQLSERVER), і це полягає у скиданні пароля. Іронічно, що пароля немає.
Кроки:
Це має повторно надати доступ до послуги, і вона повинна запуститися знову. Дивно?
ПРИМІТКА: якщо проблема з’явиться через кілька годин або днів, то, ймовірно, у вас є групова політика, яка перевизначає ваші налаштування, і вона з’являється та приймає негайно знову.
Це сталося зі мною. Політика щодо домену відбирала права облікового запису користувача SQL Server "Увійти як сервіс". Ви можете обійти це, використовуючи рішення JLo, але не вирішує проблему групової політики конкретно, і вона повернеться наступного разу, коли групові політики оновляться на машині.
Конкретною політикою, яка спричинила проблему для мене, було: Під, Конфігурація комп'ютера -> Налаштування Windows -> Налаштування безпеки -> Локальна політика -> Призначення прав користувача: Увійдіть як сервіс
Ви можете побачити, які політики застосовуються до вашої машини, запустивши команду "rsop" із командного рядка. Дотримуйтесь шляху до переліченої вище політики, і ви побачите її поточне значення, а також те, який об'єкт групової політики встановив значення.
Поки функція ("запустити як СИСТЕМУ") працює, людям слід порадити, що це означає перехід від облікового запису типу мінімальних дозволів до облікового запису, який має всі дозволи у світі. Що вкрай не є рекомендованою практикою налаштування чи з точки зору безпеки.
Якщо ви знаєте, що робите, і знаєте, що ваш SQL Server завжди працюватиме в ізольованому середовищі (тобто не в мережі готелю чи аеропорту), це, мабуть, добре, але це створює цілком реальний вектор атаки, який може повністю скомпрометувати машину, якщо вона відкрита Інтернет.
Здається, це помилка з боку Microsoft, і люди повинні знати про наслідки опублікованого обхідного шляху.
Коротка відповідь:
встановіть інструменти віддаленого адміністрування сервера на ваш SQL Server (це необов’язкова функція Windows Server), перезавантажте, потім запустіть диспетчер конфігурацій SQL Server, отримайте доступ до налаштувань служби для кожної з служб, обліковий запис для входу яких починається з «NT Service». . ", очистіть поля пароля та перезапустіть службу. Під обкладинками менеджер конфігурації SQL Server призначить цим віртуальним обліковим записам право входу як служби, і ви вже в дорозі.
tl; dr;
Між налаштуваннями за замовчуванням для домену Windows та встановленням за замовчуванням SQL Server 2012 існує зачіпка.
Як зазначалося вище, налаштування домену за замовчуванням Windows дійсно завадить вам визначити "вхід як послуга" безпосередньо за допомогою редагування групової політики на локальній машині (принаймні за допомогою графічного інтерфейсу; якщо ви встановите модуль Powershell ActiveDirectory (за допомогою інструментів віддаленого адміністрування сервера) ) це можна зробити за допомогою сценарію.
І за замовчуванням установка SQL Server 2012 запускає служби у "віртуальних облікових записах" (префікс NT Service \, наприклад, NT Service \ MSSQLServer. Це як локальні машинні облікові записи, а не облікові записи домену, але ви все одно не можете призначити їх для входу як сервісні права, якщо ваш сервер приєднаний до домену. Налаштування SQL Server намагається призначити право під час інсталяції, а інструмент управління конфігурацією SQL Server також намагається призначити право під час зміни облікового запису для входу.
І прекрасний catch-22 такий: інструменти SQL Server залежать від (якогось компонента) RSAT, щоб призначити вхід як правильний сервіс. Якщо випадково не встановлено RSAT на вашому сервері-учаснику, SQL Server Config Manager не вдається мовчки, намагаючись застосувати цей параметр (незважаючи на всю пишну перевірку перед встановленням, яку він виконує), і ви отримуєте послуги, які не запускаються.
Одним натяком на цю вимогу, яку мені вдалося знайти в хуртовині SQL Server та віртуального облікового запису, був такий: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts , пошук RSAT .
У мене була подібна проблема, яку вирішили наступним чином:
Якщо користувач є користувачем домену, використовуйте ім’я користувача та пароль домену
Я не знаю, наскільки це хороше рішення, але після безуспішного виконання деяких інших відповідей на це питання я вирішив встановити підключення користувача служби MSSQLSERVER до "Локальна служба".
Примітка: я використовую SQL Server 2017.