5 Things to Know About PowerShell Core on Windows
Unless you’ve been stuck in a data center server rack, you’ve most likely heard about the next version of PowerShell, referred to as PowerShell Core. This version will run on Windows, Linu,x and Mac systems. For those of you considering running it on a Windows box, allow me to share 5 things you should know.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Side by Side
Perhaps the best feature of PowerShell Core is that you can run it side by side with Windows PowerShell. PowerShell Core is installed in a separate location from Windows PowerShell and even has a different executable: pwsh.exe.
I have not run into any issues running both versions of PowerShell at the same time. Where you potentially might encounter an issue is establishing a traditional remoting connection to a server that might be running both Windows PowerShell and PowerShell Core. The latter has its own PSSession endpoint but connecting to it has proven problematic. Long-term Microsoft intends for us to use SSH anyway (more on that below) and that this may be a moot point.
Out of the box, PowerShell Core on Windows has a minimal number of available modules. There is a $env:PSModulePath variable but it may not point to all the available modules on your Windows box. For example, I have Hyper-V running but the Get-VM cmdlet isn’t recognized in PowerShell Core. The solution is to download and install the WindowsPSModulePath module from the PowerShell Gallery. The module has a single command: Add-WindowsPSModulePath. Run it. This will update the PSModulePath variable and now all of your Windows modules are available. Although, there’s no guarantee they will all work.
As you can see Get-VM now works, but Resolve-DNSName does not. The DNSClient module requires a part of the .NET Framework that is not supported in .NET Core, at least for now. Longer term, Microsoft is working on some sort of compatibility toolkit but for now, sticking Add-WindowsPSModulePath into your PowerShell Core profile script is your best bet.
Remoting with SSH
Perhaps the most exciting part of PowerShell Core is that you can now establish a PowerShell remoting session over SSH. Going forward in the PowerShell Core world, I think this will be the norm. For many Windows admins, SSH will be something new to learn. But once you have it setup, using it in PowerShell is just as easy as traditional PowerShell remoting.
There are a few new parameters to learn, but once you have a connection, the remoting experience should feel very familiar.
This may not impact that many of you but there is no PowerShell workflow in PowerShell Core. Again, part of the issue is that PowerShell Workflow relies on certain parts of the .NET Framework that don’t exist in .NET Core. There is also no workflow endpoint. If your Windows server is still running Windows PowerShell 5.1, you should be able to use workflow from your Windows 10 desktop. Personally, one of the best reasons to use a workflow had nothing really to do with workflow. It was the ability to process things in parallel. Microsoft recognizes scalability and parallelism is a big deal. So I’m hoping at some point, we’ll get that type of feature natively in the shell. At which point, most people won’t miss workflow at all.
Using PowerShell Core on Windows may give you a false sense of security, thinking you can run anything. Not true. One major thing I think you’ll miss is Out-Gridview. But this should come as no surprise given the nature of .NET Core. All the bits related to graphical interface tools are gone. This also means you can’t run WPF or WinForms based scripts in a PowerShell Core session. Even Get-Credential is now a console-based input tool.
Of course, since you still have Windows PowerShell, you haven’t lost anything. You should still be able to create graphical scripts and tools that remotely connect or manage systems running PowerShell Core but you’ll run them from your Windows 10 desktop. And who knows, perhaps someday we’ll have corresponding Linux tools for admins running a full graphical Linux desktop like Ubuntu!
If you haven’t started tinkering with PowerShell Core on Windows, you can download a release from https://github.com/PowerShell/PowerShell/releases in either msi or zip format. I’d love to know what you think about PowerShell Core and how you think it will change your job.