I dived into WS-Management support in Vista / Longhorn Server Windows Server 2008 this weekend. There are a couple of caveats if you want to enable remote WS-Management based access to these machines. Support for remote management is also built into Windows Server 2003 R2.
WS-Management specification allows remote access to any resource that implements the specification. Everything accessed in a WS-Management world is a resource, which is identifiable by a URI. The spec uses WS-Eventing, WS-Enumeration, WS-Transfer and SOAP 1.2 via HTTP.
Since remote management implementation in Windows acknowledges all the work done in the WMI space, you can simply issue commands in terms of URIs that incorporate WMI namespaces.
For example, the WMI class or action (method) is identified by a URI, just as any other WS-Management based resource. You can construct access to any WMI class / action using the following semantics:
- http://schemas.microsoft.com/wbem/wsman/1/wmi denotes a default WMI namespace accessible via WS-Management
- http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default denotes access to root/default namespace
Since the majority of WMI classes are in root/cimv2 namespace, you should use the following URI to access those:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2
OK, back to WS-Management and its implementation in Vista / Windows Server 2008.
First, Windows Server 2008 has the Windows Remote Management service started up by default. Vista doesn't. So start it up, if you're on a Vista box.
Second, depending on your network configuration, if you're in a workgroup environment (not joined to a domain) you should tell your client to trust the server side.
Trusting the server side involves executing a command on a client. Remote management tools included in Windows Server 2008 / Windows Vista are capable of configuring the local machine and issuing commands to remote machine. There are basically two tools which allow you to setup the infrastructure and issue remote commands to the destination. They are:
- winrm.cmd (uses winrm.vbs), defines configuration of local machine
- winrs.exe (winrscmd.dll and friends), Windows Remote Shell client, issues commands to a remote machine
As said, WS-Management support is enabled by default in Windows Server 2008. This means that the appropriate service is running, but one should still define basic configuration on it. Nothing is enabled by default; you have to opt-in.
Since Microsoft is progressing to a more admin friendly environment, this is done by issuing the following command (server command):
winrm quickconfig (or winrm qc)
This enables the obvious:
- Starts the Windows Remote Management service (if not stared; in Windows Vista case)
- Enables autostart on the Windows Remote Management service
- Starts up a listener for all machine's IP addresses
- Configures appropriate firewall exceptions
You should get the following output:
[c:\windows\system32]winrm quickconfig
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:
Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.
Make these changes [y/n]? y
WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.
There are options in winrm.cmd to fine tune anything, including the listening ports and / or SSL (HTTPS) support. In a trusted environment you probably don't want to issue commands using HTTP based mechanism, since you are located behind the trust boundary and have complete control over available (allowed) TCP ports.
You can now issue remote management commands against the configured server, but only if the communication is trusted. So in case you are in a workgroup environment (client and server in a workgroup), this should get you started (client command):
winrm set winrm/config/client @{TrustedHosts="<server ip or hostname>"}
You can specify multiple trusted servers using a comma:
winrm set winrm/config/client @{TrustedHosts="10.10.10.108, 10.10.10.109"}
This trusts the server(s) no matter what. Even over HTTP only.
Enumerating the configured listeners - remember, listener is located on the destination side - is done via:
winrm enumerate winrm/config/listener
OK, now we're able to issue commands to the remote side using WS-Management infrastructure. You can, for example, try this (client command):
winrs -r:http://<server ip> -u:<username> -p:<password> <shell command>, ie.
winrs -r:http://10.10.10.108 -u:administrator -p:p$38E0jjW! dir -s
or
winrs -r:http://10.10.10.108 -u:administrator -p:p$38E0jjW! hostname
You can even explose HTTP based approach through your firewall if you're crazy enough. But using HTTPS would be the smart way out. What you need is a valid certificate with server authentication capability and a matching CN. Self-signed certs won't work.
Simple and effective.