How to Enable Long File Paths with PowerShell on Windows

File path limitations can be a source of frustration for IT professionals and Managed Service Providers (MSPs), especially in environments that rely on deep directory structures or software that generates verbose filenames. One common issue is the 260-character path length limitation in legacy Windows systems—a limitation that can hinder file operations and cause application errors.

Fortunately, Windows 10 and later allow this restriction to be removed, provided a system setting is modified. This blog post explores how to enable long file paths with PowerShell, offering automation and consistency for IT teams.

Background

By default, Windows imposes a legacy limitation known as MAX_PATH, restricting file and folder paths to 260 characters. While modern Windows versions, starting from Windows 10 (1607) and Windows Server 2016, include support for longer paths, this feature is not enabled out of the box. Enabling this capability requires editing the Windows registry—an operation best handled through automation to avoid manual errors and ensure deployment at scale.

This is where PowerShell proves invaluable. Using a PowerShell script to enable long file paths not only simplifies the process but also ensures it can be executed across multiple endpoints—ideal for MSPs managing diverse environments.

The Script

<#
.SYNOPSIS
    Enables long file paths on Windows.
.DESCRIPTION
    Enables long file paths on Windows.
    This script will enable long file paths on Windows and optionally restart the computer.

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).

PARAMETER:
    (No Parameters)
.EXAMPLE
    (No Parameters)

    [Info] Attempting to enable long file paths on Windows.
    [Info] Successfully enabled long file paths on Windows.

PARAMETER: -Reboot
    Reboots the computer after enabling long file paths.
.EXAMPLE
    -Reboot

    [Info] Attempting to enable long file paths on Windows.
    [Info] Successfully enabled long file paths on Windows.
    [Info] Restarting computer.

.LINK
    https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Release Notes: Renamed script and added Script Variable support
#>

[CmdletBinding()]
param (
    [Parameter()]
    [Switch]$Reboot
)

begin {
    if ($env:reboot -and $env:reboot -like "true") { $Reboot = $True }

    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        $p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
    }

    function Set-RegKey {
        param (
            $Path,
            $Name,
            $Value,
            [ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
            $PropertyType = "DWord"
        )
    
        # Check if the specified registry path exists
        if (!(Test-Path -Path $Path)) {
            try {
                # If the path does not exist, create it
                New-Item -Path $Path -Force -ErrorAction Stop | Out-Null
            }
            catch {
                # If there is an error creating the path, output an error message and exit
                Write-Host "[Error] Unable to create the registry path $Path for $Name. Please see the error below!"
                Write-Host "[Error] $($_.Exception.Message)"
                exit 1
            }
        }
    
        # Check if the registry key already exists at the specified path
        if (Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue) {
            # Retrieve the current value of the registry key
            $CurrentValue = (Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue).$Name
            try {
                # Update the registry key with the new value
                Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                # If there is an error setting the key, output an error message and exit
                Write-Host "[Error] Unable to set registry key for $Name at $Path. Please see the error below!"
                Write-Host "[Error] $($_.Exception.Message)"
                exit 1
            }
            # Output the change made to the registry key
            Write-Host "$Path\$Name changed from $CurrentValue to $((Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue).$Name)"
        }
        else {
            try {
                # If the registry key does not exist, create it with the specified value and property type
                New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                # If there is an error creating the key, output an error message and exit
                Write-Host "[Error] Unable to set registry key for $Name at $Path. Please see the error below!"
                Write-Host "[Error] $($_.Exception.Message)"
                exit 1
            }
            # Output the creation of the new registry key
            Write-Host "Set $Path\$Name to $((Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue).$Name)"
        }
    }
}
process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }

    try {
        Write-Host "[Info] Attempting to enable long file paths on Windows."
        Set-RegKey -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -ErrorAction Stop
        Write-Host "[Info] Successfully enabled long file paths on Windows."
    }
    catch {
        Write-Host "[Error] Failed to enable long file paths."
        exit 1
    }

    if ($Reboot) {
        try {
            Write-Host "[Info] Restarting computer."
            Start-Sleep -Seconds 10
            Restart-Computer -Force -Confirm:$false -ErrorAction Stop
        }
        catch {
            Write-Host "[Error] Failed to restart computer."
            exit 1
        }
    }
}
end {
    
    
    
}

Detailed Breakdown

The script begins by defining its metadata through a comment-based help block, making it self-documenting and ideal for team environments. It supports a -Reboot switch, allowing administrators to automatically restart the machine after enabling long path support.

Here’s how it works step-by-step:

1. Elevation Check
   The Test-IsElevated function ensures the script is executed with administrator privileges. Registry changes at the system level require elevated permissions.
2. Environment Variable Check
   The script supports $env:reboot to facilitate use in environments like NinjaOne, where environment variables can trigger reboots programmatically.
3. Registry Key Modification
   The Set-RegKey function handles the core functionality. It:
   • Checks for the existence of the registry path.
   • Creates the path if missing.
   • Adds or updates the LongPathsEnabled registry key under HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem.
   • Sets its value to 1 (enabled).
4. Feedback and Logging
   Informational messages are written to the console, aiding administrators in auditing script behavior.
5. Optional Reboot
   If the -Reboot switch is used (or the reboot environment variable is set to true), the script initiates a restart with a 10-second delay.

Potential Use Cases

Scenario:

An MSP supports a graphic design firm using Adobe products. Designers often generate deeply nested file structures, quickly hitting the 260-character limit. These errors result in failed saves and lost productivity.

Solution:

The MSP pushes this PowerShell script to all endpoints via NinjaOne with the -Reboot switch. The script silently updates the registry and reboots systems during off-hours. The change eliminates file path issues and improves workflow reliability.

Comparisons

Group Policy vs. PowerShell

• Group Policy:
  Can enable long file paths using a GPO (Enable Win32 long paths) but lacks granularity and may not be viable in non-domain environments.
• Manual Registry Editing:
  Error-prone and time-consuming, especially across multiple systems.
• PowerShell Script:
  Ideal for both domain-joined and standalone systems. Easily integrated with automation platforms like NinjaOne, Intune, or SCCM.

Implications

Enabling long file paths enhances compatibility with modern applications and avoids runtime errors due to path truncation. However, this change can have downstream effects in legacy applications that assume the 260-character limit. IT teams should validate critical business software in a test environment before broad deployment.

From a security standpoint, this registry change does not introduce any known vulnerabilities. Still, it emphasizes the importance of controlled and documented changes across the IT environment.

Recommendations

• Test in a Staging Environment: Always validate the script on non-production machines first.
• Use with Automation Tools: Deploy through RMM tools like NinjaOne for consistency and scale.
• Document Changes: Ensure that change management protocols are followed.
• Monitor Post-Deployment: Check logs or output to verify registry keys were correctly set.

Final Thoughts

Managing configuration changes across numerous devices can be a logistical challenge, but automation makes it manageable. Scripts like this one become even more powerful when combined with platforms like NinjaOne, which allows MSPs and IT departments to deploy scripts, schedule reboots, and monitor outcomes with ease. By leveraging tools that enhance visibility and control, IT professionals can reduce manual overhead and improve service delivery.

Whether you’re supporting dozens or thousands of endpoints, using PowerShell to enable long file paths is a simple but essential step toward modernizing your Windows environment.