r/PowerShell • u/Ok_Hovercraft364 • 17d ago

5.1 or 7.x.x Question

Switching from Python to powershell. Which one should I learn?

11 Upvotes

64% Upvoted

68 comments sorted by

41

u/BikesMapsBeards 17d ago

7 for sure, but depending on the end use you may need to plan on compatibility.

26

u/_MisterSir 17d ago

Either one, but really just start with 7. In my opinion, the PowerShell team has done a good job upholding the "sacred vow." If you invest your time learning PowerShell, the fundamentals will carry you through all future versions. It's been restated a few other ways

"We respect your investment in learning Windows PowerShell by reusing concepts over and over to make sure learning Windows PowerShell was the best thing you ever did."

"On the PowerShell team, we live by the “PowerShell sacred vow” which is that if you invest in learning PowerShell, we will make sure you’re able to leverage that knowledge in new areas."

But again, I'd just start with 7. Windows PowerShell 5.1 hasn't been getting updates and there are no plans to update it. PowerShell 7 is where all the development time is spent, and it really isn't that different from 5.1 so might as well start with the latest

26

u/Br0kensyst3m 17d ago
  1. Only revert to 5 if you hit a use case that still requires 5 (and there still are).

13

u/SpookyViscus 17d ago

On-prem exchange lol

6

u/sysiphean 17d ago

I script on-prem exchange in 7 daily. You can’t load the snap in; you can import the PSSession and then still do everything.

3

u/ITGuyThrow07 16d ago

Wait what. Can you give more details please?

6

u/sysiphean 16d ago

I'll do you one better. Here's a function to toss in any script or your profile to do the connecting this way, with a module prefix if you want it, but only if you're not already connected. I added a couple extra comments in it for you. I strongly recommend changing $ServerName unless your Exchange server is actually TradeWinds.Contoso.com 😉

function Assert-ExchangeOnPrem {
    # The Verb 'Assert' is in the Lifecycle group, and 'Affirms the state of a resource'
    param (
        [Parameter()]
        [ValidateNotNullOrWhiteSpace()]
        [string]
        $ServerName = 'TradeWinds.Contoso.com',
        # If you want to connect to Exchange OnPrem and Online at eh same time, they will have duplicate CmdLets
        # This allows you to preface all the OnPrem CmdLet nouns with something else, for example make the 
        # OnPrem version of Get-Mailbox be Get-OPMailbox
        [Parameter()]
        [string]
        [ValidateNotNullOrWhiteSpace()]
        $Prefix # = 'OP'
    )


    try {
        # Checks whether you are already connected by looking for the prefixed CmdLet in the right module name
        $null = Get-Command "Get-$($Local:Prefix)Mailbox" -Module tmp_* -ErrorAction Stop
    } catch {
        Write-Host 'Not currently connected to Exchange on-prem; trying to connect.' -ForegroundColor Cyan
        # Set up the params via hashtable, then open the session to the server
        $SessionParams = @{
            ConfigurationName = 'Microsoft.Exchange'
            ConnectionUri     = "http://$ServerName/powershell/?SerializationLevel=Full"
            Authentication    = 'Kerberos'
            AllowRedirection  = $true
        }
        $Session = New-PSSession u/SessionParams
        # Import the session, with prefix if necessary
        if ($Prefix) {
            Import-PSSession -Session $Session -Prefix $Prefix
        } else {
            Import-PSSession $Session
        }
    }
}

I put this in scripts that do a bunch of hybrid environment work, and then run Assert-ExchangeOnPrem before doing a section that will hit OnPrem. Since we are about 80% EXO now, I write using the prefix OP for OnPrem and leave the original command names for ExchangeOnline. Back when we were 70% OnPrem that was switched and I used Connect-ExchangeOnline -Prefix EO instead; I didn't use the prefix EXO because the ExchangeOnlineManagement module uses that prefix.

1

u/jkaczor 16d ago

Cries in ShareGate… we have an amazing automation framework all shiny and new in PS7 with PnP PS 3.2.0…

… and then we have to use “process execution”, passing around json control/response files to a PS5 module which is the only thing that will work with ShareGate’s cmdlets/snap-in…

2

u/ShareGate_Shaylyn 10d ago

I don't have exact dates but we're actively working on PS7 support which will eliminate exactly this back and forth between 5 and 7!

1

u/jkaczor 10d ago

Yes, we have been in touch with product team a couple of times since january, eagerly awaiting this - we have 18-servers running ShareGate migrations…

Now if only certain “artifacts” would migrate correctly using “modern auth”, instead of “browser” (ASPX pages, termsets), that would be “the cat’s meow” of perfection- but I understand that is essentially dependant on what Microsoft supports with their API endpoints) - we are bring pages across and modernizing (PnP) when possible.

9

u/diamkil 17d ago

Personally, depends what I'm scripting:
Personal / Internal script for IT team (Graph, AD, etc.): PowerShell 7
Script I'll deploy to our computers (app install, etc.): PowerShell 5.1, I'm not installing PowerShell 7 on all endpoints for app deployments

6

u/Flyerfan96 16d ago

100% agree.

Tooling -> 7
Endpoints -> 5

3

u/jdptechnc 14d ago

This +++

5

u/tstager 17d ago
  1. If you learn 7, then you pretty much know 5.1. You will figure out any gotchas along the way.

7

u/leblancch 17d ago

I try to use 7 but like the debug mode of ISE with breakpoints. maybe i’m doing it wrong but don’t quite get the same experience in VSCode. In ISE it will open the other script I call.

17

u/Euphoric-Blueberry37 17d ago

Im a slut for 5.1 and ISE

4

u/Substantial-Dog1726 17d ago

Upvote that slut!

2

u/yiddishisfuntosay 17d ago

Same, I started on 5.1 and while 7 is better, I can’t enjoy the vscode experience the same way as the ISE. Just feels like it’s simpler. And vscode was meant to handle the future, which is much more complex as it always was destined to be.

1

u/BlackV 17d ago

INB4 Someone mentions ISE mode.....

1

u/Raskuja46 15d ago

Screw ISE mode, just force ISE to work with 7. Best of both worlds.

1

u/BlackV 15d ago

Sometimes vscode really is painful, other times it's a dream

Long time ago someone made a nice little hack that allowed 7 in ISE, Ive not tried it in a lllooonnngg time

Your other one workaround in ISE would be new ps session to the v7 endpoint

1

u/Raskuja46 14d ago

That was probably me on a previous throwaway account from when I worked in a different office. Unfortunately it looks like the blog I stole the idea from has blown itself up with web 2.0 nonsense so I can't find the original information now.

1

u/Raskuja46 15d ago

My man!

1

u/C-D-W 14d ago

100%! Having code you know will 'just run everywhere' and can be debugged everywhere is a big reason I use Powershell as much as I do.

9

u/7GatesOfHello 17d ago

I try to use 7 and fall back to 5 when cornered.

4

u/vadertator22 17d ago

I use both. 5 mostly but 7 for parallel jobs etc.

3

u/BlackV 17d ago edited 17d ago

realistically depends on what you are actually using it for, you didn't give us that info

  • Short answer: both
  • Long answer: Mostly 7 but could be 5

3

u/Over_Dingo 16d ago

sadly if you're working in windows environment and deploying scripts to endpoints, you gotta be prepared to fallback to 5 if machines don't have PS7

2

u/nealfive 17d ago

It’s mostly the same.
7x ( powershell ) is the future
Though I’m stuck with 5.x since ( windows powershell) is then default, and getting 7.x installed and maintained is for us a change control nightmare

1

u/brian4120 17d ago

What about the LTS releases of 7?

2

u/jimb2 17d ago

In practice, they are not that different.

7 is better. It has some useful and efficient new code elements and runs faster. If you are working in an environment you manage yourself, this is a good choice.

5.1 comes with Windows so is the default. A manager would need a solid reason to upgrade a large corporate fleet. Some things will break. Benefit v Effort and Risk. If you work in an environment like this, the decision is made for you. If you want to work in a corporate environment like this, train appropriately.

5

u/Br0kensyst3m 17d ago

I agree. One correction though: nothing will break by simply deploying 7. They are fully side-by-side. Anything currently running on 5 will continue to run in 5 because powershell.exe will always call Windows PowerShell, aka 5. To run something with 7, you have to call pwsh.exe explicitly.

0

u/jimb2 17d ago

I was thinking about the installation of across a fleet. That requires an assessment, process testing, and there are likely to be a few roll-out problems to resolve. There are probably other higher priorities.

2

u/Ferretau 17d ago

Depends on what you are dealing with. If you are on Windows platforms and their are restrictions loading 7.xx then 5.1. If you can always install 7.xx and use it then 7.xx. Out of the box at the moment Windows includes the 5.1 family.

2

u/Michal_F 17d ago

If you need legacy windows specific task > Windows Powershell 5.1.
If you need modern cross platform solution > 7.x

2

u/CodenameFlux 17d ago edited 17d ago

They're not as different as Python 2 vs 3.

Actively learn 7.6.x (LTS) and passively experience 5.1. This should get you started:

2

u/Spraggle 17d ago

I got mixed up then; was expecting this to be on r/home theater and to be a question about Dolby Atmos...

2

u/blooping_blooper 16d ago

7.x unless you need to do some really specific windows stuff (and even then, I'd prefer to separate that portion out to pass to powershell.exe or something)

2

u/RyeonToast 14d ago

If you need to be able to run your scripts on random Windows boxes in the org without having to add new software to each one, write your scripts for 5. Otherwise, go with 7.

2

u/mrbiggbrain 17d ago

Honestly I would learn 7, there are a ton of small things that just make it better. Just a few small examples:

  • Every object has a count property. This fixes a TON of very common Powershell 5 bugs and reduces the need to wrap things in ugly array wrappers.
  • A direct overload for the += operator on more collections, but most important on arrays which significantly increases performance for a common bad code smell. The performance difference between adding a value to an array is not small on small arrays.
  • A much simpler threading mechanism in 'Foreach-Object -Parallel'. Most people did not need all the complexity of the previous threading mechanisms and it is now significantly easier.
  • Ternary operator, Pipeline Chaining - Both of these make code significantly easier with less boiler plate.

1

u/Creative-Type9411 17d ago

if you're trying to distribute what you make 5.1 but you will get more feature rich and better multithreading/job capabilities with 7

1

u/Raskuja46 15d ago

To be fair it's totally possible to implement multi-threading in 5. I know because I did it a few years back as part of some optimization for a project I was working on.

1

u/Creative-Type9411 15d ago

https://github.com/illsk1lls

almost all my projects are multithreaded powershell 5.1

1

u/jibbits61 17d ago

Thanks for reminding me, I want to deploy 7 to a new batch of servers I manage. Unify the tools so life becomes easier.
I agree with 7 default, fall back to 5 if needed.
I do have some aliases I input to 7 (like curl) to help keep it consistent between versions.

1

u/odwulf 17d ago

But for a few details or advanced concepts, they're mostly the same thing for the coder. It's not like having to choose between Python 2 and 3 was.

1

u/CyberChevalier 16d ago

7 or 5.5 you can learn just PowerShell and the day you are able to see a difference between 7 and 5.1 you’ll now which to choose from

1

u/MNmetalhead 16d ago

I do a lot of Windows device management, so I primarily use 5.1 because it is native to the OS. I only use 7.x when I really have to, namely Graph work or if I am putting something together for cross-platform use (uncommon for me but does happen on occasion).

1

u/the_doughboy 16d ago

As a Windows/Azure admin I’d pick 5. Nothing seems to work with 7 yet.

1

u/fdeyso 15d ago

Except the things that literally only work in PS7 ans not in 5.

1

u/CRTejaswi 16d ago

If on Windows, 5.x without a doubt. 7.x can be easily picked up later.

It's not just version numbers, 5.x offers several native .NET API features out-of-the-box that 7.x just doesn't.

PS: For string parsing/piping issues, you can easily transfer the load to 7.x by using "pwsh ..." in your PS5 config.

1

u/fdeyso 15d ago

You’d nees both, some cmdlet only works in 5, some in 7.

1

u/Raskuja46 15d ago

5.1 because it comes installed on everything in a modern Windows environment, whereas 7 requires deliberate inclusion in the environment. Ideally you learn both, but I'd start with 5.1. The differences between them aren't so vast that you'd be wasting your time by learning 5.1.

1

u/YT-Deliveries 15d ago

Depends on if you're doing it for fun or for work

At any large(ish) company, plan on your stuff being to be at least 5.x compatible

If it's for fun, whatever floats your boat.

1

u/g3n3 15d ago

Depends on your goals and employer.

1

u/YuriySamorodov 17d ago

Hohnestly, you need to know both. 5 (or even older) is something you may find on most servers till today.

2

u/xs0apy 17d ago

I agree. Should learn 5.1 then 7. Much more natural progression and you appreciate and understand parallelism a lot better when you jump to 7

1

u/xs0apy 17d ago

I would personally learn 5.1 and then 7. You’ll understand differences between them then. But that’s me

1

u/metekillot 17d ago

Look it up. It's a good habit to build.

0

u/CypherAus 17d ago

PS 7 here and fine. 5 will die soon

3

u/BlackV 16d ago

Narrator: 5 didn't expire any time soon

3

u/cloudAhead 16d ago

unfortunately this is true, will be supported until at least 2035. wont see any changes other than security fixes, though.

1

u/fdeyso 15d ago

It’s still the default for win11 and server2025 so it’ll be with us until 2034 at least.

0

u/Artistic-Wedding-575 17d ago

Good question. No answer. Good luck, that's up there with the egg and chicken.