0

I'm writing a REST API that encapsulates some common Windows management tasks, (DNS/DHCP management, terminal sessions, etc.). I don't want to use PowerShell Web Services, as I don't want OData in my API. I'm trying to figure out what's the most efficient way to execute remote management commands on the back end.

As far as I can tell, the options are:

  • WMI over RPC, using System.Management. There's also Microsoft.Management.Infrastructure, but it seems to be locked to Windows 8/2012 R2 and above, which doesn't work for me. Obviously this isn't the most firewall friendly, and is probably considered legacy by MS, but is probably the fastest protocol.

  • WMI over WSMAN, using an approach like How to access WinRM in C#. This is more in line with MS's current thinking from a protocol perspective, but XML parsing could be painful with more complex return sets.

  • PowerShell Remoting, this probably results in the most readable code (after the Powershell session is created), and you wind up with some sort of (generic) objects but this seems like the slowest method, because of the time it takes to spin up the PowerShell session.

Am I missing anything? Am I going a step backwards by using System.Management?

Community
  • 1
  • 1
  • What are your specific goals? Referring to the first option you want to maintain systems older than Win8 - as fast as possible. Thaught about an own service on the server/target system? – Clijsters Apr 16 '16 at 19:35
  • A single, REST based interface to manage Windows, so that I can build flexible client tools in non-Windows environments (mobile, Linux). Adding a "helper service" for communications purposes seems to just add another layer of management, I'd still need to use one of the methods above to do the work. – Julian Rodriguez Apr 17 '16 at 22:55
  • I would recommend WMI over RPC. It works on more systems than PowerShell, is fast and adaptable... First I thought you want to build it on the client machine. – Clijsters Apr 18 '16 at 08:45

0 Answers0