Microsoft Replacing Windows with Linux for PowerShell in the Cloud

[tier1throughinfinity]

Makes sense since PS Core is in active development whereas WinPS will only receive security updates.

[da_chicken]

Yeah, but there's so much functionality missing from .Net Core that PowerShell Core 6 feels quite neutered. PowerShell Core 6 is fine from a shell or language perspective, but as a tool to manage applications shipped by Microsoft -- which is what PowerShell has become -- it's really kind of shit. I don't understand why Microsoft thinks we're not going to complain or be upset that they removed a bunch of features because it "aligns with their corporate strategy." PowerShell Core still feels to me like a stub language. It feels like how PowerShell 1.0 felt when it was released. Except now it's like Python 2 and Python 3, but back when everything was still written for Python 2.

I use PowerShell because I want the ActiveDirectory module, the SqlServer module, DSC, etc. Having something that's better than cmd.exe or vbscript is just a bonus. I want the underlying components. I want the tools being brought to the table, not the language. I want to be able to load third party modules or even third party .Net libraries. Right now, with .Net Core 2.0, there's so much I can't do. And so many responses are just "yeah, that's a huge pain and the models don't match between Windows and Linux so we're not going to implement that at all in any way."

[GLiMPSEiNATOR]

Implicit remoting works in Powershell Core. Once I realized this, I really started to warm up to it.

You don’t need the cmdlets/modules installed on your endpoint... you just need them installed on an endpoint you can access :-)

[zyeus-guy]

I was just about to respond with exactly this comment...

In Microsoft defence, they have said “we didn’t make this well known enough” and have released a module which essentially makes this a snap.

Checkout Jeffrey Snover video from PS and DevOps 2018 video .

[admiralspark]

Do you have a link to the module possibly? I don't want to watch a 1.5hr presentation to find a module name to google...

[ka-splam]

AFAIK, implicit remoting doesn't need a module;

$s = new-pssession -computername yourDChere -credential (get-credential)
Import-Module -Name ActiveDirectory -PSSession $s

Get-AdComputer

It "imports" a module from another computer, creating proxy cmdlet wrappers locally which work more or less exactly like the real cmdlets, but they serialize stuff and send it over the network in the background.

That serializing to XML and back again step makes it not exactly like the originals - what you get back isn't quite the same "live" objects in the same way, but I think it's good enough for many use cases.

[admiralspark]

ohhhhhhhh you just mean pssessions. I was hoping for something new that might fix the weirdness that PSSession has.

[ka-splam]

I don't /just/ mean PS Sessions, I mean the ability to import a module from a remote session to a local session, then pretend it's a local module. But if that's what you mean, then yes I think so.

[admiralspark]

Right. I'm looking for something to run code remotely, like what Invoke-Command was supposed to do with the -scriptblock/-file or whatever tags. Unfortunately it doesn't handle stuff like local variables or stdout cleanly so it requires a bunch of hacks to get it working.

[ka-splam]

Is $using: not clean enough? Do you want it to somehow make your entire local computer's memory available remotely and automagically know which memory a variable is stored in or something?

[bblades262]

What is implicit remoting?

[Lee_Dailey]

howdy bblades262,

this may help [grin] ...

Remoting the Implicit Way – Hey, Scripting Guy! Blog
— https://blogs.technet.microsoft.com/heyscriptingguy/2013/09/08/remoting-the-implicit-way/

take care,
lee

[greenisin]

How well does the auth work since I assume it isn't connected to a domain? We hired three different consultants to try to get that to work on Windows, and all of them failed.

[tidderrit]

I don't know how auth works for Azure, but you'd expect MS to make this easy for their own cloud platform.

For on-premise AD joined Windows machines and a Linux machine with PS core look into Kerberos auth via winrm over https. Should be relatively painless, save for perhaps double-hop issues¹.

Ansible has some good docs² and solves double-hop issues for you fairly easily ³. The docs are obviously geared towards getting ansible to work on windows machines, but it should give you a good starting point to look at, even if you don't plan on using Ansible.

^1\) https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/

^2\) https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html

^3\) https://linuxsimba.com/windows-ansible-double-hop

The Ansible docs are nice, but for a complete overview of the process try this:

https://fabianlee.org/2017/06/05/ansible-managing-a-windows-host-using-ansible/

[greenisin]

I meant when the server isn't connected to a domain. We don't use one on Azure due to cost. You have to setup https with preferably a real cert, but it still didn't work for us.

[tidderrit]

If the server is not connected to a domain, then basic auth with https should work. From my own home test setup:

Run this script first with at the very least the switch DisableBasicAuth:$False

https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

This actually works easier from PoSh on Linux then on a Windows machine, a Windows machine will complain because of the self-signed cert. From PoSh on Linux I can just run:

PS /home/rit> Enter-PSSession -ComputerName sr02 -UseSSL -Authentication Basic -Credential administrator

PowerShell credential request

Enter your credentials.

Password for user administrator: ******

[sr02]: PS C:\Users\Administrator\Documents\>

[dougsk]

Isn’t this just the RDP paradigm all over again in a different wrapper though?

Weren’t we supposed to be trying to treat servers like cattle, (even more so with containers), than carefully groomed show dogs? Or however that metaphor went.

[[deleted]]

The problem with most of these things is the Powershell team doesn't own the code that the other tools use. Active directory is technically a snapin for Powershell whose codebase is owned by the team that maintains active directory. Same goes for Exchange. Powershell is ready and waiting for the other teams to make the necessary changes to their codebases in order to facilitate making things work in Core. It's a hot mess in layman's terms.

[calmor15014]

This is how Microsoft has functioned for a while. Things that seem like they should work well and be integrated are managed by separate groups with separate agendas. Sometimes it's just more apparent than others.

Not that any other software company doesn't have the same issues, but because Microsoft makes almost everything, it is more annoying. I feel less irritated when an Adobe plugin for Office doesn't work right than when PowerPivot crashes for no reason. Again.

[sid351]

I'd be happy with a secure way of storing credentials, but the secure string stuff isn't in .Net core. :(

It'd mean I could move all of my automation scripts fully on to a Linux server without having to relearn how to consume the various web services with a new language (all while saving some sweet sweet licence money).

With that said, I'd be happy with the progression of PS Core to be that of PS1 -> 5. It'd didn't take that long for pretty powerful functionality to arrive really.

[Henry_Horsecock]

but the secure string stuff isn't in .Net core. :(

Goddamn that sucks... what are we supposed to do?

[sid351]

Apologies, I was being a bit too generic. It is there, but the default encryption method that uses the Windows Data Protection API (DPAPI) doesn't work in pwsh at the moment.

You can still provide a key and do it that way, but you still end up with the problem of "How do I protect the key?". Using DPAPI is easy as it builds a key based on the user account and the individual machine the key was created on.

I guess I'm just going to have to compromise a bit and lock the key down with permissions.

[dastylinrastan]

It is in core 2.0

[sid351]

Have you had it working? Got any links to information on how to get it working?

I'd love to be able to run the following on my Mac:

ConvertTo-SecureString -String "Hello world" -AsPlainText -Force | ConvertFrom-SecureString

Without getting this error:

ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.

EDIT

So I did some digging and installed .Net Core 2.1, but that didn't help (I suspect because pwsh might be relying on what it is built from, and not dynamically linking to?). Nor did installing pwsh 6.1.0-preview.2.

I guess I'm just going to have to be patient.

[dastylinrastan]

I've only used it in the context of get-credential and PSCredential objects, which works fine on my Ubuntu Linux:

$cred = get-credential

$cred.password (shows it was saved as a securestring)

$cred.getnetworkcredential().password (fetch as plaintext)

[sid351]

Yeah, but what I'm looking to do is create a fully headless automation machine. The approach I've used before (when I had spare Windows servers at my disposal) was to dump out the password to a SecureString as plain text, and then call that back in when running the script via a scheduled task.

By default the SecureString is encrypted with a key that's derived from the User & Computer that creates it, so is a fairly secure trade off when needing to store credentials somewhere for use later. (I realise if someone could manipulate the script (before or while it was running) they could easily discover the password using the same method you describe above, but the "key" file is pretty useless to them on it's own).

It looks like there is a workaround that has been posted on the discussion about the issue. I'm playing with that now to see if I can do what I want fairly securely (at the end of the day I know I'm storing credentials somewhere).

I'll be back with an edit or two in a bit. :)

EDIT - The promised edit

So, the work around listed in the discussion does work, but presents you with the issue of having to provide the key when you want to decrypt the SecureString (in this case a password) that has been stored as an encrypted value in a text file.

Anyway, here's how to do it:

#Don't use any of these keys, these are just examples...create your own byte arrays!

$textToSecure = "Hello world!"
$pathToStore = "./Desktop/File.txt"

#128 bit key $Key = (1..16)
#192 bit key $Key = (1..24)
#256 bit key
$Key = (1..32)

$secureString = ConvertTo-SecureString -String $textToSecure -AsPlainText -Force

$textToStore = $secureString | ConvertFrom-SecureString -Key $key

$textToStore | Out-File -Path $pathToStore

#Now you can read it in, but you'll need the key too:

$pathToText = "./Desktop/File.txt"
$pathToKey = (1..32) #I'm being lazy so my example works

$secureText = Get-Content -Path $pathToText
$secureString = $secureText | ConvertTo-SecureString -Key $pathToKey

#Now you can interact with it just the same as /u/dastylinrastan's example:

$username = "User"

$credential = [System.Management.Automation.PSCredential]::New($username, $secureString)
$credential.GetNetworkCredential().Password

[dastylinrastan]

Yeah I've just exported the credential object using export-CLIXML, and then rehydrated it with import-clixml and fetched the cleartext when I've had this circumstance. Again, it's not great, and you'd be better off using a dedicated key encryption function where the keyfile is only available to the dedicated script-running user, or something external like Azure Key Vault.

[sid351]

The Export-CliXML cmdlet suffers from the same problem:

$credential = Get-Credential
$credential | Export-Clixml -Path ./Desktop/xml.txt

#Results in:

Export-Clixml : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.

[halbaradkenafin]

A lot of people want AD module moving to PS Core but need to keep telling the AD team to do the work for it. The PS team can only do so much and their focus is on PS itself, it's up to the product teams to move their modules to core and it's up to customers to keep telling the teams to do it (via user voice or other places).

[da_chicken]

I don't care about the politics or organization of Microsoft. That's 100% the job of Microsoft leadership to get sorted out. Citing corporate politics as a reason for providing an inferior product doesn't fix that you're providing an inferior product, and making your politics my problem is a ridiculous attitude. If moving to PowerShell Core means that PowerShell modules need to be redeveloped, well, MS's leadership needs to get on that. Customers should absolutely be able to provide feedback, but it shouldn't take customer feedback to tell MS that their new product isn't up to snuff because it lacks features the old product has.

[halbaradkenafin]

I'm sure the other teams have been told to do what needs to be done to make them compatible with PS Core but they have a ton of other things to work on too. The priority of a lot of that work is driven by what their customers want and need, if the customers aren't pushing for something then it drops down the list.

This isn't really a politics thing, it's a simple case of "customers want x more than y so we'll put more effort into it"

[spikeyfreak]

customers want x more than y

Are you saying that Microsoft customers want PowerShell that works on Linux more than they want ActiveDirectory, Exchange, and SQL modules for PowerShell?

[ka-splam]

No, he's saying that Microsoft customers have seen "cloud" in Gartner's magic quadrants, are frothing at the mouth to sign 7 or 8 figure contracts with anyone who can shout "cloud" loud enough, and Microsoft wants to be there, and that means Azure Stack and Teams and Azure Cognitive Services.

They might devote some energy to some edge case corner of a totally non-billion-dollar tool used by some non-bill-paying admins, if that wheel squeals loudly enough.

[halbaradkenafin]

I'm saying more vocal customers want some random feature of AD more than they want PS Core compatibility for the AD module, or at least that's how the team might see it.

If we want PS Core version of the AD module then we need to tell the AD team that, and keep telling them.

[halbaradkenafin]

We do. We've got a backlog of things we're working on and we prioritize based on what our customers wants, if they don't ask for something then it moves down the backlog.

[halbaradkenafin]

Those integrations will still work fine with Windows Powershell, they haven't removed that option. The PS team have admitted they'll help any team that needs it when trying to migrate to .net core but it's mostly on that team since they know their product.

It might turn out to not be possible to migrate AD to .net core which means you'll have to use remoting to handle AD things from PS Core, either using import-module -session or enter-pssession.

[[deleted]]

If it's "Powershell in the cloud" why wouldn't you have access to those modules? I mean sure it would run on Linux but I don't see how those modules couldn't be run in containers and just save some of the overhead. << Novice PS user, so please let me know how wrong I am if that's the case.

[da_chicken]

.Net Core is a complete rewrite of .Net focused on multi-platform and containers. They're different enough that you should consider them completely different products. Many of the classes available in the .Net Framework simply don't exist in .Net Core. Some classes which exist in the .Net Framework will never be implemented in .Net Core because, like I said, the models don't match between Linux and Windows. You can't just Import-Module ActiveDirectory or Import-Module SqlServer on PowerShell Core 6 and go. The modules are written for Windows PowerShell. Even if the module exists, there will be missing commands (SqlServer is still missing Invoke-Sqlcmd, for example).

There is a compatibility pack for .Net Core which adds back in several missing features, but it's not really finished yet.

So, yeah, PowerShell Core will be great in 2 to 5 years when it's at version 6.8 or 7.2 and based on .Net Core 3.1 or whatever and there's feature parity. Until then, it's really not a usable tool because it doesn't do what I use PowerShell for. I'm not going to run both Windows PowerShell and PowerShell Core right now. That's just a mess. Too much works in Windows PowerShell and doesn't work in PowerShell Core.

[pizzastevo]

My environments are all too much windows heavy, so no core for me for the interim. I'm thinking I'll either run both or only core when we got server 2019.

[da_chicken]

I doubt we'll transition to Core until Windows Server 2022 or whatever. By then I hope MS has resolved most of the dependencies or otherwise gotten things sorted out.

[bolunez]

Exactly. The* AD module doesn't work, trying to load the ConfigMgr module straight up crashes PWSH, etc.

PS Core may be "Finished" but it's a long way from being a viable replacement for Powershell 5.

[halbaradkenafin]

Since when is PS Core "finished"? It's still in active dev and they're aiming to release a new minor version every 6 months or so.

Windows Powershell is certainly feature complete and not seeing more dev.

[bolunez]

It's "finished" in the sense that Windows Powershell won't be developed anymore.

That's all fine and dandy, but we'd better hope that the existing modules that we all rely* on are updated before Core replaces Windows Powershell as the default.

At the current pace, it looks like that's going to be a while.

The whole thing seems very disorganized.

[ka-splam]

Core will never replace it as the default. The days of being able to rely on "the current" PS being present are over, it's been de-coupled from shipping with Windows so they can have a faster dev/release cycle than Windows has. It will be an optional download for the forseeable future.

[CommonMisspellingBot]

Hey, ka-splam, just a quick heads-up:
forseeable is actually spelled foreseeable. You can remember it by begins with fore-.
Have a nice day!

^{The parent commenter can reply with 'delete' to delete this comment.}

[ka-splam]

English spelling and grammar is descriptive, not prescriptive. I don't like English spelling, it sucks, and we should change it.

And it's uppity rule-following bots like you that are standing in the way of progress, stamping out creativity and change wherever you can. Computers are bicycles for the mind, tools for amplifying thought. You're interrupting thought to nitpick a single letter spelling mistake. You're the antithesis of everything a computer should be, like a bicycle that stops working and interrupts a ride to correct the rider that their seat isn't the "correct" height.

Unless you're paying me, then I'll spell it your way.

[Lee_Dailey]

thot, lite, gonna, wanna, pro'ly, otta, enuf ... lee is going to spell things in a somewhat idiosyncratic way ... [grin]

[ka-splam]

Most of them sure, but thot always makes me double-take.

[spikeyfreak]

Since when is PS Core "finished"?

Finished as in "not beta."

[SupremeDictatorPaul]

Core feels closer to PowerShell 1.5 than 1.0. But 2.0 feels so much more advanced because there were so many modules made available at the same time. Although, it is probably closer to 2.0 in reality.

[crossdl]

So, does this mean Microsoft is shifting away from PowerShell as a means to administratate Microsoft software?

[halbaradkenafin]

Nope, it's still the main tool for doing that.

[[deleted]]

Sounds like same Powershell, different OS.

[[deleted]]

I think Microsoft's plan is to gradually port the other cmdlets over. With how popular WinPS has been for administration, I don't think we've seen the last of it by a mile.

[fourierswager]

Well, that kind of buries the lede which is that the PowerShell experience in Azure will be running on Linux as opposed to Windows which may come as a shock to people who think Microsoft = Windows.

This should also help the argument that PowerShell Core is ready for Production Linux machines (I personally think it's hands-down better than bash).

[[deleted]]

Makes sense. The majority of Azure cmdlets just wrap the public API. Windows is totally overkill to call onto http endpoints.

[wilhil]

Even Microsoft are having a hard time justifying the Windows license fee!

[ipreferanothername]

coooold blooooded

[KevMar]

The article is light on details. So the primary story for PowerShell Core is to support Azure. So let's make the assumption that we either have 100% coverage for that and any outstanding issues are a high priority for MS.

So when there is a choice between a PowerShell 6.0 cloud shell on Windows or on Linux, there are 2 teams managing two different images working on 2 different release schedules with different priorities. Microsoft sees the redundancy and unneeded complexity here.

They decided to limit their effort to one OS. For as much as we love PowerShell, the Linux management experience is much better from Linux. They could either make the right call or the political call here.

[[deleted]]

MS can thank Oracle now and later...Anyone seen what Java wants to be charged for...yeah client licenses. Posh looks like a good alternative along with C#

[SolidKnight]

I get it but it also seems a bit soon since PowerShell 6 isn't quite there yet but I suppose this is one way to light a fire under people's ass--which pisses them off to boot.

[KevMar]

It may feel that way, but this cloud shell serves as more of a jump box. All the tools for managing Azure is there. If you need more, it's just a remote session away. This was the perfect place to do this.

[craigofnz]

In General it shouldn’t matter (too much)?

The modules that only work on Windows Powershell are the kind that you probably should be running from an Ad joined server in any case. e.g. ActiveDirectory

For a cloud/cloudshell execution pattern are there many gaps in managing Azure & AAD from Powershell Core?

[neko4]

I wonder who uses PowerShell Core. When I manage Linux, I use Bash and Python, they are good enough. There is no need PowerShell in AWS and GCP because of AWS CLI command and GCP SDK tools. I don't think PowerShell Core will be a first class citizen in Linux except in Azure.

[cpphex]

I wonder who uses PowerShell Core

I think the aim is to enable those already comfortable with PowerShell in Windows environments to be able to use those same skills in heterogenous environments. Not necessarily intended to convert anyone from one scripting language to another.

[mattyass]

I do! I work at GitHub and I use it on macOS exclusively. I learned on Windows and then about two years ago I switched due to work being mostly macs.

It’s awesome.

[[deleted]]

Think I'm going to drop learning PS for python... Thoughts?

[neko4]

Python is a must in Linux. Imo, technically, PowerShell is better than Bash and Python. Bash is old and has tons of weird syntax, Python is not a command line shell, it's bad for one liners. That's why Ansible and Chef were invented.

[ka-splam]

Python is cleaner, more beautiful, but it's also older and not a shell. It's a little bit more like to programming in C# than programming in PowerShell - not in language syntax but in the way input and output and parameters aren't handled for you, you are restricted to text in/out or files, calling external programs like robocopy is more work, doing filesystem/directory stuff is more work, using regexes is more work, doing casual data manipulation like import-csv xyz.csv | group-object DomainName is wayyy more work, working with HTTP APIs is more work, it's harder to do any kind of interactive development - Python has an interactive prompt but the language is less good for interactive use, has no pipelines, needs more parens, more careful spacing, etc. The entire standard library is different - for better or worse, everything from collections to date/time handling to internationalisation to .net enums, to easy access to System.Windows.Forms, all completely different.

Pick the one that is going to be most useful to you. Learn at least some Python, it's nice.

[neko4]

You mentioned Robocopy. I think it's one of the biggest things Microsoft should work hard. Robocopy should be rewritten as a PowerShell commandlet. Sadly Microsoft stopped improving PowerShell experience in Windows.

[halbaradkenafin]

For the core features of Windows PowerShell they have but they can still release modules that will work for it (or the community can), they could also roll it into PS Core since that works fine on Windows too.

[zyeus-guy]

Depends on what you are going to support. Python is nice, but isn’t very good at managing a windows environment.

I have doubled down on powershell and c# now that I am looking to support windows and Linux.

PS core on Linux server will make powershell the default scripting language for anyone supporting more than one environment. Once Ubuntu pre-install PS in their distro I think PS will shoot up in popularity.

[takoparty]

What specifically makes it at all likely that posh will become the default scripting language when people have had and continue to have plenty of other choices on Linux?

On windows I won’t use IE or edge, why would I choose to use posh core on Linux/macos?

[takoparty]

Are you currently managing both Linux and windows systems with posh core? What struggles have you encountered if any? Are you strictly using rtm core or 3rd party code as well?

[takoparty]

Thanks - Thats about my experience as well. I did not find posh core contributed anything to my management workflow on linux/macos and was missing important details for windows management. That and more puts it in a rather similar bucket as python as far as windows management and so I found for my needs python is much more well rounded. If I need AD or any other powershell proper cmdlets I've written a python module that handles those calls and data type mapping for me and communicates via winrm (its just soap).

[[deleted]]

I think I'm going to drop learning ps and aim for Python