PowerShell Remoting(sconstantinou.com)
sconstantinou.com
PowerShell Remoting
https://www.sconstantinou.com/powershell-remoting/
58 comments
The bulk because of soap is sort of irrelevant unless you are in a really slow connection where the size of every packet counts.
I have more serious griefs against powershell remoting.
For instance it is set up as a delayed start service which means you often have to wait more than a minute after a VM rebooted before you can log into it.
Windows Update is accessible by remoting through a COM API that doesn’t allow remote connections, so you can’t do the equivalent of a simple apt-get update remotely. There are horrible hacks around it, like setting up a scheduled task to trigger or collect the update and run that task from remoting and collecting the result some random way like reading a text file.
It really feels half baked, barely usable, and an ugly reminder that CLI has been added to windows as an after thought.
[edit] also I believe it is unencrypted by default. You have to enable https, which isn't straightforward. And you can't change the default ports.
I have more serious griefs against powershell remoting.
For instance it is set up as a delayed start service which means you often have to wait more than a minute after a VM rebooted before you can log into it.
Windows Update is accessible by remoting through a COM API that doesn’t allow remote connections, so you can’t do the equivalent of a simple apt-get update remotely. There are horrible hacks around it, like setting up a scheduled task to trigger or collect the update and run that task from remoting and collecting the result some random way like reading a text file.
It really feels half baked, barely usable, and an ugly reminder that CLI has been added to windows as an after thought.
[edit] also I believe it is unencrypted by default. You have to enable https, which isn't straightforward. And you can't change the default ports.
> Windows Update is accessible by remoting through a COM API that doesn’t allow remote connections, so you can’t do the equivalent of a simple apt-get update remotely.
This isn't even remotely related to PowerShell (no pun intended), it's a security based decision of the windows update API. You can say that it is annoying, stupid and cause of hacks that are much less secure than opening remote operations to the API, and I will agree with you. But it isn't PowerShell business.
As as side note If you are using SCCM you can use WMI for windows update.
PowerShell is far from being half baked, it is a first class citizen in Windows, all the OS GUI tools today executes operations through PowerShell. Many let you see the commands so you can bypass the gui next time and run the commands yourself. As a matter of fact, many things these days can only be done by the shell, while the GUI only expose limited set of the available API.
This isn't even remotely related to PowerShell (no pun intended), it's a security based decision of the windows update API. You can say that it is annoying, stupid and cause of hacks that are much less secure than opening remote operations to the API, and I will agree with you. But it isn't PowerShell business.
As as side note If you are using SCCM you can use WMI for windows update.
PowerShell is far from being half baked, it is a first class citizen in Windows, all the OS GUI tools today executes operations through PowerShell. Many let you see the commands so you can bypass the gui next time and run the commands yourself. As a matter of fact, many things these days can only be done by the shell, while the GUI only expose limited set of the available API.
I am not sure what you are trying the achieve by setting the cursor between the update API and powershell. Both are managed by the same group within the same company. The fact is Microsoft delivered an ssh-like scripting capability that cannot do simple things like updating the OS. You can call powershell a wonder, I beg to differ.
> Both are managed by the same group
I highly doubt that this is this the case.
>The fact is Microsoft delivered an ssh-like scripting capability that cannot do simple things like updating the OS
If you measure PowerShell by its ability to perform OS updates then you are correct, it is a failure. But the fact is that this annoyance isn't caused by the shell being half baked but rather it is an API decision of a different, unrelated product. The shell provides great usability in all other aspects - that is, the whole OS and other Microsoft and 3rd party software.
I highly doubt that this is this the case.
>The fact is Microsoft delivered an ssh-like scripting capability that cannot do simple things like updating the OS
If you measure PowerShell by its ability to perform OS updates then you are correct, it is a failure. But the fact is that this annoyance isn't caused by the shell being half baked but rather it is an API decision of a different, unrelated product. The shell provides great usability in all other aspects - that is, the whole OS and other Microsoft and 3rd party software.
Most of the issues I had with powershell remoting were related to the security model. It's totally integrated into AD. Which is fine if you're in the domain, but a nightmare to manage when you're not. Or if you want to do anything cross-domain (because, you know, you might now want to combine a production and test domain, or have any kind of explicit trust relationship).
As a fan and frequent user of PowerShell, I'm afraid I have to agree that PS remoting is pretty clunky. I often end up using psexec with cmd instead.
Not irrelevant: reactivity when typing in a remote shell affects very important features such as completion or resizing.
Note that Windows has had a similar capability to SSH for many years, but it's unfortunately not so well-known: https://docs.microsoft.com/en-us/sysinternals/downloads/psex... ("ps" prefix is unrelated to PowerShell, in fact I think this utility predates it.)
It uses DCE-RPC which is not trivial, but I believe it is certainly more compact than SOAP and such. The main advantage is the server component is built-in.
It uses DCE-RPC which is not trivial, but I believe it is certainly more compact than SOAP and such. The main advantage is the server component is built-in.
For the curious, https://en.wikipedia.org/wiki/Distributed_Computing_Environm...
It sounds super complex to setup.
It sounds super complex to setup.
Windows only takes the wire protocol from DCE, and added a few things here and there. It's used extensively in Windows, e.g. the DNS MMC snapin. For NT Domains it was THE protocol, until Microsoft moved to AD with more standards-based protocols, but even AD still heavily relies on RPC, i.e. for replication. The annoying thing about MSRPC is that it uses a portmapper process, like sun rpc for NFS3, so it's a pain to use with firewalls, as ports are randomly assigned. But it's widely simpler than a DCE environment, it's been made to fit internet protocols.
psexec is trivial to install and use: just download and run. At worst you might need to enable the RPC ports in the Windows firewall, which is also easy (even at scale thanks to GPO).
But is there anything to install or setup on a windows server other than opening a port? Also does it require the server to be domain joined?
No, all it requires is that "file and print sharing" is turned on and accessible. Windows has a default, hidden share "Admin$" which is used for this (just as "c$" exists as a share even if you don't explicitly share anything)
I was doing remote logins to Windows servers over SSH using cygwin like 10 years ago.
Yes, and it's was an awful hack and provided an incredibly poor experience. Luckily things are changing with https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...
I use SSH with the Windows 10 Ubuntu subsystem every day at work. It works great. Aside from the tmux windows frequently needing detached because of graphical glitches (they get "stuck" for lack of a better phrase), I don't have any complaints.
Considering the relative age of WSL integration in comparison to Windows and Linux themselves, it's progressing very nicely. I feel almost as comfortable on Windows now as I did on OS X 10 years ago -- but I don't need to pay the Mac Tax.
I love powershell, but I will say the troubleshooting the remoting aspect of it suuuuucks.
There were plenty of people cheering when they say they could ssh from powershell to a win box running powershell, just because of how annoying it is.
There were plenty of people cheering when they say they could ssh from powershell to a win box running powershell, just because of how annoying it is.
Trying to open a remote PowerShell session into a Windows VM running in Azure is agony. This seems like the most basic, fundamental operation you could imagine for an IaaS platform, particularly when you wrote all the components involved, and it’s nearly impossible.
I haven't tried doing this with Azure, but if it involves setting up PowerShell Remoting for local accounts and non-domain computers, then I can see why it would be a hassle.
The article is about powershell to powershell remoting. I like powershell itself fairly well, but I just feel so much more comfortable in bash/zsh and more importantly the environment around them.
I'm interested to see whether Windows SSH servers become more viable after ConPTY[0] is widely available.
[0]: https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...
I'm interested to see whether Windows SSH servers become more viable after ConPTY[0] is widely available.
[0]: https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...
One benefit you get with powershell to powershell remoting is that the output of the commands come back as objects rather than text. You can even use "implicit remoting" (not sure if that's the marketing term) to make the remoting part of it transparent to your automation - see Import-PSSession.
That's a pretty cool feature, but I don't often remote into machines and then want to do the processing locally. Maybe that's because I don't have this feature, but I've never felt like I wanted to. Usually I just treat the client like a dumb terminal.
I'd bet a project like Ansible could use something like that to great effect though.
I'd bet a project like Ansible could use something like that to great effect though.
IIRC, the main scenario for implicit remoting was where you were exposing a management interface for a service in no-language mode (i.e. the server will only run a whitelisted set of commands and no other scripting, for security) and any complex scripting needs to be done client side. So you'd open a console, import the commands from the remote machine, and now you can interact with it to do things scoped to your role, like diagnostics or restarting a service, etc.
That makes sense...
Its pretty cool actually, called Just Enough Administration, and its well supported.
https://docs.microsoft.com/en-us/powershell/jea/overview
https://docs.microsoft.com/en-us/powershell/jea/overview
From what I understand, PowerShell has been open-sourced and ported to Linux. Are non-Windows users adopting it? It's probably facing a long climb. Having 30+ years of productivity hacks is tough to compete with.
Part of it has, yeah. Personally I use it fairly frequently for scripting tasks on Windows, but have yet to have the urge to install it on anything else.
I use PowerShell on Windows because CMD is atrocious and some things just aren't great in Windows for Python. C# is also not efficient for those people used to the efficiency that comes with a Linux terminal and how to use it.
When I'm on Linux, I have tons of commands, bash, python, perl, Awk, sed...etc etc. All of those tools work perfectly with text which the Unix style OS embraces. Windows on the other hand is all objects and this can be painful in PowerShell at times.
Tldr; PowerShell is alright on Windows as it is the only real viable option for a power user. However, Linux is far better with what it already has and PowerShell would be a step backwards in functionality and efficiency.
When I'm on Linux, I have tons of commands, bash, python, perl, Awk, sed...etc etc. All of those tools work perfectly with text which the Unix style OS embraces. Windows on the other hand is all objects and this can be painful in PowerShell at times.
Tldr; PowerShell is alright on Windows as it is the only real viable option for a power user. However, Linux is far better with what it already has and PowerShell would be a step backwards in functionality and efficiency.
WSL (Windows Subsystem for Linux) is doing a pretty great job of making those *nix commands easily available on Windows. I don't know if it's ready for say DevOps day-to-day professional usage, but just being able to find, grep, awk on Windows works great for me.
Sadly I'm still on Windows7. I'll start the fight with IT over access (I assume configuring it requires admin) as soon as I'm on Windows10.
It's interesting - I get to a certain point with Powershell and then jump into Visual Studio to accomplish whatever I'm trying to do in C# instead.
I think it'd be better if there was a fully supported way to debug Powershell inside Visual Studio - the IDE is a step backwards.
I think it'd be better if there was a fully supported way to debug Powershell inside Visual Studio - the IDE is a step backwards.
Imagine if Microsoft focused on IronPython and added a high level of integration with PowerShell and/or Python-extensible utilities. Running/executing PowerShell from within a Python REPL would really be something.
OTOH there is no online streaming, right?
"The listener that is created when you enable PowerShell Remoting is over HTTP. You are able also to configure WinRM over HTTPS"
Doesn't seem like a good idea to default to plaintext.
Doesn't seem like a good idea to default to plaintext.
It's not plain text. The traffic is still encrypted by winrm.
Ahh. Would be a good note in that area of the article.
I was curious about the details and did some digging.
"Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key."
https://docs.microsoft.com/en-us/powershell/scripting/setup/...
"Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key."
https://docs.microsoft.com/en-us/powershell/scripting/setup/...
Then what's the point of using HTTPS? Heating the room?
See my other comment, but a) it encrypts more of the packets, b) helps with validating correct server, c) encrypts even if you end up authenticating without Kerberos somehow.
When using HTTP for remoting, headers are not encrypted. But body is always encrypted when using NTLM, CredSSP or Kerberos - the GSSAPI supported protocols. If user doesn't want to use these and opts for basic auth or some other protocol that doesn't have encryption specified, https is useful.
It's typical Microsoft engineering, and I say that as a frequent defender of powershell here.
It's encrypted, except when it isn't, except on Tuesdays when it is.
https://www.reddit.com/r/PowerShell/comments/97oxox/comment/...
"Just an FYI not all psremoting traffic is encrypted when using http. Message encryption is done using the authenticated context which varies based on what auth was actually used.
For example Basic auth has no authenticated context in SSPI so has no encryption.
NTLM (fallback if kerb is not available) is next to useless as it is based on RC4 which is considered broken today.
Kerberos should be using AES if configured correctly but older environment may have older insecure algorithms set up if the config is mismanaged on the domain level.
CredSSP uses the TLS context that is set up in the auth so is similar to using HTTPS.
When using https you not only get a more consistent and secure encryption mechanism on all auth methods. You also get encryption on the whole TCP packet that is sent to the client, whereas http message only encryption encrypts the message body."
And
"My understanding of the issue is that WinRM can do more than just Powershell Remoting (for example there are also Python libraries that run on Linux machines to interface with WinRM which I'm assuming do something different to PS remoting since PS is not native/required on those platforms). So if you are doing ONLY Powershell Remoting you're probably fine with HTTP, but if you're doing anything else then it could be exposed via HTTP WinRM. So HTTPS is still recommended.
tl;dr - All Powershell Remoting is WinRM, not all WinRM traffic is PS Remoting."
https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encr...
And
I think lots of people couldn't get a straight answer on this and it came up on the recent MCP Insider AMA.
First 3 minutes of video 2 "it's secure, use it [...] tell 'em Jeffrey Snover told you, go do it".
"Also, for more information on security when remoting read the powershell.org free e-book, Secrets of PowerShell Remoting.*"
https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/...
It's encrypted, except when it isn't, except on Tuesdays when it is.
https://www.reddit.com/r/PowerShell/comments/97oxox/comment/...
"Just an FYI not all psremoting traffic is encrypted when using http. Message encryption is done using the authenticated context which varies based on what auth was actually used.
For example Basic auth has no authenticated context in SSPI so has no encryption.
NTLM (fallback if kerb is not available) is next to useless as it is based on RC4 which is considered broken today.
Kerberos should be using AES if configured correctly but older environment may have older insecure algorithms set up if the config is mismanaged on the domain level.
CredSSP uses the TLS context that is set up in the auth so is similar to using HTTPS.
When using https you not only get a more consistent and secure encryption mechanism on all auth methods. You also get encryption on the whole TCP packet that is sent to the client, whereas http message only encryption encrypts the message body."
And
"My understanding of the issue is that WinRM can do more than just Powershell Remoting (for example there are also Python libraries that run on Linux machines to interface with WinRM which I'm assuming do something different to PS remoting since PS is not native/required on those platforms). So if you are doing ONLY Powershell Remoting you're probably fine with HTTP, but if you're doing anything else then it could be exposed via HTTP WinRM. So HTTPS is still recommended.
tl;dr - All Powershell Remoting is WinRM, not all WinRM traffic is PS Remoting."
https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encr...
And
I think lots of people couldn't get a straight answer on this and it came up on the recent MCP Insider AMA.
First 3 minutes of video 2 "it's secure, use it [...] tell 'em Jeffrey Snover told you, go do it".
"Also, for more information on security when remoting read the powershell.org free e-book, Secrets of PowerShell Remoting.*"
https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/...
I totally agree here. Every time Microsoft roll out a new product or feature, it seems they go out of their way to make it as complex as possible.
A lot of their server side products have weird restrictions or integrate with their other products in strange ways. Nothing is standardised, or simple.
For example, I'm in the middle of a project that needs to log audit data from a front-end service. The service isn't that busy, so doesn't really log that much, however the reporting interface only works with System Center. So to build out the reporting infrastructure I need: 2x System Center Service Manager Management Servers, and 2x System Center Service Manager Data Warehouse Servers, and 2x SQL Servers in a live-sync arrangement. That's six servers, three in each Datacenter. Four of which need 16Gb of RAM. The Management Servers do hardly any work, but due to an artificial restriction placed in the installer, you cannot install them on the same boxes as the Data Warehouse component. Even if you could, MS wouldn't support it.
All this to log no more than 100-200 events a day. To do the reporting any other way, is unsupported. It's nuts. I am starting to believe that Microsoft are now deliberately making their products so complex and so expensive to build on premises, in order to push customers into their Cloud platforms instead. This is certainly true of Exchange Server which is now an absolute nightmare to manage on premises. It's a mail server, why is it so complex?!
To be honest, it wouldn't surprise me if even internal Microsoft product designers and engineers no longer understand how most of the Microsoft server products even work or integrate.
And I say all this as someone who's spent 25 years working with Microsoft products as my day job.
A lot of their server side products have weird restrictions or integrate with their other products in strange ways. Nothing is standardised, or simple.
For example, I'm in the middle of a project that needs to log audit data from a front-end service. The service isn't that busy, so doesn't really log that much, however the reporting interface only works with System Center. So to build out the reporting infrastructure I need: 2x System Center Service Manager Management Servers, and 2x System Center Service Manager Data Warehouse Servers, and 2x SQL Servers in a live-sync arrangement. That's six servers, three in each Datacenter. Four of which need 16Gb of RAM. The Management Servers do hardly any work, but due to an artificial restriction placed in the installer, you cannot install them on the same boxes as the Data Warehouse component. Even if you could, MS wouldn't support it.
All this to log no more than 100-200 events a day. To do the reporting any other way, is unsupported. It's nuts. I am starting to believe that Microsoft are now deliberately making their products so complex and so expensive to build on premises, in order to push customers into their Cloud platforms instead. This is certainly true of Exchange Server which is now an absolute nightmare to manage on premises. It's a mail server, why is it so complex?!
To be honest, it wouldn't surprise me if even internal Microsoft product designers and engineers no longer understand how most of the Microsoft server products even work or integrate.
And I say all this as someone who's spent 25 years working with Microsoft products as my day job.
It's typical Microsoft engineering
What surprises me the most is they could've used the existing (also quite over-engineered, but existing nonetheless) MSRPC infrastructure for this, like what psexec does, but chose to use a completely different set of technologies once again.
What surprises me the most is they could've used the existing (also quite over-engineered, but existing nonetheless) MSRPC infrastructure for this, like what psexec does, but chose to use a completely different set of technologies once again.
Tbf, using kerberos which most windows installations get for free with AD is a good idea, saves issuing certs etc. But they really need to move on and deprecate NTLM, and basic should only be allowed over TLS... I think you're right with the whole microsoft really does let you shoot youself in the foot, and will gladly hand you the gun to do so.
Along the same lines: https://github.com/geophile/osh
Osh (Object shell) is a command-line utility for running sequences of operations connected by a pipe-like construct. Objects are piped, not strings. Included in the sequence of operations may be remote sequences of command, which run on all nodes of a cluster. For example, if you have configured a cluster named foo, then you can get the pid and commandline of every node of your cluster like this:
- @foo [ ... ]: Run the bracketed commands on every node of cluster foo.
- ps: The osh ps command, which yields a stream of Process objects.
- ^: The osh pipe symbol
- f: Function application. The function in this case takes a Process p, and returns a tuple containing the process's pid and command line.
- $: Print the contents of the input stream, one per line.
This is a python tool, so the stuff piped between operations are python objects.
Osh (Object shell) is a command-line utility for running sequences of operations connected by a pipe-like construct. Objects are piped, not strings. Included in the sequence of operations may be remote sequences of command, which run on all nodes of a cluster. For example, if you have configured a cluster named foo, then you can get the pid and commandline of every node of your cluster like this:
osh @foo [ ps ^ f 'p: (p.pid, p.commandline)' ] $
- @foo [ ... ]: Run the bracketed commands on every node of cluster foo.
- ps: The osh ps command, which yields a stream of Process objects.
- ^: The osh pipe symbol
- f: Function application. The function in this case takes a Process p, and returns a tuple containing the process's pid and command line.
- $: Print the contents of the input stream, one per line.
This is a python tool, so the stuff piped between operations are python objects.
I casually follow the development of the Elvish shell, which uses structured data, and is written in Go:
https://elv.sh/
The latest release has a package manager for plugins, so hopefully we'll see more support for remote stuff through that route.
PowerShell has some great ideas, but it seems doomed to mostly be a quirk of Windows at this point. I'd really love to see a more modern shell than bash get adoption across the industry.
https://elv.sh/
The latest release has a package manager for plugins, so hopefully we'll see more support for remote stuff through that route.
PowerShell has some great ideas, but it seems doomed to mostly be a quirk of Windows at this point. I'd really love to see a more modern shell than bash get adoption across the industry.
Hadn't heard about Elvish, thanks for the reference.
I've thought about a new version of osh, making it less of a command-line utility, and more of a shell. What do you think would be the main properties of a "more modern shell"? Do you think it is OK if this shell drags in a Python interpreter?
I've thought about a new version of osh, making it less of a command-line utility, and more of a shell. What do you think would be the main properties of a "more modern shell"? Do you think it is OK if this shell drags in a Python interpreter?
Pywinrm is your friend if you are a nix person.
That's a good tip, I'll check that out. Still hoping for SSH server support though...
I've installed and run OpenSSH via Cygwin on Windows systems going back to Windows Server 2003 at least. I think Cygwin provides a better UX than WSL, and its deployment is easily automated.
I worked at a client that manually pulled data from 70+ remote servers every morning to combine into a financial report.
I enabled ps-remoting, wrote a bunch of scripts, and turned this process into an automated batch job that took 3 minutes.
One of those odd jobs that was a lot of fun.
I enabled ps-remoting, wrote a bunch of scripts, and turned this process into an automated batch job that took 3 minutes.
One of those odd jobs that was a lot of fun.
I can appreciate the clear explanation of Powershell Remoting in this guide. It was a big part of one of my previous jobs. It is a pathway to basic dev-ops things in a Windows environment.
Given that my company pushes things out using GPO, I'm trying to figure out if we are missing something by not leveraging PS Remoting.
Does anyone have any use cases where PS Remoting would be more useful?
Does anyone have any use cases where PS Remoting would be more useful?
Ansible supports powershell remoting. In a past role I used it to install SQL Server and other software packages on Windows servers. I've also used it to install VMware vCenter and all its dependencies, pGina etc.
A bit clunky to set up but it works. I'd rather use SSH than WinRM though, which should be possible in the future now that MS has added SSH support to Windows.
A bit clunky to set up but it works. I'd rather use SSH than WinRM though, which should be possible in the future now that MS has added SSH support to Windows.
I use it for auto-deployment using Team Services into IIS. There is a plug-in for powershell remoting which works great for this and the client can be installed on a local vm or computer. You can of course start any other workflows from there too. It’s free so no need to do octodeploy or anything like that. Usually I also have it send a message to a slack channel when complete and start the deployment through the web: https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy...
font-weight: 300;
Why do they insist on making the text hard to read?
Why do they insist on making the text hard to read?
Now that Windows 10 and above support native SSH with a somewhat-real pseudo terminal, we can probably just use SSH instead in the next year or two without having to pay Bitvise a ton of cash