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.