Microsoft Always On VPN is a beautiful thing. VPN profiles are assigned to the user (and, optionally, their device). When users power up their device and log on, they are automatically connected to the corporate network and can access all the applications and data they need on-premises. Until recently, though, end users could disconnect the VPN. Why they would do this is beyond comprehension, but sadly, it happens all too often. When it does, it presents a problem for Always On VPN administrators because they must now rely on the user to re-enable this feature. And until they do, they often suffer productivity loss, and their devices may fall out of compliance.
Connect Automatically
When an Always On VPN profile is provisioned to a user (or a device), the VPN profile has the option to ‘Connect automatically’ enabled by default. Unfortunately, this setting is cleared if a user terminates the VPN.
This setting will remain cleared until the user rechecks the box to enable it. Until then, the VPN will no longer connect automatically.
Workarounds
Instead of relying on the grace of the end user to restore Always On functionality, administrators have a few options to correct this problem programmatically.
Intune Remediation
Administrators can use Intune Remediations to deploy a set of detection and remediation scripts I’ve published to update this setting. Now, administrators can enforce ‘Always On’ VPN connections with the assurance that if the user turns off this feature, it will be quickly re-enabled.
Detect-AutoTriggerDisabledProfile.ps1
Remediate-AutoTriggerDisabledProfile.ps1
SCCM
You can find a standalone version of this script here if you use System Center Configuration Manager (SCCM) or another systems management solution to manage your endpoints.
Clear-AutoTriggerDisabledProfile.ps1
AovpnTools
In addition, you will find the Clear-AutoTriggerDisabledProfile function is included in my AOVPNTools PowerShell module, which can be installed from the PowerShell gallery.
Install-Module -Name AOVPNTools -Force
Disable Disconnect Button
To avoid this pain in the future, Always On VPN administrators can prevent users from disconnecting the VPN using the UI by leveraging the DisableDisconnectButton option in ProfileXML. This setting is supported for both user and device tunnels on Windows 11 and later devices.
victor e bassey
/ January 15, 2024Thanks Richard. This has plagued my current Window 11 deployment for a client. It was not so much of an issue in window 10 though. Would be trying out the remediate scripts.
Richard M. Hicks
/ January 15, 2024Awesome. Let me know how it goes!
Chris G
/ January 15, 2024Love this concept Richard, however i’m having a difficult time getting the remediation to run. Our vpn is set per user, but the script needs to run in the system context in order to write to the registry. Every time it runs, it can’t see the VPN and generates a Warning: VPN connection “my vpn name” not found. Any help would be great!
Richard M. Hicks
/ January 15, 2024Thanks for the feedback. Indeed, that poses a challenge. I originally created this script for a customer using SCCM, for which it worked without issue. Also, I implemented it as an Intune remediation recently but in that case the user VPN profiles were deployed in the system context.
For now, the user would need to have the ability to write to the registry. I’ll investigate further and see if there are any options for a workaround to address this.
Sorry for the trouble!
Armin
/ February 27, 2024Hi Richard, thanks for your great stuff. In SCCM i got also the Message “VPN Connection xxxxx not found” in a User VPN Scenario. Does the SCCM Script works with User VPN?
Richard M. Hicks
/ February 27, 2024It does work in the user scenario, but for now it requires the user to have administrative rights on the local machine. Not ideal, I know, but the script is writing to the registry. I’m working to find an alternative, but haven’t had much luck thus far. I’ll update this post when/if I come up with something. 🙂
Felix Jacobsen
/ July 28, 2026Hi, since a few days we have the problem that the checkbox ‘Connect automatically is completely misssing. We made no config change or anything. We have about 400 Users and we have the problem with around 25% of them. Any Ideas? Thanks Felix
Richard M. Hicks
/ July 28, 2026I’ve heard reports from others experiencing this issue. It may be related to recent Windows Updates, though I’m not sure. You can either instruct users to check the box again, or you can do this programmatically using PowerShell. Here’s a link to the script.
https://github.com/richardhicks/aovpn/blob/master/Clear-AutoTriggerDisabledProfile.ps1
I have also published detection and remediation scripts for use with Intune Remediations.
https://github.com/richardhicks/endpointmanager/blob/main/Detect-AutoTriggerDisabledProfile.ps1
https://github.com/richardhicks/endpointmanager/blob/main/Remediate-AutoTriggerDisabledProfile.ps1
Hope that helps!
Felix Jacobsen
/ July 29, 2026Hi Richard,,thanks for your answer. I think it is a different problem . The Reg Key with Disabled profiles doesn´t exist. The scripts says the same:
PS C:\Temp> .\Clear-AutoTriggerDisabledProfile.ps1 -ProfileName “Always On VPN”
WARNUNG: VPN connection “Always On VPN” not found.
I removed the last windows updates, but the check box is still missing.
Richard M. Hicks
/ July 29, 2026Ok, good to know. Have you tried removing the profile and redeploying it again? I’m curious to know if that restore the checkbox.
Felix Jacobsen
/ July 31, 2026No, redeploying the profile, same problem. No checkbox, no auto connect.
Richard M. Hicks
/ July 31, 2026Interesting. Have you tried deploying using a different name? I know some settings can get tattooed, so I’m wondering if that changes things.
Felix Jacobsen
/ August 10, 2026Hi Richard,
same problem, i made a new profile with new name and a complete new Intune configuration profile . No checkbox no automatic connection. ???
Richard M. Hicks
/ August 10, 2026Ok, good to know. I’m hearing reports that the July updates may have broken Always On VPN. Can you test with a machine that does not have the July update and see if it works as expected?
Felix Jacobsen
/ August 11, 2026Hi again,
i tried to import a new profile manually via powershell, same problem.
Then i modified the XML and insert:
1
Then it works again, checkbox is back an automatic connection works, too.
Maybe there is a problem with the july updates and the intune configuration profile.
If i run the cmdlet: Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_VPNv2_01 the new Intune profile shows:
AlwaysOn : True
AlwaysOnActive :
The manual profile shows:
AlwaysOn : True
AlwaysOnActive : True
No i try to rollout the Switch with intune Custom OMA-URI Settings, to update the existing profiles or powershell, Any ideas?
Richard M. Hicks
/ August 11, 2026Hi Felix. WordPress messed up the formatting of your XML. Can you repost or send me the PowerShell and XML you used directly? Thanks!
Rene Hansen
/ August 13, 2026We are in the same boat, but the issue only seem to hit our 25H2 Clients – admittedly we are a bit behind on the feature updates, so the complaints aren’t that widespread. 23H2 just stay connected.
Clients with 25H2 will disconnect, and remove the “connect automatically” checkmark as if the connection was disconnected manually.
Richard M. Hicks
/ August 13, 2026I’m hearing numerous reports of this, but I’m unable to replicate. Several of my customers have open support tickets with Microsoft. I will let you know if I hear anything more on this.
Michael Leeming
/ August 21, 2026Not sure if this is the exact same issue, but we also have some users seeing issues with autotrigger registry keys disappearing.
We found out that intune for the affected users is deploying both a device tunnel and user tunnel to the device.
When device tunnel is not deployed anymore, the registry keys will at some point come back when sync has fully completed with the user tunnel configuration profile once again.
While both profiles are deployed, check-in status for the user tunnel configuration profiles often has an Error state on check-in status in intune.
When device tunnel is no longer deployed, the check-in status for the user tunnels seems to go back to success on the check-in status.
We were tring to fix using remediation scripts, also forcing the remediation to run during a debug session. Remediation detection did not trigger in this scenario, because the keys were gone, autotriggers were not as such disabled for any profiles, just deleted, which is why the remediation detection did not trigger.
But after forcing detection to run the remediation, ensuring the registry keys were restored for the user tunnel, the registry keys would disappear once again “shortly” after.
This was the moment we noticed that device tunnel configuration profile had completed a successful check-in status around the same time, as the keys would disappear.
For more context, both tunnel types were being deployed via custom configuration profiles in intune, using “OMA-URI Settings” and both were deployed to the OMA-URI path “./Device/Vendor/MSFT/VPNv2//ProfileXML”
Meaning the User tunnel is deployed in AllUserConnection context
Michael Leeming
/ August 24, 2026Hi again
Not sure if my previous post was received, but if is was, we found a workaround for our scenario.
We removed the custom “Device Tunnel” OMA Uri assignments and moved the same devices/assignments to a detect/remediation script.
It only adds the device tunnel, if it doesn’t exist already.
The result is that the custom “User Tunnel” (for alluserconnections) OMA Uri now completes correctly and auto trigger registry keys are not being removed, now that the Device tunnel OMA uri configuration is “disabled/without assignments”
FYI – The device tunnel we were deploying, was only for hybrid joined devices and it was only used to ensure machine access to domain controllers, so it was without too much pain, for us to do this maneuver.
So our conclusion is that we have made a succesful workaround, to stop the autotrigger conflict happening, when having OMA uri configurations for both a device tunnel and an alluserconnection user tunnel, while our device tunnel is still auto connecting.
So in reality we have gone back to our old school powershell script to deploy the device tunnel, embedded into the Detect/Remediation feature in Intune.
Regards
Michael
Richard M. Hicks
/ August 24, 2026That’s an interesting workaround. Glad to hear it solved your problem, though!