Server Core Configuration
Now that Server Core is installed, first you need to configure it. Without the normal graphical elements, you don't have the nice Initial Configuration Tasks (ICT) interface that you would normally use to configure Windows Server 2008 server, so you have two options:
- Manually configure the server using command-line tools.
- Automate the configuration using answer files during the actual installation.
The second option is the way to go for any sizable deployment. One of the big pushes of the latest operating system has been zero-touch deployments, so you can automate the install and configuration of all the main components. However, this does take up-front effort and planning but is definitely an option. Other areas of the book talk about unattended installations, so for now concentrate on the manual configuration of the server. However, if you go the unattended route, Server Core uses the same unattended syntax as Windows Vista and a normal server. Use the Windows System Image Manager from the Windows Automated Installation Kit (WAIK) to help create the unattended eXtensible Markup Language (XML) answer file. There are some advantages to using the unattended XML, however, because some items are quite hard to configure in Server Core. For example, configuring screen resolution is quite complex without the Display Control Panel applet! The display options are part of the Microsoft-Windows-Shell-Setup component, and a sample code extract for an unattend.xml is shown here:
<settings pass="oobeSystem"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Display> <HorizontalResolution>1280</HorizontalResolution> <VerticalResolution>1024</VerticalResolution> <ColorDepth>16</ColorDepth> </Display> </component> </settings>"
If you examine the content of the install.wim file for Windows Server 2008, you see that a CORE version exists for each operating system. If you are using Windows Deployment Services (WDS) or any other XML installation, select the CORE post-fixed version, as shown in Figure 14-4.
Figure 14-4 The core versions of the main Server 2008 editions.
Let's look at the main things you normally do when you configure a new server:
- Set the administrator password.
- Set the machine name.
- Set static TCP/IP v4 details.
- Set the time zone.
- Join a domain.
- Set keyboard and international settings.
- Set the default scripting engine.
- Activate the server.
- Install patches.
- Configure the firewall.
- Configure the server pagefile.
- Enable Remote Desktop.
- Configure hardware.
- Add roles and features.
You would normally do all this via GUI interfaces. For example, you would use Network and Sharing Center to configure IP settings, Windows Update for patches, and so on, but none of these interfaces are available. You can still set all of these things using the command line and some Server Core–specific commands. However, most of these are standard commands and can be used on normal installations for configuration and for scripted communication.
Setting the Administrator Password
The Winlogon and security subsystem in Core is the same as in a standard installation of Windows Server 2008, so to change the password of the logged-on account, just press Ctrl+Alt+Delete as you would normally do. Select the Change a Password link from the menu, and the normal change password dialog displays.
Passwords can also be changed via the net user command as on any other Windows installation by passing the username and the new password or passing the wildcard (*) character to be prompted for the new password, as shown in Figure 14-5. To change a domain account password, add the /domain switch.
Figure 14-5 The net user command is an easy way to manage local account passwords.
Setting the Server Name
In the first screen, you viewed the server name using the hostname command. However, to change the server name, use the netdom command with the renamecomputer switch. To avoid having to type in the long default computer name, use the %computername% environment variable and then pass the new server name with the /NewName switch:
C:\Windows\System32>netdom renamecomputer %computername% /New Name:savtstcore01 This operation will rename the computer WIN-DJM3YTGC5KZ to savtstcore01. Certain services, such as the Certificate Authority, rely on a fixed machine name. If any services of this type are running on WIN-DJM3YTGC5KZ, then a computer name change would have an adverse impact. Do you want to proceed (Y or N)? y The computer needs to be restarted in order to complete the operation. The command completed successfully.
This change does not take immediate effect; a reboot is required by selecting the Restart option from the Ctrl+Alt+Del screen shutdown options as shown in Figure 14-6 or by using the shutdown /r /t 0 command. When the reboot is complete, the server has taken the new name, which you can verify by rerunning the hostname command.
Figure 14-6 Although you don't have a Start menu, access shutdown options via the Ctrl+Alt+Del menu.
Setting Static TCP/IP v4 Information
By default, the new installation has been dynamically allocated an IP address. However, in most cases a server needs static IPv4 information, which can be seen with the ipconfig /all command. It will show DHCP Enabled set to Yes.
Because you can't use the normal Network interface to set the IP properties, instead use the netsh command. However, before you can set the IP properties, check which interface you are configuring. By default your server has two network interfaces: the "real physical" interface and a second IntraSite Automatic Tunnel Addressing Protocol (ISATAP) tunneling interface, which sends IPv6 packets over an IPv4 network by encapsulating the IPv6 packet in the IPv4 header. You need to configure the physical connection and not the ISATAP one, so list your interfaces to identify the index of the physical adapter.
C:\Users\administrator>netsh interface ipv4 show interfaces Idx Met MTU State Name --- --- ----- ----------- ------------------- 2 10 1500 connected Local Area Connection 1 50 4294967295 connected Loopback Pseudo-Interface 1
When the adapter is identified, which in this case is index 2, the IP details can be set. They most likely consist of an IP address, a subnet mask, a gateway, and one, possibly two, DNS servers.
To set the IP address, subnet mask, and gateway, run the following and change the information for your environment:
C:\Users\administrator>netsh interface ipv4 set address name="2" source=static address=192.168.1.232 mask=255.255.255.0 gateway=192.168.1.1
You can now add the DNS servers. The primary DNS server gets an index of 1, the secondary DNS server gets an index of 2.
C:\Users\administrator>netsh interface ipv4 add dnsserver name="2" address=192.168.1.230 index=1 C:\Users\administrator>netsh interface ipv4 add dnsserver name="2" address=192.168.1.10 index=2
If you need to configure primary and secondary Windows Internet Name Service (WINS) servers, use the same syntax as for adding DNS servers but use winsserver instead of dnsserver. The first index would be the primary WINS server and the second index the secondary WINS server.
If you now examine the IP information with ipconfig/all, the configured settings are displayed, as shown in the following example:
C:\Users\administrator>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : savtstcore01 Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . . : Description . . . . . . . . . . . : Intel 21140-Based PCI Fast Ethernet Adapter (Emulated) Physical Address. . . . . . . . . : 00-03-FF-0E-0D-F9 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::c49a:b729:8c8b:471e%2(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.1.232(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 192.168.1.230 192.168.1.10 NetBIOS over Tcpip. . . . . . . . : Enabled
If you need to remove a DNS server, or more likely a WINS server, after you finally get it killed off, use the del keyword instead of add. For example:
Netsh interface ipv4 del winsserver name="2" address=192.168.1.10
Setting the Time Zone
The date and time are easy to set using the date and time command lines, but using a command-line method to set the time zone is trickier. There are Registry areas for the time zone. However it's not necessary to use the Registry. Remember that Control Panel is unavailable in Server Core except for two applets. The Date and Time Control Panel applet is one of them; start it via the following command:
control timedate.cpl
After loading the applet, perform the normal date/time and time zone configurations, as shown in Figure 14-7. Note that in a domain environment, the time synchronizes; however, you might need to set the time zone.
Figure 14-7 At last, a graphical way to configure something.
Joining a Domain
It is most likely your servers are part of a domain, and unless the server was preprovisioned during deployment or used an answer file, you need to configure your server to join a domain. After the IP configuration is configured with the correct DNS servers, the computer name is set, and the time configuration is correct, you can join the domain.
To join a domain, use the same command that you used to rename the computer: netdom. Full help can be seen by running netdom join /?, which gives information on specifying a specific organizational unit (OU) to place the computer into. However, at the most basic level, pass the domain you want to join, the account to use to perform the join, and its password:
C:\>netdom join %computername% /domain:virt.savilltech.net /userd:administrator /passwordd:* Type the password associated with the domain user: ******* The computer needs to be restarted in order to complete the operation. The command completed successfully.
Replace the domain name with your domain, and then restart the server. After the reboot, you can log on as a domain user, which confirms the domain join operation worked successfully. You can also verify your connectivity to the domain using the netdom /verify command as in the following example:
C:\Users\administrator.VIRT>netdom verify %computername% /domain:virt.savilltech.net The secure channel from SAVTSTCORE01 to the domain VIRT. SAVILLTECH.NET has been verified. The connection is with the machine \\SAVTSTDC01.VIRT.SAVILLTECH.NET. The command completed successfully.
Configuring International Settings
The second Control Panel applet available in Server Core is the Regional and Language Options applet. It enables the configuration of the keyboard layouts, languages, and location. To launch the applet, run the following command and configure as a normal installation:
Control intl.cpl
Setting the Default Scripting Engine
With Server Core, you do a lot via various scripts executed by the Windows Scripting Host, which has a GUI and a command-line engine. By default the GUI engine is the preferred tool, which goes against the idea of managing Server Core from the command line and requires you to remember to put cscript at the start of your scripts to process the script using the command-line interpreter.
To change the Windows Scripting Host to use the command-line interpreter by default, use the following command:
C:\Windows>cscript //H:CScript //NOLOGO //s Command line options are saved. The default script host is now set to "cscript.exe".
If you've enabled cscript as the default engine, you don't need to type it every time.
Activating the Server
Server Core includes the Slmgr.vbs script, which when passed with the –ato switch, performs an automated activation of the operating system. Slmgr.vbs is not a Server Core feature; it is present in Windows Vista and full Windows Server 2008 deployments and is the main license manager for the Vista/2008 products.
Because Server Core has no taskbar or system tray, you do not receive any prompts to activate the server, so remember to do so shortly after the installation of Server Core.
Before you activate, check your status to see how far into your initial 30-day grace period you are by using the –xpr switch as shown here:
C:\Windows\System32>cscript slmgr.vbs -xpr Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Initial grace period ends 10/4/2007 2:48:10 PM
There is also more information available via the –dli switch or the –dlv switch to get detailed info.
C:\Windows\System32>cscript slmgr.vbs -dli Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Name: Windows(TM) Server code name "Longhorn", ServerEnterpriseCore edition Description: Windows Operating System - Server code name "Longhorn", RETAIL channel Partial Product Key: 2T9PJ License Status: Initial grace period Time remaining: 42000 minute(s) (29 day(s))
If you have a normal license key or Multiple Activation Key (MAK) that activates with Microsoft, you can go ahead and just activate. However, if you have a local Key Management Service (KMS), tell the activation to use it via the –skms <KMS server> switch. If you need to clear the configured KMS server, use the –ckms switch. If you are using an enterprise license key, use the –ipk <key> switch.
To activate, use the –ato switch as previously mentioned. Rerun the display of license information to see the status is now licensed with no time remaining.
C:\Windows\System32>cscript slmgr.vbs -ato Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Activating Windows(TM) Server code name "Longhorn", ServerEnterpriseCore edition (f00d81ce-df2c-47cb-a359-36d652296e56) ... Product activated successfully. C:\Windows\System32>cscript slmgr.vbs -dli Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Name: Windows(TM) Server code name "Longhorn", ServerEnterpriseCore edition Description: Windows Operating System - Server code name "Longhorn", RETAIL channel Partial Product Key: 2T9PJ License Status: Licensed
Installing Patches and Configuring Auto-Update
You can use various methods to patch Server Core. You can push patches with Group Policy or System Center Configuration Manager or any other deployment-type product. You can use Windows Update, which is disabled by default. (You can confirm that with the /au /v switches with scregedit.wsf.) To enable Windows Update to perform the normal 3 a.m. checks, run the following commands. The scregedit.wsf script is Server Core–specific and was written to help perform the functions that are otherwise difficult to do from the command line. The script is installed automatically on all Server Core installations.
C:\Windows\System32>cscript scregedit.wsf /au 4 Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Registry has been updated. C:\Windows\System32>net stop wuauserv The Windows Update service is stopping. The Windows Update service was stopped successfully. C:\Windows\System32>net start wuauserv The Windows Update service is starting. The Windows Update service was started successfully.
You can force an update pass to run using the following command:
C:\Windows\System32>wuauclt /detectnow
You can't configure options to download patches and prompt for installation. You can either enable automatic download and application of patches or have automatic update turned off: There is no in-between configuration. You can always check the state of patch installations via the wmic qfe list command.
You can manually install patches using the wusa command, as in the following example:
wusa <patch name>.msu /quiet
Remember the patches all have applicability rules, so they won't install if the patch does not apply. If you want to check whether a patch applies, run the command without the /quiet switch. If you are prompted to install, it means the patch applies; if you are not prompted, it means the patch does not apply to Server Core and has been ignored. You learn more detail about patching in Chapter 17, "Managing and Maintaining Windows Server 2008."
Configuring the Pagefile
By default, the pagefile is set as managed by the system. This behavior can be modified by disabling the automatic pagefile management and manually configuring a specific pagefile size. For example, the following disables the automatic pagefile management and sets the pagefile to 1GB minimum, 2GB maximum. In general, the default Windows settings for the pagefile should not be changed—do so only if given specific guidance by an expert or vendor of an application being installed. Notice the code in the following listing is using the Windows Management Instrumentation Command-Line (WMIC) environment, which opens up a lot of functionality. Some of the other commands you performed could have been done with the WMIC. After running the commands in this listing, you must restart the server for the changes to take effect.
C:\Windows\System32>wmic computersystem set AutomaticManagedPagefile=false Updating property(s) of '\\SAVTSTCORE01\ROOT\CIMV2:Win32_ ComputerSystem.Name="SA VTSTCORE01"' Property(s) update successful. C:\Windows\System32>wmic pagefileset where name="C:\\ pagefile.sys" set InitialSize=1000,MaximumSize=2000 Updating property(s) of '\\SAVTSTCORE01\ROOT\CIMV2:Win32_ PageFileSetting.Name="C :\\pagefile.sys"' Property(s) update successful.
Configuring the Firewall
On a new Server Core installation, the firewall is enabled by default and blocking almost everything. You can turn off the firewall by using the following command, which opens up the ports and allows Remote Desktop, SNMP, and so forth. You can enable the firewall again by changing disable to enable.
Netsh firewall set opmode disable
You can configure the firewall elements using the netsh command and its various components. For example, to enable the Remote Desktop, use the following command:
C:\Windows\System32>netsh firewall set service type=remotedesktop mode=enable
There is an easier way, however. The Windows Firewall MMC snap-in can connect to a remote machine, so let's try that approach as opposed to working out the hundreds of possible netsh commands. If you are configuring many servers, however, it would be worth creating a script with the netsh commands, or configuring the firewall using Group Policy. If you want to use Group Policy, the firewall is available as part of Computer Configuration, Windows Settings, Security Settings, Windows Firewall with Advanced Security. Right-click Inbound Rules (see Figure 14-8) and select a new rule, and you can use the predefined Remote Administration and Remote Desktop rules. It might not be practical to place the Server Core machines in their own OU for the application of the Group Policy, so you can use a WMI filter to check the OperatingSystemSKU of the server for the values 12, 13, and 14, which correspond to the Datacenter, Standard, and Enterprise Server Core installations, respectively. A sample WMI filter follows:
select * from Win32_OperatingSystem where OperatingSystemSKU=12 or OperatingSystemSKU=13 or OperatingSystemSKU=14
Figure 14-8 Using Group Policy to configure the firewall is a good option for larger deployments.
Before you try this, you get an error when you launch the remote firewall snap-in because the firewall you are trying to configure blocks remote management by default. So, you need one more netsh command to enable the remote management capability:
C:\Windows\System32>netsh firewall set service type=remoteadmin mode=enable
Now let's manage remotely:
- Open a new MMC instance (Start, Run, MMC).
- From the File menu, select Add/Remove Snap-In.
- Select Windows Firewall with Advanced Security, and click the Add button (see Figure 14-9).
Figure 14-9 Select Windows Firewall with Advanced Security.
- You are prompted to indicate whether the computer is the local computer or another computer. Check Another Computer (see Figure 14-10), specify the name of your Server Core computer, and click Finish.
Figure 14-10 Check Another Computer.
- Click OK to close the Add or Remove Snap-Ins dialog box.
Now configure the firewall remotely and enable exceptions as required.
Enabling Remote Desktop
Server Core contains the Remote Desktop component, which can be a useful way to manage a Server Core environment. But due to its mainly command prompt–based interface nature, there are less resource-greedy ways of managing a Server Core install.
To check the current state of Remote Desktop, use the scregedit.wsf script with the /ar /v switches, as shown in the following listing. In this case, by default, the Remote Desktop is disabled because the Deny Terminal Server Connections setting is set to true. You must be in the Windows\System32 folder to run the script:
C:\Windows\System32>cscript 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. 1
To enable Remote Desktop, use the /ar 0 switch:
C:\Windows\System32>cscript scregedit.wsf /ar 0 Microsoft (R) Windows Script Host Version 5.7 Copyright (C) Microsoft Corporation. All rights reserved. Registry has been updated. C:\Windows\System32>cscript 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
Additionally, by default, only connections from the newest Remote Desktop Protocol (RDP) clients that support the Credential Security Service Provider (CredSSP) are accepted, which allows the user's current credentials to be automatically passed to the target server. However, you can change this behavior using the /CS 0 switch with scregedit.wsf.
Configuring Hardware
Some things, such as screen resolution, are difficult to configure from Server Core. One of the few GUI tools provided is the Registry Editor, which means you can perform configurations; it's just a bit ugly. Normally, you are advised to use the Registry Editor only as a last resort, but for some things in Server Core it's your only option. Using the Registry Editor, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\<GUID of graphics card>\0000 key. Modify the DefaultSettings.XResolution (see Figure 14-11) and DefaultSettings.YResolution values to the desired values. Just make sure they are right.
Figure 14-11 Setting the screen resolution for the system.
If you want to modify screen saver values, for example, do it in the Registry as well. By default, the screen saver kicks in after 10 minutes and uses the logon screen saver (logon.scr), requiring a password when the screen saver is deactivated. To modify this, use the Registry Editor again and move to the HKEY_CURRENT_USER\Control Panel\Desktop key. The following values can be changed:
- ScreenSaveActive. 1 means screen saver is turned on, 0 disables.
- ScreenSaverIsSecure. 1 means password is required, 0 no password needed.
- ScreenSaveTimeOut. Time in seconds of inactivity before screensaver starts.
- SCRNSAVE.EXE. The name of the screen saver. Logon.scr or scrnsave.scr for the blank screen saver.
You can also specify a background wallpaper by creating a string value named WallPaper under the same key with the full name and path of the image to use as the background.
In terms of adding hardware, if you need to install drivers, you are not prompted to install a driver for new hardware as in a normal Windows Server installation. Instead you need to manually install the driver and then, depending on the hardware, reboot the server for the new driver to be used with the hardware. Copy the driver files to a location on the server and then run the following command to load the driver:
Pnputil –i –a <driver>.inf
You can list all drivers on the system via the sc query type= driver command (note the space between type= and driver). When you have the service name of the driver, uninstall with the sc delete <service_name> command.
Adding Roles and Features
So far everything you have done configures the server. So far it does not do anything; it's not running any roles or features that are the cornerstone of Windows Server 2008.
You don't have access to the normal Server Manager interface to add roles and features, and all the features, except ADDS, are added via the Ocsetup command. Ocsetup is a case-sensitive command and is part of all Windows Server 2008 installations. Active Directory installation is installed via the dcpromo command, which installs the binaries and configures things via an unattended answer file. You can't use DCPROMO GUI. You have to use an unattended answer file or command-line switches. See the Active Directory chapters for examples of unattended Active Directory installations.
To uninstall roles and features, use the same command but add /uninstall at the end. The exception again is ADDS, which once again uses DCPROMO.
Tables 14-2 and 14-3 list the names of the components and what they correspond to in features and roles. However, you can run oclist for a complete list; oclist is a Server Core–specific command. New roles and features will be added to Server Core in the future. For example, WDS support is expected in the Windows Server 2008 R2 timeframe.
Table 14-2. Server Roles and Ocsetup Names
Server Role |
Ocsetup Name |
Active Directory Lightweight Directory Services (ADAM) |
DirectoryServices-ADAM-ServerCore |
DHCP |
DHCPServerCore |
DNS |
DNS-Server-Core-Role |
Distributed File System Service |
DFSN-Server |
Distributed File System Replication (DFSR) |
DFSR-Infrastructure-ServerEdition |
File Services |
File-Server-Core-Role |
File Replication Service (FRS) |
FRS-Infrastructure |
IIS (no ASP.NET) |
IIS-WebServerRole (plus subcomponents visible via oxlist) |
Network File System (NFS) |
ServerForNFS-Base |
Media Server |
MediaServer |
Hyper-V |
Microsoft-Hyper-V |
Table 14-3. Server Features and Ocsetup Names
Server Feature |
Ocsetup Name |
Backup |
WindowsServerBackup |
BitLocker Drive Encryption |
BitLocker |
BitLocker Remote Admin Tool |
BitLocker-RemoteAdminTool |
Failover Cluster |
FailoverCluster-Core |
Multipath IO |
Microsoft-Windows-MultipathIO |
NFS Client |
ClientForNFS-Base |
Network Load Balancing |
NetworkLoadBalancingHeadlessServer |
Quality of Service |
QWAVE |
Removable Storage Management |
Microsoft-Windows-RemovableStorageManagementCore |
SNMP |
SNMP-SC |
Subsystem for UNIX-bases applications |
SUACore |
Telnet Client |
TelnetClient |
Windows Activation Service (WAS) |
WAS-WindowsActivationService |
WINS |
WINS-SC |
By default, if you execute Ocsetup with a package to install, the command prompt returns instantly while the installation happens in the background, and you will not know when the install has completed. To work around this, run the Ocsetup command after a start /w to tell the command to execute and to wait for the execution to complete.
Let's install the DNS Server role, as shown in Figure 14-12. During the install, the TrustedInstaller process is activated and responsible for the actual installation.
Figure 14-12 Installing a role is a one-step process.
After you install the role, it is marked as installed in the Optional Component listing, as shown in the following:
C:\Users\administrator.VIRT>oclist Use the listed update names with Ocsetup.exe to install/unin- stall 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-ServerFounda- tion Installed:DNS-Server-Core-Role Not Installed:FailoverCluster-Core Not Installed:FRS-Infrastructure
In the DNS case, the service could be managed locally via DNSCMD, which is a standard part of the DNS role to facilitate command-line management, or more likely you can run the DNS MMC snap-in on a Vista/2008 box and remotely connect and manage the DNS service on the core installation. For example, in Figure 14-13, the root of the DNS navigation node is right-clicked and the Server Core installation is added, which you can now manage with the GUI remotely.
Figure 14-13 In reality, you remotely control most of the server core areas of functionality.
As with all the remote GUI tools, if you receive an Access Denied error, solve it by performing a net use to the machine before remotely connecting. The command establishes an authenticated session:
C:\Users\john>net use * \\savtstcore01.virt.savilltech.net\c$ /user:virt\administrator * Type the password for \\savtstcore01.virt.savilltech.net\c$: ***** Drive Z: is now connected to \\savtstcore01.virt.savilltech.net\c$. The command completed successfully.
A better way is to use cmdkey, which allows credentials to be set for various target systems:
C:\Users\john>cmdkey /add:savtstcore01.virt.savilltech.net /user:virt\administrator /pass:******** CMDKEY: Credential added successfully.
Installing Applications
For the Windows Server 2008 release, Server Core is designed to run in-the-box functions, that is, the supported server roles and features and not additional applications.
None of the major products are supported on Server Core; for example, Exchange, SharePoint, SQL, and so on. For additional applications, there is some planning for the future when managed code support is added to Server Core. However, there are limits to what can be added to Server Core; otherwise, it becomes a normal Windows installation.
Agents should be installable and supportable under Server Core, for example, backup agents, Microsoft Operations Manager (MOM), Systems Management Server (SMS) agents, and so on, which are managed via a remote administrative console function. You can install antivirus agents on Server Core installations and manage them remotely. For example, ForeFront runs on Server Core. Virtual machine additions can be installed and they run fine; in fact, they are recommended. The general rule of thumb is that agents have no shell or GUI dependencies and do not require managed code; if all these are true, the agent runs under Server Core.
To install additional software, execute the setup executables or manually install the MSI files using this command:
Msiexec /i <application>.msi
To check the installed applications, use the wmic command and the production function as shown in the following:
C:\Windows\System32>wmic wmic:root\cli>product AssignmentType Caption Description 1 Virtual Machine Additions Virtual Machine Additions
This output is long, so you need to scroll to see everything.
To uninstall an application, use the wmic command by checking the name of the application and then calling uninstall for it, for example:
C:\Windows\System32>wmic product get name /value Name=Virtual Machine Additions C:\Windows\System32>wmic product where name="Virtual Machine Additions" call uninstall
In the short term, the only installations you do will likely be agents and antivirus, but who knows what the future will bring?