Windows 7 / Getting Started

---

Remotely Managing Server Core

You have seen that you can use the command line for many configuration items, and nearly all Windows components come with command-line tools for management. So, you could manage Server Core locally. However, that is far from ideal, and you turned on the remote admin mode of Terminal Services so that you could remote to the box and access Server Core as if logged on locally. You have also seen how the MMC snap-ins can run on other computers and remotely manage the services on a Server Core installation. For example, the DNS MMC snap-in is probably the mostused remote management method. There are other options which give you the ability to remotely run commands on the Server Core installation- thanks to the inclusion of RPC and DCOM on Server Core, which facilitate the remote administration. Remember to enable the RemoteManage firewall rule.

Three of the MMC snap-ins require additional configuration on the Server Core installation:

• For Device Manager, enable the PnP policy. Even when enabled, Device Manager runs in a read-only mode, which is useful for checking hardware and device driver info. Load the local policy on the Server Core box (or create a Group Policy Object [GPO] that applies to Server Core) and enable the Allow Remote Access to the PnP Interface policy under Computer Configuration, Administrative Templates, System, Device Installation and reboot the Server Core computer.
• The Disk Management MMC snap-in requires two changes. Enable a firewall group on the server core installation and on the machine performing the remote management: netsh advfirewall firewall set rule group="Remote Volume Management" new enable=yes
  In addition, run the Virtual Disk Service via this command:
  net start VDS
• Enable Remote IPsec Monitor management using the SCRegEdit.wsf script:
  C:\Windows\System32> cscript scregedit.wsf /IM 1

Another command-line option is the WS-Management and Windows Remote Shell. However, this runs the command, remotely catches the output, and sends it back. The advantage of WS-Management is that it operates over HyperText Transfer Protocol (HTTP) or HyperText Transfer Protocol over Secure Sockets Layer (HTTPS), so there are no additional port requirements for WS-Management to function because the HTTP ports are normally open by default. However, you can change this port if required.

When you enable WS-Management on the server using the quick configuration, the best security method available to the installation is used. For example, on a domain-joined machine, Kerberos is selected. Run the winrm quickconfig command as shown in the following listing:

C:\Users\administrator.VIRT>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.

This can be configured via Group Policy through Computer Configuration, Administrative Templates, Windows Components, Windows Remote Management, WinRM Service and enabling Allow Automatic Configuration of Listeners. There are other options in the same policy location regarding the use of Kerberos/Basic authentication.

On the client side, use the WinRS command in the following format:

WinRS -r:<remote system> command

For the remote system, type in the name of the remote computer or enter it in the form of a URL; for example, http://ip address:port or http://fqdn; http://192.168.1.232:80 or http://savtstcore01.virt.savilltech. com. By default, your existing credentials are used. Credentials are passed using the /domain, /userd and /password arguments. Some sample uses are shown in the following listing:

C:\Users\Administrator>winrs -r:savtstcore01 ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix . . 	:
    Link-local IPv6 Address . . . . . 	:
fe80::c49a:b729:8c8b:471e%2
    IPv4 Address. . . . . . . . . . . : 192.168.1.232
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 192.168.1.1

Tunnel adapter Local Area Connection*:

Media State . . . . . . . . . . . : 	Media disconnected
Connection-specific DNS Suffix . . :

Tunnel adapter Local Area Connection* 2:

    Media State . . . . . . . . . . . : Media disconnected
    Connection-specific DNS Suffix . . :

C:\Users\Administrator>winrs -r:savtstcore01 cscript
c:\windows\system32\scregedit.wsf /AR /v
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

System\CurrentControlSet\Control\Terminal Server
  fDenyTSConnections
View Registry setting.
0

You can use the Task Scheduler as in a normal Windows installation, as items such as event logging/forwarding and performance counters, which you can fully access via the Computer Management MMC running remotely. You can use the reliability interface against Server Core. Note that you can access both the Task Scheduler and Event Viewer through the Computer Management MMC snap-in. You have full access to the local users and groups. (Although you could use the net user and net localgroup commands to perform user/group management locally.)

If you want to view the event log locally on a Server Core installation, use the Wevtutil.exe command. For example, to view the five most recent event logs in text format from the SYSTEM log, use the following command:

C:\Windows\System32>wevtutil qe system /rd:true /c:5 /f:text
Event[0]:
  Log Name: System
  Source: Virtual Disk Service
  Date: 2007-09-09T19:04:09.000
  Event ID: 4
  Task: N/A
  Level: Information
  Opcode: N/A
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: savtstcore01.virt.savilltech.net
  Description:
Service stopped.

You can also search for specific event IDs. For example, to search for reboots, which are event ID 1074, use the following command:

wevtutil qe system /q:*[System[(EventID=1074)]] /f:text

SNMP can be enabled on Server Core to allow management by your management tools if they are SNMP-based. SNMP is enabled by installing the SNMP feature. Both SNMPv1 and SNMPv2c are supported. Normal WMI scripting can be used both locally and, more likely, from a remote station.

Let's look back at the Remote Desktop option. Maybe you want a remote command prompt without a full session. With the new application publishing features of Windows Server 2008, you can publish a command prompt by performing the following actions.

You need to use the Terminal Services (TS) RemoteApp Manager, which is available on a full Windows 2008 installation with the Terminal Server Role installed. So, on a full Windows Server installation, add the Terminal Server role. Notice you need Terminal Server only because you want access to the RemoteApp Manager. Alternatively, you can add the Remote Server Administration Tools feature and select only the Terminal Server Tools option if you don't want to install the Terminal Server role on any server. This latter option avoids installing TS and allows configuration from any platform supporting Remote Server Administration Tools; for example, Windows Vista.

After the TS RemoteApp Manager is running, change the server that the client connects to so that the Server Core machine is selected via the Connect to Computer option in the Action menu of the Actions pane. In the Actions pane, click the Add RemoteApp Programs link, which starts the RemoteApp Wizard. After clicking Next at the Introduction screen of the wizard, a list of programs that can be published is displayed. Click the Browse button, navigate to the Windows\System32 folder, and select cmd.exe. Click Next and then click Finish.

Finally click the Create .rdp File link. The options for connecting to a computer and starting the Add RemoteApp Program Wizard.

You can take the generated RDP file and run it from any Vista/Windows Server 2008 client to open a seamless command window that is running on the Server Core installation. The following listing shows the content of the generated RDP that can be modified with an updated server name:

disableclipboardredirection:i:0
redirectposdevices:i:0
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
span monitors:i:1
remoteapplicationmode:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:0
authentication level:i:0
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:0
gatewaycredentialssource:i:0
full address:s:savtstcore01.virt.savilltech.net
alternate shell:s:||cmd
gatewayhostname:s:
remoteapplicationname:s:cmd.exe
remoteapplicationcmdline:s:
screen mode id:i:2
winposstr:s:0,1,424,117,835,356
compression:i:1
smart sizing:i:1
keyboardhook:i:2
audiomode:i:0
redirectclipboard:i:1
displayconnectionbar:i:1
autoreconnection enabled:i:1
prompt for credentials:i:0
negotiate security layer:i:1
remoteapplicationicon:s:
shell working directory:s:
disable wallpaper:i:1
disable full window drag:i:1
allow desktop composition:i:0
disable menu anims:i:1
disable themes:i:0
disable cursor setting:i:0
bitmapcachepersistenable:i:1

When using a terminal server connection with the Terminal Server Client (mstsc), ensure that disk drives are available from the client machine by selecting the drives as available under the Local Resources tab (you have to click the More button) or as an option. The local client drives are accessible as \\tsclient\<drive> on the remote system. You can then map to these drives to get full access as in the following example:

C:\Windows\System32>net use * \\tsclient\d
Drive Y: is now connected to \\tsclient\d.

The command completed successfully.