How to Disable or Enable the Windows Run Dialog with PowerShell

In the intricate world of IT, managing user access to certain system features is of utmost importance. One such feature is the Windows Run Dialog. But why might IT professionals want to restrict its access? This guide delves deep into the PowerShell script designed to control the Run Dialog’s accessibility and the implications of such actions.

Overview of the Windows Run Dialog

• What is the Windows Run Dialog?

  • The Windows Run Dialog is a feature that provides users with a quick way to launch programs, open folders, and execute system commands. By pressing Windows + R, a small dialog box appears, allowing users to type in commands directly.

• How is the Windows Run Dialog used?

  • It’s primarily used for quick access. Instead of navigating through multiple menus or folders, users can simply type a command or path into the Run Dialog to instantly launch a program or open a directory.

Security implications of disabling the Windows Run Dialog

What are the risks?

By disabling the Run Dialog, you might inadvertently hinder productivity. Some advanced users rely on the Run Dialog for quick tasks and system management. Moreover, if not done correctly, tampering with system settings can lead to other unintended issues.

What are the benefits?

The primary benefit is enhanced security. Disabling the Run Dialog can prevent unauthorized or malicious actions, especially from users who might not be well-versed in system operations. It reduces the risk of accidental changes or the execution of harmful commands.

How can you mitigate the risks?

Before implementing any changes, it’s essential to:

• Communicate with users, especially those who might be affected by the change.
• Provide alternative methods or tools for tasks that were previously done using the Run Dialog.
• Ensure that there’s a way to quickly revert the changes if necessary.

Background

The PowerShell script provided is a robust tool for IT professionals and Managed Service Providers (MSPs) to control the Run Dialog’s accessibility. In environments where security is a top priority, such tools become indispensable. The script’s ability to exclude specific users from these restrictions adds a layer of flexibility, ensuring that necessary access isn’t completely revoked.

The Script

#Requires -Version 2.0

<#
.SYNOPSIS
    Disables or enables the Run Dialog for all users and new users.
.DESCRIPTION
    Disables or enables the Run Dialog for all users and new users, and there is an option to exclude users.
    Reboot is required to apply changes.
.EXAMPLE
    -Disable
    Disables the Run Dialog for all users and new users.
.EXAMPLE
    -Disable -ExcludeUsers "Test1", "Test2"
    Disables the Run Dialog for all users and new users, but excludes Test1 and Test2 users.
.EXAMPLE
    -Enable
    Enables the Run Dialog for all users and new users.
.EXAMPLE
    -Enable -ExcludeUsers "Test1", "Test2"
    Enables the Run Dialog for all users and new users, but excludes Test1 and Test2 users.
.OUTPUTS
    None
.NOTES
    General notes
    Release Notes:
    Initial Release
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
#>

[CmdletBinding()]
param (
    [Parameter(Mandatory = $true, ParameterSetName = "Disable")]
    [Switch]
    $Disable,
    [Parameter(Mandatory = $true, ParameterSetName = "Enable")]
    [Switch]
    $Enable,
    [Parameter(Mandatory = $false, ParameterSetName = "Disable")]
    [Parameter(Mandatory = $false, ParameterSetName = "Enable")]
    [String[]]
    $ExcludeUsers
)

begin {
    function Set-ItemProp {
        param (
            $Path,
            $Name,
            $Value,
            [ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
            $PropertyType = "DWord"
        )
        # Do not output errors and continue
        $ErrorActionPreference = [System.Management.Automation.ActionPreference]::SilentlyContinue
        if (-not $(Test-Path -Path $Path)) {
            # Check if path does not exist and create the path
            New-Item -Path $Path -Force | Out-Null
        }
        if ((Get-ItemProperty -Path $Path -Name $Name)) {
            # Update property and print out what it was changed from and changed to
            $CurrentValue = Get-ItemProperty -Path $Path -Name $Name
            try {
                Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                Write-Error $_
            }
            Write-Host "$Path$Name changed from $CurrentValue to $(Get-ItemProperty -Path $Path -Name $Name)"
        }
        else {
            # Create property with value
            try {
                New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                Write-Error $_
            }
            Write-Host "Set $Path$Name to $(Get-ItemProperty -Path $Path -Name $Name)"
        }
        $ErrorActionPreference = [System.Management.Automation.ActionPreference]::Continue
    }
}
process {
    $Path = "SoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer"
    $Name = "NoRun"
    $Value = if ($Disable) { 1 }elseif ($Enable) { 0 }else {
        Write-Host "Either -Enable or -Disable is required to function."
        exit 0
    }

    # Get each user profile SID and Path to the profile
    $UserProfiles = Get-ItemProperty "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionProfileList*" |
        Where-Object { $_.PSChildName -match "S-1-5-21-(d+-?){4}$" } |
        Select-Object @{Name = "SID"; Expression = { $_.PSChildName } }, @{Name = "UserHive"; Expression = { "$($_.ProfileImagePath)NTuser.dat" } }, @{Name = "UserName"; Expression = { "$($_.ProfileImagePath | Split-Path -Leaf)" } } |
        Where-Object { $ExcludeUsers -notcontains $_.UserName }
    
    # Add in the .DEFAULT User Profile
    $DefaultProfile = "" | Select-Object SID, UserHive, UserName
    $DefaultProfile.SID = ".DEFAULT"
    $DefaultProfile.UserHive = "C:UsersPublicNTuser.dat"
    try {
        # Fix for edge case where PSObject is missing the add operator
        $UserProfiles = {
            $UserProfiles | ForEach-Object { $_ }
            $DefaultProfile
        }.Invoke()
    }
    catch {
        Write-Host "Failed to update default profile, skipping."
    }
    

    # Loop through each profile on the machine
    Foreach ($UserProfile in $UserProfiles) {
        # Load User ntuser.dat if it's not already loaded
        If (($ProfileWasLoaded = Test-Path -Path "Registry::HKEY_USERS$($UserProfile.SID)") -eq $false) {
            Start-Process -FilePath "cmd.exe" -ArgumentList "/C reg.exe LOAD HKU$($UserProfile.SID) $($UserProfile.UserHive)" -Wait -WindowStyle Hidden
        }
        # Manipulate the registry
        $key = "Registry::HKEY_USERS$($UserProfile.SID)$($Path)"
        Set-ItemProp -Path $key -Name $Name -Value $Value
 
        # Unload NTuser.dat
        If ($ProfileWasLoaded -eq $false) {
            [gc]::Collect()
            Start-Sleep 1
            Start-Process -FilePath "cmd.exe" -ArgumentList "/C reg.exe UNLOAD HKU$($UserProfile.SID)" -Wait -WindowStyle Hidden | Out-Null
        }
    }
}
end {}

 

Detailed Breakdown

The script starts by setting parameters, allowing users to either disable or enable the Run Dialog and even exclude specific users. A function, Set-ItemProp, is then defined to manage the creation or modification of registry keys. The main process involves defining the registry path related to the Run Dialog, retrieving all user profiles, and then looping through each profile to modify the registry accordingly.

Potential Use Cases

Consider an IT professional, Sarah, at a university. To ensure the lab computers are used strictly for academic purposes, Sarah decides to disable the Run Dialog, excluding the profiles of lab assistants. This script allows Alex to achieve this balance of security and accessibility.

Comparisons

While Group Policy offers a way to disable the Run Dialog, it might not provide the granularity this script offers. This script’s direct approach offers more agility, especially in larger organizations.

FAQs

• Can I use this script to exclude multiple users?
  Yes, multiple user exclusions are possible using the -ExcludeUsers parameter.
• Is a reboot required after running the script?
  Yes, a reboot ensures the changes are applied.

Recommendations

• Backup the current registry state before making modifications.
• Test the script in a controlled environment first.
• Keep the list of excluded users updated.

Final Thoughts

In the dynamic world of IT, tools like NinjaOne offer a centralized platform for IT management. Integrating scripts like the one discussed ensures that IT professionals remain equipped to handle any challenge, especially when it comes to managing features like the Windows Run Dialog.