Managing a Windows Server Core Server
Once we’ve performed initial configuration of our Windows server core server, we can then add roles and optional features so that it can provide needed functionality to our network. In this section, we’re going to examine how to perform such common tasks, and we’ll also look at different ways of managing a Windows server core server, including using the following:
-
Local administration from the command prompt
-
Remote administration using Terminal Services
-
Remote administration using Remote Server Administration Tools
-
Remote administration using Group Policy
-
Remote administration using WinRM/WinRS
Local Management from the Command Line
When we log on to the console of a Windows server core server, a command prompt appears. From this command prompt, we can do a lot of things:
-
Run common tools such as netsh.exe and netdom.exe to perform various tasks, as we saw previously.
-
Use special tools such as oclist.exe and ocsetup.exe to install roles and optional features on our server to give it more functionality.
-
Run in-box scripts such as slmgr.vbs and scregedit.wsf, as we saw earlier, to perform certain kinds of tasks.
-
Create our own scripts using Notepad, and run them using Cscript.exe and the supported WMI providers.
-
Use the WMI command line (WMIC) to do almost anything from the command line that you can do by writing WMI scripts.
As we mentioned before, however, one thing you can’t do is run PowerShell commands to administer your server. The reason for this omission is that PowerShell is managed code that requires the .NET Framework in order to work, and the .NET Framework is not included in the Windows server core installation option. Why? Because the .NET Framework has dependencies across the whole spectrum of different Windows components, and leaving it in would have increased the size of the Windows server core installation option until it was very nearly the size of a full installation of Windows Server 2008. For future versions of the Windows server core installation, however, a slimmed-down .NET Framework might be available that can provide PowerShell cmdlet functionality without the need of increasing the footprint significantly. But we’ll have to see, as that’s something that would happen after RTM. Note that you can however use PowerShell remotely to manage a Windows server core installation if the script strictly uses only WMI commands and not cmdlets.
Let’s look how to perform two important tasks from the command line: adding server roles and adding optional features.
Installing Roles
Let’s start by seeing what roles are currently installed on our server and what roles are available to install. We’ll use the oclist.exe command to do this:
C:\Windows\System32\>oclist Use the listed update names with Ocsetup.exe to install/uninstall a server role or optional feature. Adding or removing the Active Directory role with OCSetup.exe is not supported. It can leave your server in an unstable state. Always use DCPromo to install or uninstall Active Directory. =========================================================================== Microsoft-Windows-ServerCore-Package =========================================================================== Not Installed:BitLocker Not Installed:BitLocker-RemoteAdminTool Not Installed:ClientForNFS-Base Not Installed:DFSN-Server Not Installed:DFSR-Infrastructure-ServerEdition Not Installed:DHCPServerCore Not Installed:DirectoryServices-ADAM-ServerCore Not Installed:DirectoryServices-DomainController-ServerFoundation Not Installed:DNS-Server-Core-Role Not Installed:FailoverCluster-Core Not Installed:FRS-Infrastructure Not Installed:MediaServer Not Installed:Microsoft-Windows-MultipathIo Not Installed:Microsoft-Windows-RemovableStorageManagementCore Not Installed:NetworkLoadBalancingHeadlessServer Not Installed:Printing-ServerCore-Role | |--- Not Installed:Printing-LPDPrintService | Not Installed:ServerForNFS-Base Not Installed:SIS Not Installed:SNMP-SC Not Installed:SUACore Not Installed:TelnetClient Not Installed:WindowsServerBackup Not Installed:WINS-SC
Note that the oclist.exe command displays information about both roles and features installed and not installed on the machine. We can see from the command output that the DNS Server role is not presently installed on the machine. We can also verify this by typing net start in the command line:
C:\Windows\System32>net start These Windows services are started: Application Experience Background Intelligent Transfer Service Base Filtering Engine COM+ Event System Computer Browser Cryptographic Services DCOM Server Process Launcher DHCP Client Diagnostic Policy Service Diagnostic System Host Distributed Transaction Coordinator DNS Client Group Policy Client IKE and AuthIP IPsec Keying Modules...
In fact, the only DNS binaries presently installed are those for the DNS client:
C:\Windows\System32>dir dns*.* Volume in drive C has no label. Volume Serial Number is FC68-BDF4 Directory of C:\Windows\system32 02/09/2007 10:00 PM 163,840 dnsapi.dll 02/09/2007 09:59 PM 24,064 dnscacheugc.exe 02/09/2007 10:00 PM 84,480 dnsrslvr.dll 3 File(s) 272,384 bytes 0 Dir(s) 27,578,523,648 bytes free
Now let’s install the DNS Server role using the ocsetup.exe command as follows:
C:\Windows\System32>start /w ocsetup DNS-Server-Core-Role
After a short while, the command prompt appears again. The reason we used the /w switch with start is because that way control is not returned to the command prompt until the ocsetup command finishes its work. (By the way, note that ocsetup is case sensitive.) Now if we type oclist, we should see that the DNS Server role has been added to our server:
C:\Windows\System32\>oclist... Not Installed:DirectoryServices-ADAM-ServerCore Not Installed:DirectoryServices-DomainController-ServerFoundation Installed:DNS-Server-Core-Role Not Installed:FailoverCluster-Core Not Installed:FRS-Infrastructure ...
We can also see that three additional binaries for DNS are now present on the server:
C:\Windows\System32>dir dns*.* Volume in drive C has no label. Volume Serial Number is FC68-BDF4 Directory of C:\Windows\system32 03/20/2007 11:59 PM <DIR> dns 02/09/2007 11:42 AM 484,864 dns.exe 02/09/2007 10:00 PM 163,840 dnsapi.dll 02/09/2007 09:59 PM 24,064 dnscacheugc.exe 02/09/2007 11:42 AM 162,816 dnscmd.exe 02/09/2007 11:42 AM 13,312 dnsperf.dll 02/09/2007 10:00 PM 84,480 dnsrslvr.dll 6 File(s) 933,376 bytes 1 Dir(s) 27,576,926,208 bytes free
And if we type net stop dns, we can now stop the DNS Server service without getting an error because the service is now present on the machine. Now that our machine is a DNS Server, we can use the dnscmd.exe command to further configure this role if we want from the command line.
Installing other server roles is similar to what we just did and uses the ocsetup.exe command, with the exception being that the process installs the Active Directory role. This is because Dcpromo.exe in Windows Server 2008 now installs the Active Directory binaries during promotion and uninstalls the binaries during demotion, so you should not use ocsetup.exe to add or remove the Active Directory role as then the promotion/demotion will not take place and your server may not function correctly.
Anyway, to add or remove the Active Directory role, you therefore have to use the dcpromo.exe tool, but you also have to run it in unattended mode because the GUI form of this tool (the Active Directory Installation Wizard) can’t run on a Windows server core server because of the lack of a desktop shell to run it in. The syntax for running dcpromo.exe in unattended mode is dcpromp /unattend:unattend.txt, and a sample unattend.txt file you could use (or further customize) for doing this is as follows:
[DCInstall] ReplicaOrNewDomain = Domain NewDomain=Forest NewDomainDNSName = contoso.com AutoConfigDNS=Yes DNSDelegation=Yes DNSDelegationUserName=dnsuser DNSDelegationPassword=p@ssword! RebootOnSuccess = NoAndNoPromptEither SafeModeAdminPassword = p@ssword!
For more information on using dcpromo in unattended mode, type dcpromo /?:unattend at the command prompt.
Installing Optional Features
Installing optional features is very similar to installing roles. Type oclist to display a list of installed and uninstalled features and to determine the internal name of each feature. For example, the Failover Cluster feature is named FailoverCluster-Core, and we need to use this internal form of the name when we run ocsetup to install this feature. You can also remove features by adding an /uninstall switch to your ocsetup command. You can remote roles that way too, but be sure to stop the role’s services before you remove the role.
Other Common Management Tasks
There are lots of other common management tasks you might need to perform on a Windows server core server. The following is just a sampling of some of these tasks.
First, you can add new hardware to your server. Windows server core servers include support for Plug and Play. So if your new device is PnP and there’s an in-box driver available for your device, you can just plug the device in and the server will recognize it and automatically install a driver for it. But we did mention earlier that the Windows server core server installation option of Windows Server 2008 does not include that many in-box drivers. So what do you do if your device is not supported by an in-box driver because of its date of manufacture? In that case, follow this procedure:
-
Copy the driver files from the driver media for the device to a temporary directory on your server.
-
Change your current directory to this temporary directory, and type pnputil –i –a <driver>.inf at the command prompt.
-
Reboot your server if prompted to do so.
Note that if you want to find what drivers are currently installed on your server, you can type sc query type= driver at a command prompt.
What if you want to install some application on your server? First of all, beware-any application that has a GUI might not function properly when you install it. Obviously, that means we can’t install Microsoft Exchange Server, Microsoft SQL Server, or other Windows Server System products on a Windows server core server, because these products all have GUI management tools (and more importantly, a Windows server core server is missing a lot of components needed by these products such as the .NET Framework for running managed code).
What kinds of applications might you want to install on a Windows server core server? The usual stuff-antivirus agents, network backup agents, system management agents, and so on. Most agents like this are GUI-less and should install fine and work properly on a Windows server core server. And the Windows Installer service is yet another feature that’s still present on a Windows server core server-and if you need to install an agent manually, you should try and do so in quiet mode using msiexec.exe with the /qb switch to display the basic UI only. For example, you can do this by typing msiexec /qb <package> at the command prompt.
If you need to configure Windows Firewall, the NAP client, or your server’s IPSec configuration, you can use netsh.exe to do this. I won’t go into all the details here, as you can just check TechNet for the proper netsh.exe syntax to use for each task.
What about patch management? We already described how to enable Automatic Updates on the server, and if you have Windows Server Update Service (WSUS) deployed, you can manage patches for your server using that as well. For Windows server core servers that you want to manually perform patch management on, however, you can use the wusa.exe command to install and remove patches from the command prompt. To do this, first download the patch from Windows Update and expand to get the .msu file. Then copy the .msu file to your server, and type wsua <patch>.msu /quiet at the command prompt to install the patch. You can also remove installed patches from your server by typing pkgmgr /up /m:<package>.cab /quiet at the command prompt.
Let’s hear more about patch management on a Windows server core installation of Windows Server 2008 from one of our experts:
 |
When using Windows server core, the new minimal installation option for Windows Server 2008, a common topic of discussion is servicing. First a little background and then some methods to make dealing with patches easier.
With Windows Server 2008, each patch that is released contains a set of applicability rules. When a patch is sent to a server, either by Windows Update or another automated servicing tool, the servicing infrastructure examines the patch to determine if it applies to the system based on the applicability rules. If not, it is ignored and nothing is changed on the server.
If you have already downloaded a set of patches and want to determine if they apply to a Windows server core installation, you can do the following:
-
Run wusa <patch_name>.
-
If the dialog box that appears asks if you want to apply the patch, click No. This means that the patch applies, and you should move on to the next step. Otherwise, the dialog box will state that the patch doesn’t apply and you can ignore the patch.
-
Run wusa <patch_name> /quiet to apply the patch.
After applying patches, you can run either the wmic qfe command or systeminfo.exe to see what patches are installed.
–Andrew Mason
Program Manager, Windows Server
|
What else can you do in terms of managing your Windows server core installation of Windows Server 2008? Lots! For example, if you need to manage your disks and file system on your server, you can use commands such as diskpart, defrag, fsutil, vssadmin, and so on. And if you need to manage permissions and ownership of files, you can use icacls.
You can also manage your event logs from the command line using the wevtutil.exe command, which is new in Windows Vista and Windows Server 2008. This powerful command can be used to query your event logs for specific events and to export, archive, clear, and configure your event logs as well. For example, to query your System log for the most recent occurrence of a shutdown event having source USER32 and event ID 1074, you can do this:
C:\Windows\system32>wevtutil qe System /c:1 /rd:true /f:text / q:*[System[(EventID=1074)]] Event[0]: Log Name: System Source: USER32 Date: 2007-03-20T22:26:36.000 Event ID: 1074 Task: N/A Level: Information Opcode: N/A Keyword: Classic User: S-1-5-21-3620207985-2970159875-1752314906-500 User Name: DNSSRV\Administrator Computer: DNSSRV Description: The process C:\Windows\system32\shutdown.exe (DNSSRV) has initiated the restart of computer DNSSRV on behalf of user DNSSRV\Administrator for the following reason: No title for this reason could be found Reason Code: 0x840000ff Shutdown Type: restart Comment:
To create and manage data collectors for performance monitoring, you can use thelogman.exe command. You can also use the relog.exe command to convert a performance log file into a different format or change its sampling rate. And you can use the tracerpt.exe command to create a remote from a log file or a real-time stream of performance-monitoring data.
To manage services, you can use the sc command, which is a very powerful command that provides even more functionality than the Services.msc snap-in.
What else can you do? Lots. Let’s move on now to remote management.
Remote Management Using Terminal Services
You can also manage Windows server core servers from another computer using Terminal Services. To do this, you first have to enable Remote Desktop on your server, and because we can’t right-click on Computer and select Properties to do this, we’ll have to find another way. Here’s how-use the scregedit.wsf script we looked at previously. The syntax for performing this task is cscript scregedit.wsf /ar 0 to enable Remote Desktop and cscript scregedit.wsf / ar 1 to disable it again. To view your current Remote Desktop settings, type cscript scregedit.wsf /ar /v at a command prompt. Note that in order to allow pre-Windows Vista versions of the TS client to connect to a Windows server core installation, you need to disable the enhanced security by running the cscript scregedit.wsf /cs 0 command.
Once you’ve enabled Remote Desktop like this, you can connect to your Windows server core server from another machine using Remote Desktop Connection (mstsc.exe) and manage it as if you were logged on interactively at your server’s console. In this figure I’m logged on to a full installation of Windows Server 2008 and have a Terminal Services session open to my remote Windows server core server to manage it.
There’s more! Later in Chapter 8, “Terminal Services Enhancements,” we’ll describe a new feature of Terminal Services in Windows Server 2008 that lets you remote individual application windows instead of entire desktops. Let’s hear now from one of our experts concerning how this new Terminal Services functionality can be used to make managing Windows server core servers easier.
|
There are several ways to administer a Windows server core installation, ranging from using the local console to remote administration from a full Windows Server 2008 server using MMC. A really cool mechanism is to manage the Windows server core installation using Terminal Services RemoteApp to make the command line console available. This allows command-line administration without having to be physically present at the box, and without having a full-blown terminal server session. (After all, a Windows server core installation does not need the full desktop; it just needs the console, and Terminal Services RemoteApp is perfect for this.) A full Windows Server 2008 machine is necessary, along with the Windows server core installation that is to be administered.
On the Windows Server 2008 machine, add the Terminal Server Role using the Server Manager administrative tool. Only the Terminal Server role itself is needed, not the TS Licensing role, TS Session Broker role, TS Gateway role, or TS Web Access role. After the TS role is installed, start MMC and add the TS RemoteApp Manager snap-in, providing the name of the Windows server core machine to the snap-in. Once the snap-in is installed, connect to the Windows server core machine and click Add Remote Apps. Navigate to the %SYSTEMROOT%\System32 folder using the administrative share, select cmd.exe, and complete the wizard. Select the cmd.exe entry in the RemoteApp pane, click Create .rdp File, and follow the wizard to save the RDP file. Ensure that TS is enabled on the Windows server core machine. (Use the scregedit.wsf script.) You can now copy the RDP file to any client machine and connect to the Windows server core installation through it. The console will be integrated into the task bar of the client, like a local application. For more information on Terminal Services and TS RemoteApp, please see Chapter, “Terminal Services Enhancements.”
–Rahul Prasad
Software Development Engineer, Windows Core Operating System Division
|
And here’s another expert from the product team at Microsoft sharing some additional tips on managing Windows server core servers using Terminal Services:
|
When you’re using Terminal Services in a Windows server core server without the GUI shell, some common tasks require you to do things a little differently.
Logging off of a Terminal Services Session
On a Windows server core server, there is no Start button and therefore no GUI option to log off. Clicking the X in the corner of the Terminal Services window disconnects your session, but the session will still be using resources on the server. To log off, you need to use the Terminal Services logoff command. While in your Terminal Services session, you simply run logoff. If you disconnect your session, you can either reconnect and use logoff, use the logoff command remotely, or use the Terminal Services MMC to log off the session.
Restarting the Command Prompt
When logged on locally, if you accidentally close the command prompt you can either log off and log on, or press CTRL+ALT+DEL, start Task Manager (or just press CTRL+SHIFT+ESC), click file, and run cmd.exe to restart it. You can also configure the Terminal Services client to have the Windows keys pass to the remote session when not maximized so that you can use CTRL+SHIFT+ESC to start task manager and runcmd.exe.
Working with Terminal Services Sessions
If you ever need to manage Terminal Services sessions from the command line, the query command is the tool to use. Running query sessions (which can also be used remotely) will tell you what Terminal Services sessions are active on the box, as well as who is logged in to them. This is handy if you need to restart the box and want to know if any other administrators are logged on. Query has some other useful options, and there are a variety of other Terminal Services command-line tools.
–Andrew Mason
Program Manager, Windows Server
|
Remote Management Using the Remote Server Administration Tools
Although you can manage file systems, event logs, performance logs, device drivers, and other aspects from the command line, there’s no law that says you have to. For example, the syntax for wvetutil.exe is quite complex to learn and understand, especially if you want to use this tool to query event logs for specific types of events. It would be nice if you could just use Event Viewer to display, query, and filter your event logs on a Windows server core server. You can! But you have to do it remotely from another computer running either Windows Vista or Windows Server 2008 and with the appropriate Remote Server Administration Tools (RSAT) installed on it.
We talked about RSAT earlier in Chapter 4, “Managing Windows Server 2008,” and it’s basically the Windows Server 2008 equivalent of the Adminpak.msi server tools on previous versions of Windows Server. So if you want to use MMC snap-in tools to administer a Windows server core server from a Windows Vista computer or a machine running a full installation of Windows Server 2008, you might or might not need to install the RSAT on this machine because both Windows Vista and full installations of Windows Server 2008 already include many MMC snap-in tools that can be accessed from the Start menu using Administrative Tools. Event Viewer is one such built-in tool, and here it is running on a full installation of Windows Server 2008, showing the previously mentioned shutdown event in the System event log on our remote Windows server core server.
Remote Administration Using Group Policy
Another way of remotely administering Windows server core servers is by using Group Policy. For example, although the netsh advfirewall context commands can be used to configure Windows Firewall, doing it this way can be tedious. It’s much easier to use the following policy setting:
Computer Configuration\Windows Settings\Security Settings\Windows Firewall With Advanced Security
By creating a GPO that targets your Windows server core servers, either by placing these servers in an OU and linking the GPO to that OU or by using a WMI filter to target the GPO only at Windows server core servers, you can remotely configure Windows Firewall on these machines using Group Policy. For example, you can use the OperatingSystemSKU property of the Win32_OperatingSystem WMI class to determine whether a given system is running a Windows server core installation of Windows Server 2008 by checking for the following return values:
-
12 – Datacenter Server Core Edition
-
13 – Standard Server Core Edition
-
14 – Enterprise Server Core Edition
You can use this property in creating a WMI filter that causes a GPO to target only Windows server core servers.
Remote Management Using WinRM/WinRS
Finally, you can also manage Windows server core servers remotely using the Windows Remote Shell (WinRS) included in Windows Vista and the full installation of Windows Server 2008. WinRS uses Windows Remote Management (WinRM), which is Microsoft’s implementation of the WS-Management protocol developed by the Desktop Management Task Force (DMTF). WinRM was first included in Windows Server 2003 R2 and has been enhanced in Windows Vista and Windows Server 2008.
To use the Windows Remote Shell to manage a Windows server core server, log on to the Windows server core server you want to remotely manage and type WinRM quickconfig at the command prompt to create a WinRM listener on the machine:
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. 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.
Now on a different machine running either Windows Vista or the full installation of Windows Server 2008, type winrs –r:<server_name> <command>, where <server_name> is your Windows server core server and <command> is the command you want to execute on your remote server. Here’s an example of the Windows Remote Shell at work:
C:\Users\Administrator>winrs -r:DNSSRV "cscript C:\Windows\System32\slmgr.vbs -dli" Microsoft (R) Windows Script Host Version 5.7Copyright (C) Microsoft Corporation. All rights reserved. Name: Windows(TM) Server Windows Server 2008, ServerEnterpriseCore edition Description: Windows Operating System - Windows Server 2008, RETAIL channel Partial Product Key: XHKDRLicense Status: Licensed
You can also run WinRM quickconfig during unattended installation by configuring the appropriate answer file setting for this service.
EAN: 2147483647
Pages: 138