WinRM: Domain or Workgroup?

Posted on

I'm curious about something and would like to hear from you. PowerShell v2 remoting uses WinRM which in a domain environment is very secure and easy to use. You can even use a GPO to configure your domain members. However you can also use WinRM in a workgroup environment but you have few hoops to jump through. My question is how many of you need remoting in a non-domain environment? What sort of scenarios do you have to support? I hope you'll let me know.

Manage and Report Active Directory, Exchange and Microsoft 365 with
ManageEngine ADManager Plus - Download Free Trial

Exclusive offer on ADManager Plus for US and UK regions. Claim now!
Behind the PowerShell Pipeline

3 thoughts on “WinRM: Domain or Workgroup?”

  1. We will be using it in a non-domain environment in order to manage Hyper-V Server 2008 R2 which are not joined to the domain since all of the DCs are virtualized. Now that PoSH can be easily enabled on Hyper-V Server, we will be using it more and more to configure and manage them.

    Michael

  2. The only scenario that I can think of for workgroup / standalone would be servers (mainly IIS) in a DMZ environment

  3. While Paul is correct about DMZs. However, keep in mind there are some companies that run every application and every layer of that application in a separate dmz – and do so both on domain and off.

    So it wouldn’t just be internet-facing web servers. The app tier on a domain is sectioned off from everything else – with explicit ports opened. Databases are sectioned off with only explicit ports opened.

    Many companies think this creates unnecessary overhead, but that is only true when your network topology is garbage to begin with. A properly build infrastructure is just like an operating system or a piece of code… The more you know about the explicit nature of what you are doing – the more benefit that is derived.

    That being said, we have had the need that WInRM is supposed to fill for years. We use SSH instead of WinRM for now. It’s a single administrative port for both remote command execution, file copy, and port forwarding. We also get interoperability with our *nix and Apple systems.

    WinRM is based on the WS-Management standard, which as I understand it, doesn’t address file copy, or system to system tunneling.

    So while I could use WinRM for commands and SMS for file copy – it’s a burden compared to using SSH.

    As for on domain vs off. We’d use it both ways.

Comments are closed.