Установка роли останавливается на общей ошибке, а журнал событий почти ничего не даёт для работы. На серверах, где это происходит, недостающий кусок вовсе не в мастере: служба Remote Access никогда не покидает состояние Starting. Роль, которая не может завершить свою инициализацию, снова терпит неудачу при каждой попытке, поэтому сначала идёт служба, а мастер — вторым. Исправление права входа занимает минуты, а повторная переустановка роли — нет.

Начинайте со службы, а не с мастера роли

Откройте командную строку с повышенными правами и прочитайте конфигурацию службы, прежде чем трогать роль. Важны два значения: тип запуска и учётная запись, под которой работает служба. Установка по умолчанию регистрирует службу для автоматического, отложенного запуска под Network Service.

Если состояние остаётся в Starting, а не в Running, служба ждёт чего-то, чего не может получить, и право входа — обычный кандидат. Более долгое ожидание не помогает, потому что запуск уже не удался так, как Service Control Manager сообщает о нём как об ожидающем. Остановите службу чисто и прочитайте её конфигурацию ещё раз. Затем посмотрите на попытку запуска службы в журнале событий, потому что именно там имя учётной записи появляется рядом с ошибкой.

Мастер роли сообщает только о том, что инициализация не удалась, и именно поэтому диагностика службы должна быть первой.

Прочитайте право входа перед переустановкой

Network Service нужно право входа в качестве службы, чтобы запуститься. Встроенные учётные записи обычно получают его через членство в группе, а усиленный базовый профиль или обновление политики могут его отобрать. Групповая политика побеждает при следующем обновлении, поэтому ручное предоставление может снова исчезнуть без предупреждения.

Экспортируйте локальную политику безопасности и прочитайте запись вместо того, чтобы доверять GUI. Это оставляет вам файл для сравнения после обновления, и только так можно узнать, пережило ли изменение. Если запись пуста или пропускает учётную запись, вы нашли неисправность. Запишите, какой объект политики её задаёт, потому что именно этому объекту нужна постоянная правка.

secedit /export /cfg C:\Windows\Temp\secpol-export.inf
Select-String -Path C:\Windows\Temp\secpol-export.inf -Pattern SeServiceLogonRight
sc.exe qc RemoteAccess
Get-Service RemoteAccess | Format-List Name, Status, StartType

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

Обратный проход учётной записи, который переписывает конфигурацию

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

Проход переписывает запись службы и снова даёт учётной записи нужное право. Это обходной путь, а не исправление первопричины, поэтому ему место в журнале изменений с датой рядом. Там, где сервером управляет базовый профиль, правильное исправление — добавить учётную запись в назначение входа как службы в этом профиле. Сделайте это первым, когда можете, а проход используйте только чтобы разблокировать установку, которая иначе застряла.

sc.exe config RemoteAccess obj= "NT AUTHORITY\LocalService" start= demand
Start-Service RemoteAccess
sc.exe config RemoteAccess obj= "NT AUTHORITY\NetworkService" start= delayed-auto
Start-Service RemoteAccess

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

Установите роль и докажите, что она установлена

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

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools
Get-WindowsFeature RemoteAccess, DirectAccess-VPN, Routing
Get-Service RemoteAccess

Убедитесь, что подфункции сообщают Installed, а не Available, затем откройте консоль и завершите начальную настройку, прежде чем кто-либо другой коснётся машины. Если консоль всё ещё утверждает, что служба не работает, вернитесь к проверке службы вместо того, чтобы удалять роль.

Запишите, что вы изменили

Первые выборы мастера задают правила брандмауэра, распределение адресов и то, ожидает ли сервер ретранслятор DHCP. Нескольким клиентам «точка — площадка» не нужна форма конечной точки «площадка — площадка». Решите насчёт роли, пула адресов, метода проверки подлинности и источника сертификата до того, как начнёте нажимать. Догадки здесь дают сервер, который чисто устанавливается и никогда не принимает подключение.

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

Похожие статьи