Do you have a moment? I think it's time we had a little chat. No, no...you have done anything wrong. In fact, what I really need is your help. Because you are a member of the global PowerShell community, I felt I could talk to you. You do enjoy being a member of the community, don't you? I'm assuming you've gotten a lot of value from it. Maybe it has even advanced your career. If so, then I really need to talk to you for a few minutes about something very important, and that is the future of PowerShell. If PowerShell is an important part of your job and an even bigger part of your career, then we definitely need to talk.
ManageEngine ADManager Plus - Download Free Trial
Exclusive offer on ADManager Plus for US and UK regions. Claim now!
Open Source Means You
As you know, PowerShell is an open source project. And by PowerShell I mean PowerShell 7.x. Windows PowerShell 5.1 is a legacy product that should be used in situations where PowerShell 7.x isn't a viable option. You probably also know that PowerShell is a pretty active project. We no longer wait 3 years between releases. New releases come out twice a year. Even more if you count all of the previews. Where does all this new goodness come from?
To be sure Microsoft has a roadmap. But they also listen to the community. So much of what we have in front of us today is a result of PowerShell community members reporting problems and contributing code. Open Source means open to the community.
Issues Matter
Don't worry. I'm not going to ask you to write code to be added to PowerShell. I'm not even going that far. What you *can* do is pay attention to the Issues. This part of the PowerShell repository is more than a place to report problems. This is the area where Microsoft decides what to work on. The PowerShell team takes a lot of this information to help them prioritize work. This should matter to you.
This is where it gets tricky. I'll admit that many of the issues you'll find are developer-oriented. And that's one of the challenges we face as IT Pros. If only developer-oriented people are active in PowerShell issues, then we get a lot of developer-oriented features. As cool as the ternary operator is, I'd rather have a JEA successor that utilizes SSH. I will also be the first to confess that I have not done my part either.
Don't get me wrong, there's nothing wrong with language features and improvements. That's how we got ForEach-Object -Parallel. But we need more. "We" meaning IT Pros. We need to look at open issues and provide feedback on how it might affect how you use PowerShell to do your job. We need to report problems and bugs that are holding us back. We need to request features that would make us more efficient. In short, if we don't speak up, someone else will decide what version of PowerShell we are left to use.
Start Now
The first thing you need to do, if you aren't already, is to make PowerShell 7.x your default. PowerShell 7.x is PowerShell. Windows PowerShell is never going to change. You won't advance your career by sticking with Windows PowerShell. You can leave Windows PowerShell on your servers. All I'm talking about is moving to PowerShell 7 on your management desktop. If you really need it, you can always drop back to Windows PowerShell. I still use a lot of PowerShell scheduled jobs which only work in Windows PowerShell. Otherwise, I use PowerShell 7.x as much as possible.
If you need to install it, one easy way is to use my PSReleaseTools module. Install it from the PowerShell Gallery, then run Install-PowerShell. The PowerShell team has also gotten the latest PowerShell preview in the Microsoft store which is another option. It isn't that difficult to install and it can run side by side with Windows PowerShell. Or do what I do and use Windows Terminal.
Follow Issues
Next, you need to keep up to speed with PowerShell issues. While you don't need a GitHub account to view the issue, you will need one to contribute. If Watch the PowerShell repository, I think you'll get email notifications on issues. I have a mail filter that sends issue notifications to its own folder.
Or, since you may already have the PSReleaseTools, v1.8.0 of the module, includes commands for viewing issues from PowerShell.
Or you can use Open-PSIssue to go to the Issues section of the repository or open a specific issue.
The Bottom Line
Your action item is to get more involved with PowerShell issues. At least as much as you feel you can do. Yes, some of the issues are code-heavy. But don't be afraid to ask what it means to you and how you might use PowerShell. There are over 2600 open issues. I'm betting at least a few of them would have an impact on how you use PowerShell. If you don't speak up, someone else will speak up for you.
Problem is I have to use compatibility modes to do any of my work with Azure, and M365 or on Prem AD because I can’t import the ad module without switches.
Not worth it.
I realize there are some blockers and can’t speak to all your issues. But the Azure cmdlets should work. I’ve used the ActiveDirectory module in PowerShell 7 with no problem and nothing extra. If something doesn’t work the way you want, then you should post an issue so it gets attention.
Yeah, creating users can be done in pwsh 7 using New-AzADUser but all of a sudden you need to add to distribution groups. Connect-ExchangeOnline doesn’t really work, if you get it working then it is missing DistributionGroupMember cmdlets, then maybe you wanna see some license info. You’re going to need to use Connect-MsolService as you shouldn’t mix Az module with AzureAD, but MsolService doesn’t work or at least I didn’t get this working.
Fall back to PS5 for creating users simply cause i only need to use Connect-AzureAD, maybe I’m doing it wrong but it’d be nice to have pwsh 7 do the work.
Thank you for sharing. I think it is always going to be a challenge. The issue isn’t so much PowerShell as it is the supported version of .NET Core. Module authors need to keep on top of changes and that is easier said than done for some teams. For example, the Appx module no longer works in the PowerShell preview because .NET changed. The team responsible for the Appx module will have to rewrite. The best we can do is keep on top of the teams that support the tools we need.