
PowerShell Remoting - axiomdata316
https://www.sconstantinou.com/powershell-remoting/
======
nunez
Remoting is SSH, but with much much MUCH more bulk (because it transfers full
objects over the wire and uses SOAP as its wire protocol; see here:
[https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.core/about/about_ws-
management_cmdlets?view=powershell-5.1)

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

~~~
cm2187
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.

~~~
zaat
> 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.

~~~
cm2187
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.

~~~
zaat
> 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.

------
hobs
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.

~~~
Analemma_
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.

~~~
equalunique
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.

------
reificator
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...](https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-
command-line-introducing-the-windows-pseudo-console-conpty/)

~~~
13of40
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.

~~~
reificator
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.

~~~
tcbawo
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.

~~~
3rdAccount
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.

~~~
davvolun
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.

~~~
3rdAccount
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.

------
tyingq
_" 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.

~~~
jodrellblank
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/...](https://www.reddit.com/r/PowerShell/comments/97oxox/comment/e4blfgj)

" _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...](https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encryption_question_xpost_from_rpowershell/)

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/...](https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/cqzj4l2)

~~~
Jaruzel
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.

------
geophile
Along the same lines:
[https://github.com/geophile/osh](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:

    
    
        osh @foo [ ps ^ f 'p: (p.pid, p.commandline)' ] $
    

\- osh: Invokes the interpreter

\- @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.

~~~
sjellis
I casually follow the development of the Elvish shell, which uses structured
data, and is written in Go:

[https://elv.sh/](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.

~~~
geophile
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?

------
arminiusreturns
Pywinrm is your friend if you are a nix person.

~~~
reificator
That's a good tip, I'll check that out. Still hoping for SSH server support
though...

~~~
xenophonf
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.

------
ChicagoDave
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.

------
equalunique
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.

------
newman314
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?

~~~
nineteen999
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.

------
madmulita
font-weight: 300;

Why do they insist on making the text hard to read?

