In our ongoing effort to configure Windows Server 2008's GUI-less incarnation, Server Core, we've named the server, given it a DNS suffix, assigned static IP values, enabled Automatic Updates, and worked a bit with Ocsetup and Oclist. Now, it’s time to set up remote Server Core administration by taking the nifty new remote-access tool Winrs for a spin.Web Elements? N/A
In this column’s continuing effort to configure Windows Server 2008’s GUI-less incarnation, Server Core, we’ve named the server, given it a DNS suffix, assigned static IP values, enabled Automatic Updates, and worked with Ocsetup and Oclist— tools that let you add or remove server modules such as DNS and DHCP. Now, let’s set up remote Server Core administration by taking the nifty, new remote-access tool Winrs for a spin.
A Better Alternative
When I set up Server Core systems for clients, they always want to know how to enable Remote Desktop. My answer is always, “Wait! There’s a better alternative!” Server Core can’t run 95 percent of GUI-based applications, so there’s no need to enable Remote Desktop, particularly when Server 2008 and Windows Vista share a new secure remote command shell—that is, the Winrs command.
I like Winrs because although it’s a remote-control tool, it doesn’t require that you open any of the Five Ports of Peril—TCP 135, 139, and 445 and UDP 137 and 138. Winrs runs atop TCP port 80; it essentially runs on HTTP or, more exactly, HTTPS traffic. To do so, Winrs takes advantage of the relatively new Windows Remote Management (WinRM) protocol that’s built into Server 2008 and Vista. You enable WinRM by typing (from an elevated command prompt)
Run that command on both the host and client machines—you need only do it once.
WinRM won’t let Winrs communicate with any hosts except the ones it trusts. WinRM trusts all fellow members of an Active Directory (AD) forest, but a WinRM client won’t talk to another system in a workgroup unless you give the client the OK by issuing the command
where list is either a comma-delimited list of DNS names or IP addresses of trusted systems, or an asterisk to denote “trust every host.” For example, to trust the system at 192.168.1.7 and the system named ace.bigfirm.com, you’d type
You must type the TrustedHosts command on the client, not the server. Thus, if I wanted to use Winrs to control a Server Core system from a Vista system, all I’d have to do is enable WinRM on both systems, then execute a TrustedHosts command on the Vista machine, and I wouldn’t have to execute one on the Server Core system. That seems a bit backward to me! In fact, given that Winrs requires NTLM, Kerberos, or certificate-based logons by default, it already boasts plenty of security, and you’re probably safe by simply typing the following command at the client:
Putting It to Work
To find out your system’s current list of trusted hosts, you’d type
Assuming that your client system trusts the remote Server Core system and that both systems have run winrm quickconfig (or the Group Policy equivalent), you’d then type
If you’re remotely controlling a system in the same forest and need to use a different account than the one you’re logged in as, or if you’re remotely controlling another system in a workgroup, you’d use that -u parameter. For example, to tell a system named sc1 .bigfirm.com to run an IPconfig command where sc1.bigfirm.com has an administrative account named administrator, you’d type
Winrs would then prompt you for the password for the administrator account, and you’d get the output of an IPconfig command run on sc1.bigfirm.com. If you need to run several commands instead of just one—a likely scenario on Server Core—you’d be better off typing
On my Vista desktop, Winrs is useful as a command prompt that I can open at any time and type an administrative command to the Server Core system. I think WinRM and Winrs add up to a far superior remote-command solution for Server Core than Remote Desktop (unless you’re attempting remote control from Windows XP, which doesn’t offer Winrs). Give it a try!