Kind of, but you're doing it wrong.

The bash way to remotely administer a server is to SSH into the server, then run your commands there. While that's technically possible with PowerShell in recent versions, it's not how PowerShell is designed to work with remote machines. Instead, your local copy of PowerShell is designed to grab the remote server's management objects, and use those to administer the remote server.

For example, say I quickly want to shut down a service on ten boxes. On a Unix system, I'd use a tool like Fabric/Ansible/whatever to quickly SSH into those ten boxes and run "/etc/init.d/whatever stop" (or equivalent). I guess you could do this all on one line with something like

    echo box1 box2 box3 ... | tr " " "\n" | xargs -L 1 -I BOX ssh BOX /etc/init.d/whatever stop

but that's really rare, in my experience, compared to using a tool like Fabric.

On PowerShell, in contrast, I'd grab the remote service objects, and pipe them into the Stop-Service cmdlet, locally. For example (written verbosely; there's a shorter way to do this):

    @('box1', 'box2' ... ) | ForEach-Object { Get-Service -name "whatever" -computername $_ } | Stop-Service

Note what's going on: I'm passing an array of box names in, grabbing out handles to the actual services running on the remote box, and then stopping those, using the local Stop-Service cmdlet.

Other things work the same way.

But my favorite part is that Windows servers actually vend a lot of their resources as PowerShell mounts. Changing the configuration of Apache on your server farm? Break out Puppet and some templates on Unix, but on Windows, use the IIS snapin to "cd" right into the IIS configurations on those boxes and use your normal cat/echo magic to change the configurations. Need to change registry settings? You can "cd" into the registries, too. Same for SQL Server. And because this is all through PowerShell, doing things like redirecting a SQL Server database name right into an IIS configuration file (e.g., configuring your website on which DB to use) becomes easy--again, across a pile of machines.

So: yes, you can remote in. But that's not how PowerShell is designed to work, and you're losing a lot of the magic if you do things that way.

This approach most likely requires that the script runs within the same trusted local network, correct? So, technically you'd still have to "ssh" into at least one box, and run all admin scripts from it.

"It depends."

Generally speaking, your servers will be bound to the same Active Directory domain, so if you're logged in via AD, and AD says you're an admin on the boxes you're trying to hit, you're good. This is called trusted authentication, and is similar to forwarding your SSH agent all over the place.

That opens up what happens if you're not in the domain (say, you're on your home laptop). Many commands take a -Credential parameter, which takes an authentication token available that you create via Get-Credential. If the command you want to use takes -Credential, then you can still avoid actually logging into the remote machine in the way you would for, say, SSH.

If, on the other hand, the command you want doesn't take -Credential, you do either need to use Invoke-Command, or genuinely log onto the remote PowerShell service via New-PSSession/Enter-PSSession, which is an extremely direct analog for SSH.

Would this not mean that to do administrative tasks you need to be using a Windows 7 Pro computer and could not do it from a Windows Home, Mac or Linux box?

You would need to RDC into at least one machine and run the scripts from there, in that scenario--so no worse than where you are now.

Note that Windows 8 removes the distinction between Pro and other editions.

Yes, this is the preferred approach since Windows 2008 Server Core. Please note that Powershell is only installed by default in Windows 2008 R2 Server Core.

You can then use Powershell remoting capabilites, or log into the server with SSH, like on UNIX systems.

Remoting is a bit hobbled I find. For example I'd love to be able to run vim in a powershell remoting session, but it doesn't seem to work.

That's largely because that's not really how Microsoft envisions you using PowerShell. The Windows way is to run the tool locally, edit the resource remotely (kind of like Emacs' TRAMP mode v. Vim users always sshing into the box). In this way, I kind of view PowerShell's direct remoting (i.e., Enter-PSSession) as a complete misfeature.

Even with the UNIX subsystem installed?