Remotely managing your Server Core using WinRM and WinRS
I've already shown you how to remotely manage your Server Core installations of Windows Server Core using the Remote Desktop Protocol, but using Windows Remote Management (WinRM, Microsoft implementation of WS-Management) in combination with WinRS might prove to be even more useful for day to day administration.
About WS-Management
WS-Management is a specification of a SOAP-based protocol for the management of servers, devices, applications and more. The specification is based on DMTF open standards and Internet standards for Web Services and was published in March, 2005 by a group of companies, including AMD, Dell, Intel, Microsoft, Sun Microsystems and others.
WS-Management provides a common way for systems to access and exchange management information across the IT infrastructure. The specification is quite rich, supporting much more than get/set of simple variables, and in that it is closer to WBEM or Netconf than to SNMP. A mapping of the DMTF-originated Common Information Model into WS-Management was also defined.
Remote Shell
One of the most common uses for Windows Remote Management is the Remote Shell, (WinRS) that can be used to execute a program on a remote host.
Other uses
Windows Remote Management is not a stranger to this blog. I wrote a blogpost 6 months ago on event forwarding and already looked into WinRM. You might find your Windows Remote Management is already enabled after following those directions.
This blog post will be focusing on using WinRM, combined with WinRS.
WinRM
Windows Remote Management is the server part answering the Remote Shell. In Windows Server 2008 it is not enabled by default, which is good from a security point of view.
Determining whether WinRM is configured or not
Windows Remote Management is installed by default on Windows Server 2008 and the WinRM service is set to start (delayed) automatically. The only way to determine whether Windows Remote Management is installed is by examining the output of the following command:
WinRM enumerate winrm/config/listener
or (shorter, but with the same effect)
WinRM e winrm/config/listener
When this command has no output, it means no listeners are configured and Windows Remote Management is not configured.
Enabling Windows Remote Management
Using the command line
To enable Windows Remote Shell on a server running a Server Core installation, type the following command at the command prompt of the Server Core box:
WinRM quickconfig
or (shorter, but with the same effect)
WinRM qc
The command questions whether you really want to enable Windows Remote Management:
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
Make these changes [y/n]?
Press y to continue or n to cancel.
This command will perform a couple of actions. First of all it will check whether the Windows Remote Management service is started and set to start automatically. After that it creates listeners for all the network connections to accept Windows Remote Shell connections with default settings. It will also open up port 80 in the Windows Firewall.
If configuration is successful, the following output is displayed:
WinRM has been updated for remote management. WinRM service type changed to delayed auto start. WinRM service started. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Using Group Policies
When you place Server Core boxes in a separate Organizational Unit in your Active Directory environment you can manage Windows Remote Management centrally.
Look for the Windows Remote Management and Windows Remote Shell Group Policy Objects (GPOs) under Administrative Templates and Windows Components.
Do not forget to also open up TCP 80 on the firewall.
Default settings
The default settings of Windows Remote Management might not suit your needs. You can change on which network interfaces Windows Remote Management listens, change the URI's and change whether WinRM will use HTTP (TCP 80) or HTTPS (TCP 443)
While WinRM listens on port 80 by default, it doesn't mean traffic is unencrypted. Traffic by default is only accepted by WinRM when it is encrypted using the Negotiate or Kerberos SSP. Enabling HTTPS is not a security measure persé. It is needed when you want to use the Windows Remote Shell (WinRS) from a host that is not in the same domain as the Server Core box. (unless you use the trick below)
Windows Remote Shell is enabled by default within Windows Remote Management. For Windows Remote Shell the default settings are:
- Maximum of 5 concurrent users
- Maximum of 2 shells per user
- Maximum of 80MB memory usage per shell
- Maximum of 5 processes per shell
Disabling Windows Remote Management
To disable Windows Remote Management you need to remove the listener. The following command can be used:
WinRM delete winrm/config/listener?IPAdress=*+Transport=HTTP
WinRS
On another computer, at a command prompt, use WinRS.exe to run commands on a server running a Server Core installation. For example, type:
winrs -r:ServerName cmd.exe
Where ServerName is the name of the server running a Server Core installation with Windows Remote Management. This will result in a remote prompt where you can happily type away your commands.
Tips and tricks
Workaround for non-domain situations
When the Server Core box and the remote host are not members of the same domain you can't connect to the Server Core box using WinRS, because of the built-in security measures. Run the following commands to lower security:
Note:
You seriously cripple the built-in security of Windows Server 2008 after running the following commands. Only apply these commands to test situations.
On the Windows server Core box
Run the following commands on the console of the Server Core box to lower security:
WinRM set winrm/config/service/auth @{Basic="true"}
WinRM set winrm/config/client @{TrustedHosts="<local>"}
WinRM set winrm/config/client @{TrustedHosts="RemoteHost"}
Where RemoteHost is the host you want to be able to connect to the server.
On the remote host
Start the Command Prompt with elevated privileges. On machines with User Account Control enabled this is easily achieved by pressing the Start button, typing cmd and press CTRL and SHIFT together with Enter to run the command. Run the following commands on the remote host to lower security:
WinRM set winrm/config/service/auth @{Basic="true"}
WinRM set winrm/config/client @{TrustedHosts="<local>"}
WinRM set winrm/config/client @{TrustedHosts="ServerName"}
Where ServerName is the name of the server running a Server Core installation with Windows Remote Management.
To open the Remote Shell use the following command:
winrs -r:"ServerName": –u:Domain\Username –p:Password cmd.exe
Where Domain\Username is the name of an account with administrative rights on the server running a Server Core installation with Windows Remote Management and Password is the password for the account.
Trick to get the hostname displayed
Using the Windows Remote Shell might get confusing pretty fast, since the prompt doesn't show where you're connected to or whether you're connected at all. There are some giveaways though:
- When you type exit your command window doesn't close
- The WinRS command is displayed in the title of your command prompt window
This can become very painful when you decide to shutdown a server and turn off the wrong server accidentally...
Arlindo Alves, the Belgian IT Pro Evangelist, has a good trick to display some extra information on the command prompt, which also works when using the Windows Remote Shell. I suggest you read his blog post on it. It entails adding an Extended String value named prompt to the following registry key:
HKLM\System\CurrentControlSet\Control\Session Manager\Environment
He fills his prompt with all kinds of stuff (which doesn't seem to get passed through completely using WinRS) but I simply add the following data to the value:
Where IdentificationString is an identification string that accurately describes what the server is all about. (which in my case differs from the hostname)[IdentificationString]$s$p$g
Concluding
Windows Remote Management and the Windows Remote Shell are really good tools and can make your life as a systems administrators much easier. In the light of Server Core this combination of tools will not generate as much traffic as RDP'ing into a Windows Server 2008 box and can be scheduled. This might make it the ideal solution for day to day system management.
Unfortunately security is a real pain in the behind if both machines aren't in the same Active Directory domain. You'll need to type away some commands to make it work.
Arlindo Alves' tip to show the hostname of the server on both the console of the Server Core box and the remote shell might prove to be a real lifesaver.
Further reading
Installation and Configuration for Windows Remote Management
Windows Remote Management (WinRM) for Powershell and CMD on Windows 2008
Windows Server 2008 - Server Core - Change Default Prompt
Will the real Core please stand up?
WinRS: Microsoft's Disappointing Answer to SSH for Remote Administration
WS-Management: Windows Vista and Windows Server 2008
RedmondMag October 2007 - First Look: WinRM & WinRS
Configuring Windows Server 2008 Server Core Basic Networking Settings
Connecting to WinRM with Windows Vista
How can I remotely run commands on a Windows Vista or Windows Server 2008 box?
Comments
The things that are better left unspoken said:
Server Core installations can be specifically targeted at situations where single server roles are needed. Combining some of these roles on one server might also be very powerful, as I will show you in this post of my Easter SC'enarios series, where I'll try to construct the ultimate Branch Office server using Server Core roles. The roles and features I'll be using are:
This will result in a headless server, that can be safely stored in a kitchen cupboard of a remote location of your company.
The things that are better left unspoken said:
Server Core installations can be specifically targeted at situations where single server roles are needed. Combining some of these roles on one server might also be very powerful, as I will show you in this post of my Easter SC'enarios series, where I'll try to construct the ultimate Branch Office server using Server Core roles. The roles and features I'll be using are:
This will result in a headless server, that can be safely stored in a kitchen cupboard of a remote location of your company.
TrackBack said:
To use WinRM, the hosts communicating with it will need to be members of the same domain as the WinRM host. If this is not the case, I recommend you consult the different WinRM security scenarios in the article “Remotely managing your Server Core using WinRM and WinRS”.
Jonathan's Virtual Blog - Thinking Outside the Physical Box said:
What is WinRM. What's new in Windows Vista, Windows Server 2003 R2, Windows Server 2008 (and Server 2008 Core)
TrackBack said:
The things that are better left unspoken said:
Looking for a complete resource on remotely managing your Server Core box? Look no further! I've done
?????????????????? ? Windows Server 2008 WinRM???WinRS????????????????????? said:
WinRM (Windows Remote Management) Architecture | Troubleshooting ? Helpforsure said:
PingBack from http://helpforsure./2011/01/23/winrm-windows-remote-management-architecture-troubleshooting/
Blog Team TechNet Italia said:
Buon inizio di settimana a tutti. Oggi vi propongo la seconda parte della guida che Ermanno Goletto