L’installation de RRAS échoue parce que le service RemoteAccess se bloque

L’installation du rôle s’arrête sur une erreur générique et le journal des événements n’offre presque rien avec quoi travailler. Sur les serveurs où cela se produit, la pièce manquante n’est pas du tout dans l’assistant : le service Remote Access ne quitte jamais l’état Starting. Un rôle qui ne peut pas terminer sa propre initialisation échoue de nouveau à chaque tentative, donc le service passe d’abord et l’assistant ensuite. Réparer le droit d’ouverture de session prend quelques minutes, réinstaller le rôle encore et encore ne le fait pas.

Commencez par le service, pas par l’assistant du rôle

Ouvrez une invite élevée et lisez la configuration du service avant de toucher au rôle. Deux valeurs comptent : le type de démarrage et le compte sous lequel le service s’exécute. Une installation par défaut enregistre le service pour un démarrage automatique et différé sous Network Service.

Si l’état reste sur Starting plutôt que Running, le service attend quelque chose qu’il ne peut pas obtenir, et le droit d’ouverture de session est le candidat habituel. Attendre plus longtemps n’aide pas, car le démarrage a déjà échoué d’une manière que le Service Control Manager signale comme en attente. Arrêtez le service proprement et relisez sa configuration. Regardez ensuite la tentative de démarrage du service dans le journal des événements, car c’est là que le nom du compte apparaît à côté de l’échec.

L’assistant du rôle rapporte seulement que l’initialisation a échoué, et c’est exactement pourquoi le diagnostic du service vient en premier.

Lisez le droit d’ouverture de session avant de réinstaller

Network Service a besoin du droit d’ouverture de session en tant que service pour démarrer. Les comptes intégrés le reçoivent normalement par l’appartenance à un groupe, et une base de référence durcie ou un rafraîchissement de stratégie peut le retirer. La stratégie de groupe l’emporte au rafraîchissement suivant, donc une attribution manuelle peut disparaître de nouveau sans avertissement.

Exportez la stratégie de sécurité locale et lisez l’entrée au lieu de faire confiance à l’interface graphique. Cela vous laisse un fichier à comparer après un rafraîchissement, et c’est le seul moyen de savoir si le changement a survécu. Si l’entrée est vide ou omet le compte, vous avez trouvé le défaut. Notez quel objet de stratégie le définit, car c’est cet objet qui a besoin de la correction permanente.

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

Une attribution appliquée localement et écrasée par la stratégie au rafraîchissement suivant ressemble à une réparation qui a cessé de fonctionner, et elle échouera de la même manière à nouveau.

L’aller-retour de compte qui réécrit la configuration

Un raccourci répare la configuration d’ouverture de session du service sans éditer la stratégie à la main : changez le compte, appliquez, puis remettez-le avec les champs de mot de passe vides.

L’aller-retour réécrit l’enregistrement du service et accorde de nouveau le droit dont le compte a besoin. C’est un contournement et non une correction de la cause première, il appartient donc au journal des changements avec une date à côté. Là où une base de référence gère le serveur, la réparation correcte est d’ajouter le compte à l’affectation d’ouverture de session en tant que service dans cette base. Faites-le d’abord quand vous le pouvez, et n’utilisez l’aller-retour que pour débloquer une installation qui est autrement coincée.

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

Lisez l’état après chaque commande, car un service qui démarre sous un compte et pas sous l’autre vous indique quel droit manque.

Installez le rôle et prouvez qu’il est installé

Une fois le service en marche, ajoutez de nouveau le rôle et incluez la sous-fonction VPN que vous comptez réellement utiliser. Le rôle générique à lui seul ne vous donne pas de point de terminaison VPN fonctionnel.

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

Confirmez que les sous-fonctions rapportent Installed plutôt que Available, puis ouvrez la console et terminez la configuration initiale avant que quiconque d’autre touche à la machine. Si la console prétend encore que le service ne tourne pas, revenez à la vérification du service au lieu de supprimer le rôle.

Notez ce que vous avez changé

Les premiers choix de l’assistant définissent les règles de pare-feu, l’attribution d’adresses et si le serveur attend un relais DHCP. Une poignée de clients point à site n’a pas besoin de la forme d’un point de terminaison site à site. Décidez le rôle, le pool d’adresses, la méthode d’authentification et la source du certificat avant de cliquer. Deviner ici produit un serveur qui s’installe proprement et n’accepte jamais de connexion.

Gardez l’écart du compte de service dans la même note. Une passe de durcissement qui remet le compte par défaut peut restaurer le défaut au prochain redémarrage, des mois après que celui qui l’a diagnostiqué est passé à autre chose.