The Next Release of PowerShell – PowerShell 7

Steve Lee


Recently, the PowerShell Team shipped the Generally Available (GA) release of PowerShell Core 6.2. Since that release, we’ve already begun work on the next iteration!

We’re calling the next release PowerShell 7, the reasons for which will be explained in this blog post.

Why 7 and not 6.3?

PowerShell Core usage has grown significantly in the last two years. In particular, the bulk of our growth has come from Linux usage, an encouraging statistic given our investment in making PowerShell viable cross-platform.  This chart represents the number of times pwsh.exe (or just pwsh on Linux/macOS) was started (unless telemetry was disabled).


However, we also can clearly see that our Windows usage has not been growing as significantly, surprising given that PowerShell was popularized on the Windows platform. We believe that this could be occurring because existing Windows PowerShell users have existing automation that is incompatible with PowerShell Core because of unsupported modules, assemblies, and APIs. These folks are unable to take advantage of PowerShell Core’s new features, increased performance, and bug fixes. To address this, we are renewing our efforts towards a full replacement of Windows PowerShell 5.1 with our next release.

This means that Windows PowerShell and PowerShell Core users will be able to use the same version of PowerShell to automate across Windows, Linux, and macOS and on Windows, and PowerShell 7 users will have a very high level of compatibility with Windows PowerShell modules they rely on today.

We’re also going to take the opportunity to simplify our references to PowerShell in documentation and product pages, dropping the “Core” in “PowerShell 7”. The PSEdition will still reflect Core, but this will only be a technical distinction in APIs and documentation where appropriate.

Note that the major version does not imply that we will be making significant breaking changes. While we took the opportunity to make some breaking changes in 6.0, many of those were compromises to ensure our compatibility on non-Windows platforms. Prior to that, Windows PowerShell historically updated its major version based on new versions of Windows rather than Semantic Versioning

.NET Core 3.0

PowerShell Core 6.1 brought compatibility with many built-in Windows PowerShell modules, and our estimation is that PowerShell 7 can attain compatibility with 90+% of the inbox Windows PowerShell modules by leveraging changes in .NET Core 3.0 that bring back many APIs required by modules built on .NET Framework so that they work with .NET Core runtime. For example, we expect Out-GridView to come back (for Windows only, though)!

A significant effort for PowerShell 7 is porting the PowerShell Core 6 code base to .NET Core 3.0 and also working with Windows partner teams to validate their modules against PowerShell 7.

Support Lifecycle Changes

Currently, PowerShell Core is under the Microsoft Modern Lifecycle Policy. This means that PowerShell Core 6 is fix-forward: we produce servicing releases for security fixes and critical bug fixes,
and you must install the latest stable version within 6 months of a new minor version release.

In PowerShell 7, we will align more closely with the .NET Core support lifecycle, enabling PowerShell 7 to have both LTS (Long Term Servicing) and non-LTS releases.

We will still have monthly Preview releases to get feedback early.

When do I get PowerShell 7?

The first Preview release of PowerShell 7 will likely be in May. Be aware, however, that this depends on completing integration and validation of PowerShell with .NET Core 3.0.

Since PowerShell 7 is aligned with the .NET Core timeline, we expect the generally available (GA) release to be some time after the GA of .NET Core 3.0.

What about shipping in Windows?

We are planning on eventually shipping PowerShell 7 in Windows as a side-by-side feature with Windows PowerShell 5.1, but we still need to work out some of the details on how you will manage this inbox version of PowerShell 7.

And since the .NET Core timeline doesn’t align with the Windows timeline, we can’t say right now when it will show up in a future version of Windows 10 or Windows Server.

What other features will be in PowerShell 7?

We haven’t closed on our feature planning yet, but expect another blog post relatively soon with a roadmap of our current feature level plans for PowerShell 7.

Steve Lee
Principal Engineering Manager
PowerShell Team

Steve Lee
Steve Lee

Principal Software Engineer Manager, PowerShell

Follow Steve   


  • Avatar
    Jeffrey McClain

    Are there plans to port the “Active Directory module for Windows PowerShell” to work on PowerShell 7 natively, or do I still need to use the compat module?

    • Avatar
      Kris Borowinski

      ^This. I work for rather large enterprise and not having native Active Directory module on PowerShell Core is a show stopper.

      • Avatar
        vincent racanelli

        You can load the AD powershell module on Powershell core version 6.2. If you work in a large enterprise I would suggest getting away from using the module because there is a built in 5000 size limit on the group cmdlets. I used to work in an enterprise with over 450,000 users and had to learn to use .Net because of it. Works like a charm now. 

    • Tom Holt
      Tom Holt

      Let’s hope so.  I would also like to see “System.DirectoryServices” namespace included.  There are use cases when its useful especially when you need to  access AD services on Windows client OSes without having to install RSAT.

  • Avatar
    illy Metuky

    That’s great news!
    I was waiting for this version to make the switch to Core, Can’t wait for the preview to start testing the migration of my stuff to it.
    It’s perfectly logical that Windows users did not make the switch until now because it was half upgrade half downgrade, but now that Core can hopefully do everything the old version did there is no reason not to switch except for the convenience that it’s not pre installed on every system and accessible remotely out of the box.

  • Avatar
    Michael C. Cook Sr

    I can’t even make a sensible comment. That’s how surprised I am… ‘Heroes in a half-shell…’ all day every day FTW.

  • Michael H.
    Michael H.

    Can we please add an alias for “sc remove”? The rest of the sc commands are aliased as far as I know, the feature was requested and then denied with no explanation other than “there are no plans to add this feature”. It actually doesn’t even output an error saying that it didn’t do anything or that the Alias doesn’t exist. 

  • Avatar
    "Fleet Command"

    On several occasions, I commented in the PowerShell blog and explain why I do not migrate to PowerShell 6. I am in charge of a network of many computers and I need to be able to deploy PowerShell instances remotely, keep them updated, and finally keep the help/documentation updated. And we still have Windows 7 in our environment. (This version of Windows is rock-solid reliable.) And, yes, I need to be able to manage and maintain a WSUS server, Windows file servers, etc.

    • Avatar
      Warren R

      It’s not nearly as bad as Python 2/3.  As long as you don’t take a dependency on a new PS Core 6+ language feature like `e, and you don’t need something that wasn’t brought forward to PS Core like Add-Computer, then scripts will generally work fine on both versions.  There’s no change that’s as nasty as the syntax change with the “print” command.

  • Avatar
    Kenneth Benson

    It’s been awhile since I’ve worked with Powershell(retired) but I try to stay updated. Can someone define for me what “inbox version” means in relation to Powershell updates?

    • Avatar
      "Fleet Command"

      “Inbox version” actually means “built-in version”, the one shipped with Windows. It is a known fact that Microsoft employees do not speak proper English. Instead of “built-in” or “bundled”, “shipped with” or “out-of-the-box”, they say “inbox”.
      This isn’t the only case. You should read their official update-related terms. It seems to have been written by someone who intends to harass English-speakers. They have released something called “2019-01 Security Only Quality Update for Windows”! Also, there is the famous Microsoft term “boot partition”, which refers to a partition that probably does not have any boot loader on it and does not participate in the boot process. I am not trying to write a comprehensive guide to Microsoft’s (non-)English mistakes here; just enough to give you the hint as to what’s going on.

      • Avatar
        Kenneth Benson

        Thank you, that does explain things. I had wondered as there is also a part of Powershell that works with Exchange to script things and it was confusing if they meant that or the builtin thing. Have a good day!

  • Avatar
    Alex Neihaus

    What, pray tell, is an “inbox” version of PowerShell? Does that mean I have to email every use of Out-File?
    I appreciate the openness but recommend less jargon.

  • Avatar
    Joost Kuin

    Although I appreciate Microsoft’s effort to support platforms besides Windows, I did not appreciate v6 core for lacking full compatibility with v5.So I’m super relieved to hear v7 bringing back compatibility with previous releases

  • Tom Holt
    Tom Holt

    WPF and Windows Forms APIs are now supported correct?  .NET Core 3 supports these products (Windows only) so by extension so should PowerShell 7.  The fact that Out-Gridview works implies support for WPF.  Do you plan on porting PowerShell ISE to  PowerShell 7 as well?  I think you will have more interest in the new PowerShell open source version from the Windows community if these capabilities are supported.

  • Avatar
    Luigi Grilli

    I don’t understand where the surprise is that nobody in their right mind is using powershell core on windows. Nothing that works in 5.1 works in core. What would be the point? I’m extremely worried about this v7 and how you plan to make desktop modules work there. It is going to be the usual powershell mess

  • Avatar
    Gregory Suvalian

    Will username/password authentication into Azure be supported from powershell core? In 6.2 it ends up in following error
    Add-AzAccount : Username + Password authentication is not supported in PowerShell Core. Please use device code authentication for interactive log in, or Service Principal authentication for script log in.

  • Manuel Philippus Mell
    Manuel Philippus Mell

    I pretty new to this, but I have a question, do I have to unistall powershell core 6.2.2 after installing powershell core 7 preview? I can see and open them both.

  • Avatar
    Nico Grüner

    @Steve Lee,

    you have written:
    “This means that Windows PowerShell and PowerShell Core users will be able to use the same version of PowerShell to automate across Windows, Linux, and macOS and on Windows, and PowerShell 7 users will have a very high level of compatibility with Windows PowerShell modules they rely on today.”

    But that is not true! Powershell Core is not compatible with Powershell 5.1 or earlier even in basic functionality, and you and the dev team know this.
    You are not willing to be fully compatible and and for Microsoft, Linux users now count more than their own Windows users, who have been using Powershell for a long time.

    A very good example is a basic functionallity for file Encoding. Since PowerShell 3.0 (!!!!!) the Parameter -Encoding has a value called “Default”. Since PowerShell 3.0, this value “Default” will encode the file based on the os Settings ansi Code page.
    With PowerShell core this was changed, now the value “Default” encodes all the time in UTF8.

    I have open a issue for this Problem in the git repo of PowerShell Core, you can finde the link below.

    There you can see that the Linux useres are more importend for Microsoft and his PowerShell Core than the own useres, what comes from Windows.
    Microsoft is not willing to change this mistake back to the functionality like it was in PowerShell 5.1.
    Tha means that for this example non of the scripts what Yous the parameter “-Encoding” with the value “default” want work well in PowerShell core.
    The generated Output file will be all the time in the wrong Encoding. If a file like this hannded over to a 3 Party app, all the datas in the 3. Party app will be wrong as well because of a wrong Encoding of PowerShell Core and Microfot how is not willing to fix this issue.

    Now I’m curious if my comment is deleted because he is too critical. In any case, I have already taken screenshots 😉

Leave a comment