Powershell script to change registry value

Iron Contributor

Wrote a PowerShell script and I am running it under User Context in Intune (Scripts). I thought I will run it under the admin context.


I want to delete the LsaCfgFlagsDefault to LsaCfgFlags=0 as Microsoft has set it as LSACfgFlagsDefault which is causing users to not start their VPNs. So, I am trying to change it. It is not changing the value from 2 to 0 and also I do not see it deleting the LsaCfgFlagsDefault reg key.




Define the registry path and value names
$registryPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$oldValueName = "LsaCfgFlagsDefault"
$newValueName = "LsaCfgFlags"
$newValue = 0

# Check if the old registry key exists and delete it
if (Test-Path -Path $registryPath) {
    if (Test-Path -Path "$registryPath\$oldValueName") {
        Remove-ItemProperty -Path $registryPath -Name $oldValueName
        Write-Host "Deleted the old registry key: $oldValueName"
    else {
        Write-Host "Old registry key $oldValueName does not exist."

    # Check if the new registry key exists, and if not, create it and set the value to 0
    if (-not (Test-Path -Path "$registryPath\$newValueName")) {
        New-ItemProperty -Path $registryPath -Name $newValueName -Value $newValue -PropertyType DWORD
        Write-Host "Created and set the new registry key: $newValueName with a value of $newValue."
    } else {
        Write-Host "The $newValueName value already exists."
else {
    Write-Host "Registry path not found: $registryPath"




1 Reply



Hi, John.


This question is more about Intune than PowerShell.


If your script runs successfully when run manually from within an elevated PowerShell session then your script is fine and you need to look specifically at how Intune operates.


I don't work with Intune, so I cannot provide any advice on that. However, I can speak to two other Microsoft management platforms purely in a brainstorming context.


The first is group policy, where to change this kind of registry setting, it would have to be done as a machine policy, not a user policy. This is because the latter runs within the logged on user's security context, which in a best practice configuration means they do not have local administration rights.


The second is System Center Configuration Manager, which allows you to specify many different action accounts. However, like group policy, the action account requires local administration rights to be able to change this registry location.


Drawing a comparison with Intune, if running something in a user context operates the same way as group policy and action accounts from above, then that's likely to be the reason for failure. The script will need to run as the local system or some other account that has local administration rights.


Another possibility is that the script is working but is then being overridden by a higher-priority policy. In hybrid environments, it's not unheard of for a given policy to be specified in multiple management platforms, or even multiple times within a given platform, so you want to also check that nothing's superseding the Intune policy you're working with.


However, I do have to wonder if you need to take this approach at all, as Intune already has a policy for managing this feature:



As I said, I don't work with Intune (I work with group policy) but you might want to consider using the native Intune policy unless you've already tried that and it doesn't work for some reason.