For years I have spent most of my time in a Windows PowerShell prompt. I have actually taken it as a badge of honor that I've been able to manage my day and all of my work from a PowerShell prompt. I also have created practically all of my content on Windows PowerShell. I will continue to write and present on Windows PowerShell, but I feel I need to jump into the future as well and that means PowerShell Core. So for 2019 I've decided to make a PowerShell Core session, still running on a Windows platform my primary PowerShell interface. I still have Windows PowerShell if I need it but I want to learn more about what I can and can't do from a PowerShell core prompt.
ManageEngine ADManager Plus - Download Free Trial
Exclusive offer on ADManager Plus for US and UK regions. Claim now!
Do You Need PowerShell Core?
When I mentioned on Twitter that I was making the move to PowerShell Core as my "daily driver" I got some feedback asking why or that it wasn't relevant to them. And it might not be. I don't have Linux based servers that I need to manage. Everything I run is still Windows Server 2016. I also am still running a Windows 10 desktop. Personally, I need to make the jump to truly learn what is new and different in PowerShell Core so that I can teach about it and develop content. But I also know that Windows PowerShell 5.1 is feature complete. Microsoft is no longer developing it. Windows PowerShell isn't going away but the future is clearly PowerShell Core. You can run PowerShell Core side by side with Windows PowerShell so it's not like I have to give one up for the other.
If you need to manage non-Windows servers and those servers can run PowerShell Core, then it makes sense and is practically a requirement to run PowerShell Core on your desktop. Even though there are limitations today, PowerShell Core, and the underlying .NET Core, continues to be developed and updated. I would also argue that your next job might be in a more heterogeneous environment where your experience with PowerShell Core will be advantageous.
Installing PowerShell Core
Even though I had PowerShell Core installed, I realized I didn't have the most current version. I used commands from my PSReleaseTools module.
I then downloaded with msi package for Windows.
Get-PSReleaseAsset -Family Windows | where {$_.format -eq 'msi' -And $_.filename -match 'x64'} |
Save-PSReleaseAsset -Path D:\PS6\ -Passthru
Running the file installed PowerShell Core in a few minutes and it didn't require reboot. I pinned the program to my Task Bar and I'm ready to go. I should not that there is no PowerShell ISE equivalent in PowerShell Core. But that doesn't matter since I adopted VS Code as my main development tool a few years ago. If I really need it, I can still fire up the PowerShell ISE.
Profile Changes
Because I spend so much of my day at a PowerShell prompt, as you might expect I take full advantage of profile scripts to configure it. However, when I fire up PowerShell Core none of my current profile scripts apply. Remember, PowerShell Core and Windows PowerShell can run side by side. This means each has its own set of profile scripts.
As you can see, the PowerShell Core paths are completely different. Like Windows PowerShell, these files don't exist. You need to create them. Since I wanted to re-create as much of my Windows PowerShell experience into PowerShell Core I started by copying existing profiles. In my Windows PowerShell session, I copied the Current User All Hosts profile script to the corresponding PowerShell Core file.
copy $profile.CurrentUserAllHosts -Destination ~\documents\PowerShell\profile.ps1
This profile tends to pre-load modules and define my global settings. However when I launched PowerShell Core, much of the script didn't run or threw errors. That is because I was trying to load modules that PowerShell Core knew nothing about. Module locations are different.
I could re-install modules in PowerShell Core but that's a lot of work and overhead. The easier solution is to install the WindowsCompatibility module in PowerShell Core. In my profile script I added the command Add-WindowsPSModulePath. Once I do that then PowerShell Core can "see" all of the other installed modules.
There's no guarantee that every module will work in PowerShell Core. I already know that some won't due to limitations in the .NET Framework. I expect the major ones, like Active Directory, will eventually get refactored. Plus, that's one of the reasons for jumping into PowerShell Core. I want to learn what works and what doesn't (yet).
I followed a similar process by copying the Current User Current Host script from its Windows PowerShell location to the corresponding PowerShell Core location. Today, there aren't multiple PowerShell Core hosts on my machine and I'm the only user, so technically I should be able to combine everything into the Current User Current Host script. But for now I think I'll keep the separate scripts for conceptual purposes. If I ever add something that introduces another PowerShell Core host, then I'm ready.
Configure the Window
My last step was to configure the PowerShell Core window. Since I'm spending a lot of time in it I need to make it comfortable. I right-click on the system menu to get the Properties box.
I believe the default color scheme for PowerShell Core is black so I'll keep that. It also helps having a different color should I have Windows PowerShell also open. I decided to make my PowerShell Core window even more sexy by setting the opacity level. I could do the same for Windows PowerShell on Windows 10 but never felt motivated.
On the Layout tab I set my window size and screen buffer size to 120x35. If you keep them the same you'll avoid the horizontal scroll bar. On the Font tab, because I have 4K monitors and have reached a certain maturity level, I set the font size to 24. I prefer using Consolas.
More to Come
Next time I'll share with you the prompt function I developed for my PowerShell Core work. Over the course of the year I hope to share with you my experiences of working in and using PowerShell Core. I hope you'll share your experiences as well.
I too wanted to move but it was a very bad experience. I was excited with powershell core when it was released as I need not need another language to automate in Linux. Turns out that power shell core has shortage of commands as it’s based on .net core and not of .net framework. So I cannot exactly use the same coding model which I was using for 5.1 on core. I ah e to edit it , check what not in core and rewrite it again. The explanation from MS is ” it’s under development”. Next moving to invoke-commnad , I was excited to see the parameter “hostname” which can accept Linux hosts, but setting up a SSH session was a night mare. It still doesnt work. MS says they don’t support it yet, and we have to use OPEN SSH as of now. I agree that powershell’s object oriented shell has more advantageous than bash’s text based shell. Core is not yet ready to be a product.
It is true that some modules won’t run on PowerShell Core due to dependencies on the full .NET Framework. Hopefully over time those will be addressed. But you can run Windows PowerShell and PowerShell Core side by side. So if you need to do something that needs full .NET, jump into a Windows PowerShell session. In PowerShell Core on Windows make sure you have installed the WindowsCompatibility module. It is designed to help work around some of these issues. As for SSH, that is definitely a pain point for people who have never used it. PowerShell (and Microsoft) will never have its own flavor of SSH. That’s why OpenSSH now ships with Windows. You need to get SSH working on your boxes, outside of PowerShell. That is a separate, non-PowerShell, battle. But, once it is working, using SSH in PowerShell remoting is very easy and slick. It will work, but you have to be able to SSH between systems outside of PowerShell first. You might be able to get some help in the forums at PowerShell.org.
What’s your Out-Gridview replacement?
There isn’t one for Core yet. If I need it I will fire up Windows Powershell.
I appreciate this.
I have been dragging my feet because I’m all Microsoft.
But who knows what you can do with the new developments in Core until you get on it.
That is a big reason I’m diving in this year.
Hi Jeff,
I have used Powershell on Windows for a number of years and have grown to love it. I’ve reached the point where I am often at a roadblock in Windows scripting due to my own limitations – not so much on Powershell but my underlying lack of knowledge about a piece of Windows technology – such as exchange, Office 365 etc. I also spend more time working on Linux – CENTOS / Redhat these days. I have a reasonable understanding of Linux and to try experiment with Powershell here. Personally, for me, it feels like being taken out of my car and put back into the horse and cart to be honest. There is such a huge gap and the depth and maturity of existing solutions – ‘Bash being one’ – are very difficult to re-engineer in Powershell, and why would I given I already have a perfectly working bash scripting solution? I am not tribal re scripting solutions – but feel Powershell may never catch up here?
If you are in the Linux world and need to manage Linux then it makes perfect sense to use bash and all the wealth of tools available. PowerShell was never intended to replace that. PowerShell on Linux exists for more cross-platform management. *Eventually*, the goal is that you can manage anything from anywhere from any platform. But of course, there are going to be a ton of exceptions to that. PowerShell isn’t in a race to catch up with anything. It is its own complementary tool. Personally, I can see this appealing more to Windows admins who end up on a Linux box. They may struggle to navigate a bash shell, but PowerShell on Linux can help them be productive faster. It still comes down to the right tool for the job.