Manually configure the server using command-line tools.
Automate the configuration using answer files during the actual installation.
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.
Set static TCP/IP v4 details.
Set keyboard and international settings.
Set the default scripting engine.
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.
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.
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.
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.
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.
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.
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.
Netsh interface ipv4 del winsserver name="2"
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.
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.
The secure channel from SAVTSTCORE01 to the domain VIRT.
is with the machine \\SAVTSTDC01.VIRT.SAVILLTECH.NET.
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.
Command line options are saved.
If you've enabled cscript as the default engine, you don't need to type it every time.
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.
There is also more information available via the –dli switch or the –dlv switch to get detailed info.
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.
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.
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.
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."
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.
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.
Figure 14-8 Using Group Policy to configure the firewall is a good option for larger deployments.
Open a new MMC instance (Start, Run, MMC).
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.
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.
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.
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.
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.
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.
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.
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.
stall a server role or optional feature.
DCPromo to install or uninstall Active Directory.
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.
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.
This output is long, so you need to scroll to see everything.
In the short term, the only installations you do will likely be agents and antivirus, but who knows what the future will bring?