L’installazione di RRAS non riesce perché il servizio RemoteAccess si blocca
Il ruolo Routing and Remote Access può fallire perché il suo servizio resta bloccato su Starting. Controllate il diritto di accesso come servizio prima di reinstallare qualsiasi cosa.
L’installazione del ruolo si ferma con un errore generico e il registro eventi non offre quasi nulla con cui lavorare. Nei server dove accade, il pezzo mancante non è affatto nella procedura guidata: il servizio Remote Access non lascia mai lo stato Starting. Un ruolo che non riesce a completare la propria inizializzazione fallisce di nuovo a ogni tentativo, quindi il servizio viene prima e la procedura guidata dopo. Riparare il diritto di accesso richiede minuti, reinstallare il ruolo più e più volte no.
Partite dal servizio, non dalla procedura guidata del ruolo
Aprite un prompt elevato e leggete la configurazione del servizio prima di toccare il ruolo. Due valori contano: il tipo di avvio e l’account con cui il servizio viene eseguito. Un’installazione predefinita registra il servizio per un avvio automatico e ritardato sotto Network Service.
Se lo stato resta su Starting invece che su Running, il servizio attende qualcosa che non riesce a ottenere, e il diritto di accesso è il candidato abituale. Attendere più a lungo non serve, perché l’avvio è già fallito in un modo che il Service Control Manager segnala come in sospeso. Fermate il servizio in modo pulito e rileggete la sua configurazione. Poi guardate il tentativo di avvio del servizio nel registro eventi, perché è lì che il nome dell’account compare accanto all’errore.
La procedura guidata del ruolo riporta solo che l’inizializzazione è fallita, ed è proprio per questo che la diagnosi del servizio viene per prima.
Leggete il diritto di accesso prima di reinstallare
Network Service ha bisogno del diritto di accesso come servizio per avviarsi. Gli account predefiniti lo ricevono di norma tramite l’appartenenza a un gruppo, e una baseline rafforzata o un aggiornamento dei criteri possono toglierlo. I criteri di gruppo vincono al successivo aggiornamento, quindi un’assegnazione manuale può sparire di nuovo senza preavviso.
Esportate i criteri di sicurezza locali e leggete la voce invece di fidarvi della GUI. Questo vi lascia un file da confrontare dopo un aggiornamento, ed è l’unico modo per sapere se la modifica è sopravvissuta. Se la voce è vuota o omette l’account, avete trovato il difetto. Annotate quale oggetto dei criteri la imposta, perché è quell’oggetto che necessita della correzione 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
Un’assegnazione applicata localmente e sovrascritta dai criteri all’aggiornamento successivo sembra una riparazione che ha smesso di funzionare, e fallirà di nuovo allo stesso modo.
Il giro di andata e ritorno dell’account che riscrive la configurazione
Una scorciatoia ripara la configurazione di accesso del servizio senza modificare i criteri a mano: cambiate l’account, applicate, poi rimettetelo con i campi password vuoti.
Il giro riscrive il record del servizio e concede di nuovo il diritto che serve all’account. È un aggiramento e non una correzione della causa radice, quindi appartiene al registro delle modifiche con una data accanto. Dove una baseline gestisce il server, la riparazione corretta è aggiungere l’account all’assegnazione di accesso come servizio in quella baseline. Fatelo per primo quando potete, e usate il giro solo per sbloccare un’installazione altrimenti bloccata.
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
Leggete lo stato dopo ogni comando, perché un servizio che parte con un account e non con l’altro vi dice quale diritto manca.
Installate il ruolo e dimostrate che è installato
Con il servizio in esecuzione, aggiungete di nuovo il ruolo e includete la sotto-funzione VPN che intendete davvero usare. Il ruolo generico da solo non vi dà un endpoint VPN funzionante.
Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools
Get-WindowsFeature RemoteAccess, DirectAccess-VPN, Routing
Get-Service RemoteAccess
Verificate che le sotto-funzioni riportino Installed anziché Available, poi aprite la console e completate la configurazione iniziale prima che qualcun altro tocchi la macchina. Se la console sostiene ancora che il servizio non è in esecuzione, tornate al controllo del servizio invece di rimuovere il ruolo.
Annotate cosa avete cambiato
Le prime scelte della procedura guidata impostano le regole del firewall, l’assegnazione degli indirizzi e se il server si aspetta un relè DHCP. Una manciata di client punto a sito non ha bisogno della forma di un endpoint sito a sito. Decidete il ruolo, il pool di indirizzi, il metodo di autenticazione e l’origine del certificato prima di fare clic. Indovinare qui produce un server che si installa in modo pulito e non accetta mai una connessione.
Tenete la deviazione sull’account del servizio nella stessa nota. Una passata di irrobustimento che rimpiazza l’account predefinito può ripristinare il difetto al successivo riavvio, mesi dopo che chi lo ha diagnosticato è passato oltre.