RRAS Install Fails Because the RemoteAccess Service Stalls

The role installation stops with a generic failure and the event log offers almost nothing to work with. On the servers where this happens, the missing piece is not in the wizard at all: the Remote Access service never leaves the Starting state. A role that cannot finish its own initialization fails again on every retry, so the service comes first and the wizard second. Repairing the logon right takes minutes, and reinstalling the role repeatedly does not.

Start at the Service, Not the Role Wizard

Open an elevated prompt and read the service configuration before touching the role. Two values matter: the start type and the account the service runs under. A default installation registers the service for an automatic, delayed start under Network Service.

If the status sits at Starting rather than Running, the service is waiting on something it cannot obtain, and a logon right is the usual candidate. Waiting longer does not help, because the start has already failed in a way the Service Control Manager reports as pending. Stop the service cleanly and read its configuration again. Then look at the service start attempt in the event log, which is where the account name appears alongside the failure.

The role wizard reports only that initialization failed, which is exactly why the service diagnosis belongs first.

Read the Logon Right Before You Reinstall

Network Service needs the logon-as-a-service right in order to start. Built-in accounts normally receive it through group membership, and a hardened baseline or a policy refresh can take it away. Group Policy wins at the next refresh, so a manual grant can disappear again without warning.

Export the local security policy and read the entry instead of trusting the GUI. That leaves you a file to diff after a refresh, which is the only way to know whether the change survived. If the entry is empty or omits the account, you have found the fault. Record which policy object sets it, because that object is what needs the permanent fix.

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

A grant applied locally and overwritten by policy at the next refresh looks like a fix that stopped working, and it will fail the same way again.

The Account Round Trip That Rewrites the Configuration

A shortcut repairs the service's logon configuration without hand-editing policy: change the account, apply, then change it back with the password fields left empty.

The round trip rewrites the service record and re-grants the right the account needs. It is a workaround rather than a root-cause fix, so it belongs in the change record with a date next to it. Where a baseline manages the server, the proper repair is to add the account to the logon-as-a-service assignment in that baseline. Do that first when you can, and use the round trip only to unblock an installation that is otherwise stuck.

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

Read the status after each command, because a service that starts under one account and not the other tells you which right is missing.

Install the Role and Prove It Installed

With the service running, add the role again and include the VPN sub-feature you actually intend to use. The generic role on its own does not give you a working VPN endpoint.

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

Confirm the sub-features report Installed rather than Available, then open the console and complete initial configuration before anyone else touches the box. If the console still claims the service is not running, return to the service check instead of removing the role.

Write Down What You Changed

The wizard's first choices set firewall rules, address assignment and whether the server expects a DHCP relay. A handful of point-to-site clients does not need the shape of a site-to-site endpoint. Decide the role, the address pool, the authentication method and the certificate source before clicking through. Guessing here produces a server that installs cleanly and never accepts a connection.

Keep the service-account deviation in the same note. A hardening pass that puts the default account back can restore the fault at the next restart, months after whoever diagnosed it has moved on.