Why do admins need both powershell.exe and pwsh.exe?

Newcomers to PowerShell Core might wonder why there's a pwsh.exe file when there's a powershell.exe executable for Windows PowerShell.

There's a bit of backstory that explains why administrators should be aware of the two PowerShell executables on their Windows machines.

Microsoft changed its PowerShell task automation framework to an open source project in August 2016 and ported it to run on Linux and Mac platforms. However, lost in the translation with the first official release of PowerShell Core 6.0 in January 2018 was full compatibility with all the cmdlets administrators had with Windows PowerShell. There were other breaking changes in PowerShell Core 6.0 that affected how IT workers managed their infrastructure, such as the removal of the workflow feature.

Early on, the PowerShell team knew administrators with a heavy investment in PowerShell automation might need to work with both the Windows-only version and the open source PowerShell until the latter reaches feature parity. The team maintained this backward-compatibility by giving PowerShell Core a different executable name.

Administrators who want to try PowerShell Core can still use the powershell.exe executable for Windows PowerShell while Core uses an executable named pwsh.exe. This arrangement allows users to run both versions side by side. Environments that depend on scripts that use features not yet implemented -- or might never appear -- in PowerShell Core can stay with Windows PowerShell, of which the latest version is 5.1, released in 2016.

That's not the only change. The project team also uses a different folder for PowerShell Core on Windows. For example, the path for the 64-bit, Windows-only powershell.exe is C:\Windows\System32\WindowsPowerShell\v1.0\, while for PowerShell Core 6.1 the path is C:\Program Files\PowerShell\6\ for the pwsh.exe executable.

Jeffrey Snover, Microsoft technical fellow and inventor of PowerShell, said while development for Windows PowerShell is over, Microsoft will continue to stand behind the deprecated version of its automation tool during a July PowerShell meetup in Boston.

Jeffrey Snover, Microsoft technical fellow and inventor of PowerShell, said while development for Windows PowerShell is over, Microsoft will continue to stand behind the deprecated version of its automation tool during a July PowerShell meetup in Boston.

"It's going to be supported forever. Don't worry about that. But there will be no [further] feature development [for Windows PowerShell]," Snover said.

Snover, who is also the architect of Azure Stack and the chief architect for the Azure Storage and Cloud Edge group at Microsoft, told attendees that he would have no qualms if administrators stayed with Windows PowerShell due to its deep functionality and continued support from Microsoft.

However, Snover pointed out PowerShell Core runs the Azure Cloud Shell on Microsoft's cloud platform, meaning administrators who want to use PowerShell to manage Azure workloads will need to familiarize themselves with how it differs from the Windows version, such as case sensitivity with files and the removal of certain aliases that conflict with Linux commands.

The PowerShell team shrank the parity gap with the September release of PowerShell Core 6.1. The team says that version works with the more than 1,900 cmdlets that ship in the latest versions of Windows -- provided users install the Windows Compatibility Pack for .NET Core on their machines. But there are still some important modules, such as the Active Directory module, that are not compatible with the 6.1 release.