For a Microsoft AlwaysOn VPN Deployment, the following services must run in your domain:

• A Public Key Infrastructure (PKI) - Active Directory Certificate Services
• A Microsoft Network Policy (NPS)/Radius Server
• A Routing and Remote Access Server

If you need to set up your PKI, check out this blog post I made a while ago: https://www.ajni.it/2020/08/active-directory-certificate-services-ad-cs-on-windows-server-2019/

Here are the ADCS Templates needed for the deployment:

VPN Server Authentication

Make sure you leave Authenticated Users. Add Autoenroll to Ras and IAS Servers.

In Application Policies, Add IP Security IKE Intermediate

Allow the private key to be exported.

VPN Authentication Offline (Make a duplicate of the template that you just created)

Subject Name - Supply in the request

VPN User Authentication

Add the group that will contain the VPN Users

Do not make the key exportable.

You might not need the Microsoft Software Key Storage Provider. If you test the client side on a VM though, the user will not be able to obtain the certificate, because the client computer needs a TPM chip. By selecting the Software Key Storage Provider a certificate is still obtainable.

Next, VPN Computer Authentication

Add the group containing the VPN Computers. Computers will use a device tunnel and have access to the Domain Controllers and PKI infrastructure.

Edit the existing template Domain Controller Authentication. Make sure that KDC Authentication and Smart Card Logon is added.

Auto enrollment should be active. Just double check.

Add the templates that were just created.

If there is no GPO for Certificate Auto Enrollment, create one at the top of the Domain on the User and Computer Level (Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto Enrollment):

Now, let's configure the NPS server. Just install the feature through Server Manager (I skipped that part here).

Register the server in Active Directory.

Add a new Radius Client (which will be the RRAS Server outside of the Domain, in a DMZ network). Save the Shared secret externally. It will be added to the VPN server as well.

Configure VPN or Dial-Up

The Radius Client we just added should be listed.

Don't change anything here

Once again don't change anything

Leave it as is.

You might need the Windows Firewall Rules:

New-NetFirewallRule -DisplayName "RADIUS 1645 (UDP) - Inbound" -Direction Inbound -LocalPort 1645 -Protocol UDP -Action Allow

New-NetFirewallRule -DisplayName "RADIUS 1646 (UDP) - Inbound" -Direction Inbound -LocalPort 1646 -Protocol UDP -Action Allow

New-NetFirewallRule -DisplayName "RADIUS 1812 (UDP) - Inbound" -Direction Inbound -LocalPort 1812 -Protocol UDP -Action Allow

New-NetFirewallRule -DisplayName "RADIUS 1813 (UDP) - Inbound" -Direction Inbound -LocalPort 1813 -Protocol UDP -Action Allow

Configuring the RRAS server (in a DMZ network)

First, request a certificate on a Domain Computer. This certificate will be used on the RRAS Server.

Now export the certificate with the private key

... and import it on the RRAS server.

Install the RRAS Feature

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools

Open the Routing and Remote Access Console

Open the properties of the server > Security. Set the Shared secret that was automatically generated on the Radius server. Insert the IP of the Radius server. Communication is done through Port 1812 UDP.

Select the imported certificate.

Under IPv4 specify the VPN clients network settings.

Disable the unused Ports.

Same thing for Wan Miniport L2TP, PPTP and PPOE

To allow the device tunnel, run these PowerShell commands. The device will not be authenticated by the NPS server, instead the RRAS server will validate if the certificate is valid and issued by the Certificate Authority that we trust.

$VPNRootCertAuthority = "AJNI-Root-CA" 

$RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like "*$VPNRootCertAuthority*"}) 

Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru 

Ports 4500 and 500 UDP must be reachable from the internet. The NAT rule should point to the VPN server.

To deploy the user and device tunnel check out the references at the end. Both scripts must be executed as SYSTEM user. I used Task Scheduler to execute the PowerShell scripts as SYSTEM.

If you need help, let me know. It is fairly straight forward, but you should take your time and thoroughly read the documents before testing.

References:

http://blog.tofte-it.dk/tutorial-deploy-always-on-vpn/

https://directaccess.richardhicks.com/2017/12/11/always-on-vpn-windows-10-device-tunnel-step-by-step-configuration-using-powershell/

https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections

It is not possible to delete or rename a folder that contains a blank space at the end with Windows Explorer. It can only be done by using this cmd command:

rd "\.\C:\temp\my folder "

References:

https://superuser.com/questions/198256/how-to-delete-a-folder-containing-trailing-spaces

You can easily run one or multiple programs at logon without messing with the Registry by using Group Policy Object (GPOs).

Under User (or Computer) configuration > Administrative Templates > System > Logon > Run these programs at user logon you can insert the path of the executable. Very clean and straight forward.

You probably have stumbled upon this common problem: When logging into a Domain Computer with a Domain user, this error appears: The trust relationship between this workstation and the primary domain failed.

What does it mean? Well, it basically means that the Domain Computer cannot authenticate against Active Directory, because the Computer Account password on the workstation is not valid anymore (this can occur when using Sytem Restore or when restoring from a backup).

How do you solve this issue? Pretty easy. Just remove the computer from the Domain and re-join. That works, but there is a cleaner and faster solution with one line of PowerShell code:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

You will need to enter domain user credentials that can create or modify computer accounts in the Active Directory Domain.

You can check if the password of the Domain computer changed by viewing the attribute pwLastSet in the Attribute Editor.

If a computer is in an Active Directory Domain environment with Exchange On-Prem installed, Outlook clients might connect to local Exchange instead of Exchange Online, because they query Active Directory first.

This Registry key will avoid SCP Lookup in Active Directory.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
DWORD ExcludeSCPLookup 1

If you are curious, SCP is located here (you can view it with ADSIEdit inside the Configuration Partition):

CN=Services, CN=Microsoft Exchange,CN=Organization, CN=Administrative Groups,CN=Exchange Administrative Group, CN=Servers,CN=YourServer,CN=Protocols,CN=Autodiscover,

References:

https://jacob.gardiner-moon.co.uk/2016/06/13/outlook-autodiscover-connecting-local-exchange-server-instead-office-365/