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:
- Elevation Check
The Test-IsElevated function ensures the script is executed with administrator privileges. Registry changes at the system level require elevated permissions. - Environment Variable Check
The script supports $env:reboot to facilitate use in environments like NinjaOne, where environment variables can trigger reboots programmatically. - 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).
- Feedback and Logging
Informational messages are written to the console, aiding administrators in auditing script behavior. - 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.
FAQs
Q: Does this script work on Windows 7?
No, long file path support begins with Windows 10 Version 1607 and Windows Server 2016.
Q: Is a reboot necessary?
A reboot is not strictly required for the registry setting to take effect, but it’s strongly recommended to ensure system processes recognize the change.
Q: Can I run this remotely?
Yes. Tools like NinjaOne or PowerShell Remoting make remote execution straightforward.
Q: What happens if the key already exists?
The script updates the existing value and logs the change, ensuring idempotency.
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.