RRAS-installationen misslyckas eftersom RemoteAccess-tjänsten fastnar

Installationen av rollen stannar med ett allmänt fel och händelseloggen ger nästan inget att arbeta med. På de servrar där detta händer sitter den saknade biten inte alls i guiden: Remote Access-tjänsten lämnar aldrig tillståndet Starting. En roll som inte kan slutföra sin egen initiering misslyckas igen vid varje nytt försök, så tjänsten kommer först och guiden efteråt. Det tar minuter att reparera inloggningsrätten, och det gör upprepad ominstallation av rollen inte.

Börja vid tjänsten, inte vid rollguiden

Öppna en förhöjd kommandotolk och läs tjänstens konfiguration innan du rör rollen. Två värden spelar roll: starttypen och kontot som tjänsten körs under. En standardinstallation registrerar tjänsten för en automatisk, fördröjd start under Network Service.

Om statusen står på Starting i stället för Running väntar tjänsten på något den inte kan få, och inloggningsrätten är den vanliga kandidaten. Längre väntan hjälper inte, eftersom starten redan har misslyckats på ett sätt som Service Control Manager rapporterar som väntande. Stoppa tjänsten rent och läs konfigurationen igen. Titta sedan på tjänstens startförsök i händelseloggen, för det är där kontonamnet står bredvid felet.

Rollguiden rapporterar bara att initieringen misslyckades, och just därför hör tjänstediagnosen först.

Läs inloggningsrätten innan du installerar om

Network Service behöver rätten att logga in som tjänst för att starta. Inbyggda konton får den vanligtvis via gruppmedlemskap, och en härdad baslinje eller en policyuppdatering kan ta den. Grupprincip vinner vid nästa uppdatering, så en manuell tilldelning kan försvinna igen utan varning.

Exportera den lokala säkerhetspolicyn och läs posten i stället för att lita på GUI:t. Det lämnar en fil att jämföra efter en uppdatering, och det är det enda sättet att veta om ändringen överlevde. Om posten är tom eller utelämnar kontot har du hittat felet. Anteckna vilket policyobjekt som sätter den, för det objektet behöver den bestående rättelsen.

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

En tilldelning som tillämpas lokalt och skrivs över av policy vid nästa uppdatering ser ut som en reparation som har slutat fungera, och den kommer att misslyckas igen på samma sätt.

Kontorundan som skriver om konfigurationen

En genväg reparerar tjänstens inloggningskonfiguration utan att redigera policyn för hand: byt konto, tillämpa och byt sedan tillbaka det med lösenordsfälten tomma.

Rundan skriver om tjänstposten och ger kontot rätten det behöver på nytt. Det är en omväg och inte en rättelse av grundorsaken, så den hör hemma i ändringsloggen med ett datum bredvid. Där en baslinje hanterar servern är den riktiga reparationen att lägga kontot till tilldelningen av inloggning som tjänst i den baslinjen. Gör det först när du kan, och använd rundan bara för att låsa upp en installation som annars sitter fast.

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

Läs statusen efter varje kommando, för en tjänst som startar under ett konto och inte under det andra säger vilken rätt som saknas.

Installera rollen och bevisa att den är installerad

När tjänsten kör, lägg till rollen igen och ta med VPN-underfunktionen du faktiskt vill använda. Den generiska rollen ensam ger dig ingen fungerande VPN-slutpunkt.

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

Bekräfta att underfunktionerna rapporterar Installed i stället för Available, öppna sedan konsolen och slutför den första konfigurationen innan någon annan rör maskinen. Om konsolen fortfarande hävdar att tjänsten inte kör, gå tillbaka till tjänstekontrollen i stället för att ta bort rollen.

Skriv ner vad du ändrade

Guidens första val sätter brandväggsregler, adresstilldelning och huruvida servern förväntar sig en DHCP-relä. En handfull punkt-till-plats-klienter behöver inte formen av en plats-till-plats-slutpunkt. Bestäm rollen, adresspoolen, autentiseringsmetoden och certifikatets källa innan du klickar dig igenom. Gissningar här ger en server som installeras rent och aldrig accepterar en anslutning.

Håll avvikelsen i tjänstekontot i samma anteckning. En härdningsomgång som sätter tillbaka standardkontot kan återställa felet vid nästa omstart, månader efter att den som diagnostiserade det har gått vidare.