The things that are better left unspoken

Monitoring Server Core from the command line

2008-05-08T14:05:05Z

A server running a Server Core installation of Windows Server 2008 could behave flaky from time to time. Monitoring it gives clues towards this behavior and/or provides insight in why it behaves flaky. I've taken a closer look at monitoring Server Core boxes from the command line and want to share my experiences with you on this matter today.

Task Manager

The Task Manager is a perfect utility to monitor your Server Core in a way that has been familiar since Windows 95. You can start it in any of three ways:

Press the Ctrl, Alt and Del keys at the same time and select Start Task Manager from the list.
Press the Ctrl, Alt and Esc keys at the same time
Type taskmgr.exe on the command prompt

It can be used to monitor:

Running applications and tasks
Processes
Services
Performance (CPU and RAM usage)
Networking
Logged on users

The Task Manager is perfect, but unfortunately it lacks on a couple of points:

It has no logging
It doesn't include disk space monitoring

This is on full installations of Windows Server where the Performance Monitor comes in.

Performance Monitor

The graphical version of the Performance Monitor is not part of Server Core. Fortunately there is a command line driven version available, which can be used to monitor your Server Core box from the command line. It's called logman.exe

Even though logman.exe is a command line tool it's a really impressive monitoring tool, since it can collect counter, trace, alert, configuration and API tracing collectors. It supports many functions of Performance Monitor from the command line. The two great things logman.exe lacks are the ability to draw graphs and to point-and-click your queries together.

Selecting counters

To select a counter to monitor using logman.exe you need to know the name of the counter to add. logman.exe however doesn't provide this functionality. Fortunately typeperf.exe does.

To find a performance counter to monitor type the following command: typeperf.exe /q This will display a list with (installed) counters without instances. To list the performance counters with their instances type: typeperf.exe /qx

The list of performance counters is extensive, but using the find command on the output might help narrowing down what you're looking for. For instance, when you're looking for performance counters related to disk, type the following command to display disk-related performance counters:

typeperf.exe -q | find "Disk"

Narrowing down my search criteria, by executing find commands consecutively on the -qx option for typeperf.exe, I finally found the disk-related performance counter instance I was after (\PhysicalDisk(0 C:)\Disk Transfers/sec) using the following command:

typeperf.exe -qx | find "PhysicalDisk" | find "Disk Transfers/sec"

Building the data collector

Now that I found the performance counter I was after I can build the data collector.
My intention is to have a csv file with transfers/sec for the last few days, collected every 5 seconds. Your needs may vary, but the process to build your data collector would be identical.

logman.exe create counter DiskTransfers -f csv -c "\PhysicalDisk(0 C:)\Disk Transfers/sec" -max 10 -si 5

Where:

DiskTransfers is the name of the data collector within logman.exe
-f csv specifies the file format of the log for the data collector
-max 10 specifies the maximum file size of the log file in MB
-si 5 specifies the sample interval in HH:mm:ss format

Viewing the data collector

Now that we created the data collector we can view the collector. When you start logman.exe without any command line switches it will output defined data collectors and their state. As you'll find out freshly created data collectors are not started automatically.

The properties for a data collector (besides whether it is actually doing anything) can be viewed using the query command line switch. To view the properties of my freshly created data collector (the first on my Server Core box) I used the following command:

logman.exe query DiskTransfers

Starting the data collector

What use is a data collector when it's sitting idle on your box? Let's start it up, so it starts collecting the stuff it is supposed to be collecting by using the following command:

logman.exe start DiskTransfers

Modifying the data collector (if need arises)

After you've created a data collector you can edit its properties by using the update command line switch. Deleting can be done using the delete switch. Both commands use the name of the data collector within logman.exe as their starting point for modification.

Using collected data

While working in black prompt windows might be enough to baffle your co-workers it won't impress your boss much. What will really impress him (or her) is showing you're on top of things by staring endlessly at nifty excel graphs you created within seconds.

In my case I pulled the DiskTransfer_000001.csv file from the C:\Perflogs\Admin folder of my Server Core box and worked some Microsoft Office Excel magic on it.

Other tools and products

Disk usage (du.exe)

One of the many useful free Windows SysInternals tools is Disk usage (du.exe), which is currently at version 1.3.1. This tool is capable of reporting disk space usage for the directory you specify. By default it recurses directories to show the total size of a directory and its subdirectories.

Using du.exe is as simple as downloading the zip file and unzip it to a location where your Server Core box can reach it. There are several ways to accomplish this. After you've copied it to the hard disk of your Server Core box you can use it in the following manner:

du.exe [[-v] [-l ] | [-n]] [-q] FileOrDirectoryPath

Where:

-l specifies the subdirectory depth of information
-n tells du.exe not to recurse folders (only information on current folder)
-q specifies not to print the banner
-v specifies to show information in intermediate directories

Examples:

du.exe -v -q C:\Perflogs

Note:
The first time you run the utility you need to agree with the End User License Agreement (EULA) before you can use this tool.

While this command will output its information to the prompt it can be told to output to a file. Scheduling the command then might prove useful to monitor disk usage and act proactively on disk usage trends.

Process Explorer

The built-in Task Manager has evolved over the past years. It now includes networking information for instance. Process Explorer is a free Windows SysInternals tool that offers even more realtime monitoring functionality. It can be used to search for thread handles and running DLLs and can explore individual processes: You can see events, files, devices, and registry keys being accessed.

If Process Explorer is one of your favorite tools you can trade in your Task Manager for Process Explorer in the following manner:

Download Process Explorer (1.6 MB) (currently at version 11.13)
Unpack the zip file and get the executable onto your Server Core box.
Open Process Explorer by typing procexp.exe
Click the button 'Agree' when presented with the End User License Agreement (EULA)
In the Process Explorer window open the Options menu
Select Replace Task Manager.

You can now start procexp.exe the same way you would start taskmgr as described at the beginning of this post.

Concluding

The Task Manager (taskmgr.exe) and the Performance Monitor are perfect tools to monitor a Windows installation locally, but unfortunately the latter is not part of Server Core. You can find another tool on your Server Core hard disk that's useful for monitoring though: logman.exe

Installing Windows Server 2008

2008-05-01T09:57:59Z

There are a couple of ways to install Windows Server 2008. When you're lucky enough to get your hands on a physical copy of a Windows Server 2008 DVD you can use that, but what if your target system doesn't have a DVD player? What if you want to install it in a different way? What if you wanted to save some time? Read on!

Installation methods

You can install Windows Server 2008 using the following media:

A physical DVD
A DVD image (an *.iso file)
A Bootable USB stick
Your TCP-IP enabled network

Using the physical DVD

Installing Windows Server 2008 using the Physical DVD is the most reliable, but also the hardest and slowest way to get the Operating System on your box.

It's the most reliable way when you have a pressed (instead of burned) DVD copy of Windows Server 2008 and you received the copy from a legitimate source, for instance your reseller or a MSDN, TechNet, Select or other subscription box. There's only a negligible chance a malicious person would have been able to modify the bits and bytes on the disc.

It's also the hardest way to get the Operating System on your boxes, since you won't have the ability to change the bits and bytes on the media (without getting it off the disc first) which is what you would want to be doing when you know your way around the Windows Automated Installation Kit (WAIK)

I don't recommend using this method when you need to install a lot of Windows Server 2008 machines. I think it's the slowest way to install dozens of servers. If you need to install these amounts of server I suggest you read along.

Using an image

There are multiple ways to get your hands on a Windows Server 2008 image. Microsoft offers a download of Windows Server 2008 in *.iso format with certain subscriptions, such as MSDN, TechNet and Volume License subscriptions. On the other hand you could also rip your Windows Server 2008 DVD to an image with Alex Feinman's ISOBurner. (I use and recommend this tool. Some people seem to prefer WinImage)

Microsoft also offers the bits for evaluation.
While this doesn't sound very appealing to IT Pros who have been around long, let me clarify: Microsoft no longer works with specific media types, bound to specific product key families. In the past you'd need OEM media to work with your OEM product key, VLK media with your VLK product key and trial media were only usable with trial keys. Now you can simply download the media and use any product key to activate it for the scenario the product key allows. (Some minor differences still exist)

An image file can be mounted (for instance with Daemon Tools lite) and burned to physical media.

Virtual deployments

Images are perfect for virtual deployments. You can use the free Virtual PC or Virtual Server products from Microsoft, Microsoft Hyper-V products, Citrix' XenServer products, VMWare Server and VMWare ESX products (among others) to make a virtual box on which you can mount the image file as a virtual DVD and install from there. Since the host machine can read the image from the hard disk this will significantly bring down install times in virtual deployments.

Physical deployments

Having an ISO file of Windows Server 2008 instead of having a physical copy could actually save you a lot of work if you need to deploy dozens of boxes. Using the Windows Automated Installation Kit (WAIK) you can edit the unattend.xml file on the DVD to reflect the input you either need to input manually at every installation. Information you could set in the unattend.xml file include (but are not limited to):

Administrator password
Domain Name or Workgroup Name to join
Computer name
Drivers
Installed server roles and features

A complete list is available. After making your own unattend.xml you can easily copy your version over the version in the image. You can then choose to either burn the image or use it for other purposes, like virtual installations.

Hardware redirection

Another way to utilize an image file is to use it with hardware redirection. Dell Remote Access Controller (DRAC), HP Integrated Lights-Out (iLO) and IBM's family of Remote Supervisor Adapters (RSA) are perfect examples. They allow you to connect an image file to the server to function as a virtual CD or DVD drive. The server can then boot from the image file stored locally on your workstation or available remotely on a central resource. You can also insert the DVD disc into your workstation’s optical drive and tell it to use your drive by drive letter. This is one of the preferred ways to install Windows Server 2008 on blade systems without DVD drives.

Using a bootable USB device

If you really need speed to install a couple of Windows Server 2008 boxes I recommend placing the installation files on a high-speed USB Stick.

Hard drives are usually connected to one Host device and USB channels are connected to another host device chip on your motherboard. Installing from an USB device therefor won't hog the host devices for your hard drives (like when using an image) and won't lag like a normal DVD player would do while spinning up and spinning down. When you choose to use an USB flash drive (called an USB stick around here) instead of an USB hard disk (slower) you can achieve lightning speeds. To make your bootable USB device, simply type the following commands on a system with the image mounted or physical DVD copy in the drive and the USB device plugged in:

diskpart.exe

DISKPART> list disk

     Select the USB device from the list and substitute the disk number below
     when necessary

DISKPART> select disk 1
DISKPART> clean
DISKPART> create partition primary
DISKPART> select partition 1
DISKPART> active
DISKPART> format fs=fat32
DISKPART> assign
DISKPART> exit

xcopy X:\*.* /s/e/f Y:\

     where X:\ is your mounted image or physical DVD and Y:\ is your USB
     device

Now all you need to do is plug the device into your target box' USB slot and boot it.
(The target system will need to have USB slots and be able to boot from USB devices)

Using the network

There are a couple of ways to install Windows Server 2008 using the plumbing of your internal TCP-IP infrastructure.

Using Windows Deployment Services

Windows Deployment Services is the successor to Remote Installation Services. (RIS)
It was introduced with Windows Server 2003 Service Pack 2. Windows Deployment Services in Windows Server 2008 in contrast to Windows Deployment Services in Windows Server 2003 knows how to multicast, which is a pretty neat feature, which in my opinion makes using Ghost, TrueImage and other imaging solutions obsolete.

The only drawback to using Windows Deployment Services (WDS) is you need an Active Directory environment. While this sounds unlikely even in 2008 you might find networks without Active Directory.

Using the Microsoft Deployment Toolkit

On top of using the Windows Automated Installation Kit (WAIK) and Windows Deployment Services you can use a Solution Accelerator for further guidance. Microsoft offered the Business Desktop Deployment Solution Accelerator (BDD) for clients and is now offering the Microsoft Deployment Toolkit 2008 as a sort of umbrella over the existing deployment tools for Windows Vista with Service Pack 1 and Windows Server 2008. (More information on centrally deploying Windows Vista can be found here)

When used in conjunction with Systems Management Server (SMS Server) or System Center Configuration Manager (SCCM) you can achieve deployments without touching client machines, (zero touch) while preserving client settings and user experience.

Using 3rd party solutions

You can use 3rd party imaging solutions to install Windows Server 2008 over the network. Symantec Ghost for instance offers the ability to image Windows installations, but it doesn't need a Directory solution. It helps when you have a DHCP server though. Using a 3rd party solution might require you to purchase licenses, which might prove costly.

Concluding

This page shows how to install Windows Server 2008 on almost every imaginary box. Not having a DVD player and not having USB ports is no longer an excuse not to install it on a box that meets the minimum requirements.

I've showed you how to do it. I'll finish up with a nice table when to use a specific method:

Installation method	Use when:
Physical DVD	Installing one or two boxes, nothing too fancy...
Image file	Installing virtual servers Installing blade servers Transition and Alteration of media
USB device	Installing virtual servers or installing multiple servers fast Installing on servers without DVD drives
TCP-IP network (WDS)	Installing loads of servers ( > 10) in an Active Directory
TCP-IP network (Ghost)	Installing loads of servers ( > 10) in any environment

Remotely managing your Server Core using RSAT

2008-04-27T15:53:32Z

A little while ago I showed you how to perform some of the common management tasks on your Server Core installation using the Microsoft Management Console Snap-Ins, available through Computer Management (compmgmt.msc). Last week I showed you how to install Server Roles and Features on top of your Server Core installation.

This time I want to take the opportunity to show you around in the recently released Remote Server Administration Tools (RSAT) which allow you to manage the roles you can install on your Server Core installation of Windows Server 2008.

Installing the Remote Server Administration Tools (RSAT)
Displaying Administrative Tools
Using the Remote Server Administration Tools (RSAT)
Concluding

Installing RSAT

In order to use the Remote Server Administration Tools (RSAT) you need to download the standalone setup package from the Microsoft Download servers, install the update package and after installation use the Programs and Feature control panel applet to actually install the parts of the Remote Server Administration Tools (RSAT) you'd wish to use.

Fulfilling system requirements

In order to run the Remote Server Administration Tools (RSAT) for Windows Vista you'll need a box with Windows Vista Business, Windows Vista Enterprise or Windows Vista Ultimate installed with Service Pack 1 in one of the languages mentioned below.

Downloading the standalone setup package

While the Remote Server Administration Tools (RSAT) are available in English since March 24th 2008 only a few days ago Microsoft released the RSAT in the following languages:

Language	Code	Package download X86	Package download X64
Chinese - Simplified	zh-CN	Chinese - China	Chinese - China
Chinese - Hong-Kong	zh-HK	Chinese - Hong Kong SAR	Chinese - Hong Kong SAR
Chinese - Traditional	zh-TW	Chinese - Taiwan	Chinese - Taiwan
Czech	cs-CZ	Czech - Czech Republic	Czech - Czech Republic
Dutch	nl-NL	Dutch - Netherlands	Dutch - Netherlands
French	fr-FR	French - France	French - France
German	de-DE	German - Germany	German - Germany
Hungarian	hu-HU	Hungarian - Hungary	Hungarian - Hungary
Italian	it-IT	Italian - Italy	Italian - Italy
Japanese	ja-JP	Japanese - Japan	Japanese - Japan
Korean	ko-KR	Korean - Korea	Korean - Korea
Polish	pl-PL	Polish - Poland	Polish - Poland
Portuguese (Brazil)	pt-BR	Portuguese - Brazil	Portuguese - Brazil
Portuguese (Portugal)	pt-PT	Portuguese - Portugal	Portuguese - Portugal
Russian	ru-RU	Russian - Russia	Russian - Russia
Spanish	es-ES	Spanish - Spain	Spanish - Spain
Swedish	sv-SE	Swedish - Sweden	Swedish - Sweden
Turkish	tr-TR	Turkish - Turkey	Turkish - Turkey

Like a couple of persons already observed in the TechNet forums: Only 18 of the 36 languages are here. Is Microsoft using it's wave method for distribution again?

Installing the package

Since you're a server administrator (what else would you need the Remote Server Administration Tools for) I won't bore you with how to double click the standalone setup package. (*.msu file) You all know how to download stuff, relocate it, run it and get through the UAC messages, right? If not, just read this Microsoft Knowledge Base article...

Selecting RSAT features

Once you've installed the package you can begin selecting features from the Remote Server Administration Tools using the Programs and Feature control panel applet. Simply:

Go to the Control Panel and select Programs and Features or begin typing Progra... in the search field of the Start Menu
Select Turn Windows features on or off in the taskpane.
Press Continue when you have User Account Control (UAC) enabled
Scroll down to Remote Server Administration Tools and select the features corresponding to your remote management wishes:

Selecting Applicable Tools

Server Core offers only a subset of the Roles and Features you can install on a Full Installation of Windows Server 2008. The interesting features in the context of Server Core installations of Windows Server 2008 are:

Bitlocker Drive Encryption Tools
Failover Clustering Tools
Group Policy Management Tools
Network Load Balancing Tools
Active Directory Domain Services Tools
- Active Directory Domain Controller Tools
Active Directory Lightweight Directory Services Tools
DHCP Server Tools
DNS Server Tools
File Services Tools
- Distributed File System Tools
- Share and Storage Management Tools

The other tools in the collection of Remote Server Administration Tools (RSAT) do not apply to Server Core installations of Windows Server 2008. When paying attention you might have already seen some management tools are missing. Kurt Roggen compiled a comprehensive list.

Displaying Administrative Tools

By default a Windows Vista box will not display the Administrative Tools in the Start Menu. When you're comfortable with the Administrative Tools folder being accessible through the Control Panel and the Search field of the Start Menu just use those.

To display the Administrative Tools in the All Programs list and/or on the Start Menu follow the steps below:

Right-click on the Pearl (Start button) and select Properties from the context menu.
On the Start Menu tab click the button labeled 'Customize' next to the Start Menu (This menu style gives you easy access to your folders, favorite programs, and search.) radio button.
scroll all the way down in the list.
Under the System Administrative Tools header select one of the two other options:
- Display on the All Programs menu
- Display on the All Programs menu and the Start menu
Press OK to close the Customize Start Menu window
Press OK to close the Taskbar and Start Menu Properties window

Using RSAT

Now that we've managed to install the Remote Server Administration Tools package on our Windows Vista management workstation and made the Administrative Tools folder visible where we can reach it with as little as three mouse-clicks, let's dive into the tools I've been using the most in my Server Core environments:

Active Directory Domain Services Tools

The Active Directory Domain Services tools in the Role Administration Tools folder apply to the Active Directory Domain Services Role. It consist of two tools. Only the Active Directory Domain Controller Tools are of interest for a Server Core Domain Controller. Once installed you should find these tools in the Administrative Tools folder of your Windows Vista box:

Active Directory Domains and Trusts (domain.msc)
Active Directory Sites and Services (dssite.msc)
Active Directory Users and Computers (dsa.msc)
ADSI Edit (adsiedit.msc)

These tools work largely as you would expect them to on Windows XP to administer a Windows Server 2003 environment. (You can even use the tools to administer a Windows Server 2003 Active Directory environment!) There are a few exceptions though:

No Exchange Server Management integration
- Exchange Server 2003: workaround available
- Exchange Server 2007: install the Exchange Management Console
No Terminal Services integration
(by default, workaround available)
No Windows Deployment Services integration
(by default, workaround available)
No Attribute Editor when managing Windows Server 2003 environment
(by default, workaround available)

Group Policy Management Tools

As you may recall installation of Service Pack 1 for Windows Vista uninstalls the Group Policy Management Console (gpmc.msc). This would have been inexcusable if the Remote Server Administration Tools (RSAT) wouldn't provide a better tool. In fact: The Group Policy Management Tools in the Feature Administration Tools folder for the Remote Server Administration Tools (RSAT) provide the successor to our beloved Group Policy Management Console: Group Policy Management (gpmc.msc)

Although this tool's MMC Snap-In name resembles the Group Policy Management Console it is greatly enhanced with the integration of:

The Group Policy Management Tools are a good companion to the Active Directory Domain Services Tools above and can be used in Active Directory environments.

DNS Server Tools

When you install the DNS Server Tools from the Role Administration Tools section of the Remote Server Administration Tools (RSAT) you find a new shortcut in your Administrative Tools folder called DNS, which points to dnsmgmt.msc. With this tool you can remotely manage your Server Core DNS Server to your heart's content.

Even though the Remote Management Console isn't all that different to the Management Console in the adminpak.msi for Windows Server 2003 there is one major difference between the DNS Server in Windows Server 2003 and the DNS Server in Windows Server 2008: Full IPv6 integration. The Cable Guy has more information.

DHCP Server Tools

The DHCP Server Tool, called DHCP (dhcpmgmt.msc) also received a IPv6 revamp and is now fully ready to serve both IPv4 and IPv6 addresses to clients asking for them. The tool is actually divided into two different DHCP servers you can run (and stop) independently of each other, create and reconcile scopes independently on and can define classes on independently. (Authorization is still handled on the server level though) 2 DHCP servers for the price of own!

Tip:
When this tool doesn't automatically work in your environment be sure to set the DHCP Server Service to start automatically on your Server Core box. It doesn't do this by default. Use the Services MMC Snap-In remotely (more info here) or type the following commands on the console of your Server Core box

sc \\localhost config DHCPServer start= auto
sc start DHCPServer

File Services Tools

The File Services Tools folder inside the Remote Server Administration Tools (RSAT) contains a lot of interesting tools. When you add the Distributed File System Tools and Share and Storage Management Tools you receive the following new shortcuts in your Administrative Tools folder:

DFS Management (dfsmgmt.msc)
Share and Storage Manager (storagemgmt.msc)

The third tool that's listed in the Remote Server Administration Tools (RSAT) regarding File Services is the File Server Resource Manager. Since you can't install the File Server Resource Manager on a Server Core box, this tool cannot be pointed towards a Server Core file server and is therefor useless for managing Server Core boxes.

Share and storage management

The Share and Storage Management MMC Snap-In (storagemgmt.msc) is tool that is only supported to remotely manage Windows Server 2008 and above (can't be used to manage Vista though) and it provides an overview of all the shares and volumes on the server. The Share and Storage Management MMC Snap-In (storagemgmt.msc) provides much more information than the Shared Folders MMC Snap-In inside Computer Management (compmgmt.msc) does and can be seen as its successor.

It's almost a shame this tool is much harder to get working than the Shared Folders Snap-In. This is because of the Volume Management features which requires the Virtual Disk Service (VDS) to be properly configured and some firewall exceptions to be enabled on both the server and your Windows Vista workstation as pointed out here. To accomplish this, type the following command at both boxes:

sc \\localhost config vds start= auto
sc start vds

netsh advfirewall firewall set rule group="Remote Volume Management" new enabled=yes

Concluding

The Remote Server Administration Tools (RSAT) for Windows Vista add remote Server Core administration functionality to Windows Vista and can be used in that manner, when you know your way around them.

The Tools have some rough edges, some missing functionality (by default mostly) and most of them can't even be used with Server Core installations of Windows Server 2008, but they fulfill my remote administration wishes. When used in conjunction with the tools from Computer Management (compmgmt.msc) as shown here, you too can enjoy the bountiful joys of remote management from the comfort of anywhere you'd like. (in my case: my sunny backyard)

Handling Server Core Roles and Features

2008-04-24T19:56:27Z

Server Core is proving to be a versatile infrastructure platform. After installing your basic Server Core installation, configuring network interfaces, activating, enable remote management (through RDP or WinRM) and changing the look and feel it might be time to install additional roles and optional features.

Roles

It's not just infrastructure roles you can install on Server Core... You can equip your Server Core box with a total of nine roles.Although not all roles are available after simply installing Windows Server 2008 in a Server Core fashion. (Some roles need to be downloaded first.)

For a complete overview of Server Roles look at the list of Server roles for Windows Server 2008 Server Core below:

Server Role Name	Server Core Role Technical Name
Web Services (IIS)	IIS-WebServerRole * WAS-WindowsActivationService *
Print Services	Printing-ServerCore-Role *
Hyper-V	Hyper-V **
Active Directory Domain Services	DirectoryServices-DomainController-ServerFoundation
Active Directory Lightweight Directory Services	DirectoryServices-ADAM-ServerCore
DHCP Server	DHCPServerCore
DNS Server	DNS-Server-Core-Role
File Services	enabled by default
Windows Media Services	MediaServer **

* Contains subroles that can be installed separately
** Role components need to be downloaded first

Features

Besides roles Server Core installations of Windows Server 2008 also allow the installations of sixteen features. It's not really clear what distinguish a role from a feature, but the fact DNS Server is a role and WINS Server is a feature made Mark Minassi believe features is the stuff Microsoft is embarrassed about. This is not the case and can be easily proven by summing up the list of Server Core installable features:

Feature Name	Server Core Feature Technical Name
Bitlocker	BitLocker
Bitlocker Remote Admin Tool	BitLocker-RemoteAdminTool
Client for NFS	ClientForNFS-Base
Server for NFS	ServerForNFS-Base
Distributed File System Namespace Server	DFSN-Server
Distributed File System Replication	DFSR-Infrastructure-ServerEdition
File ~~Replacement~~ Replication Service	FRS-Infrastructure
Removable Storage Management	Microsoft-Windows-RemovableStorageManagementCore
Multipath IO	MultipathIo
Network Load Balancing (NLB)	NetworkLoadBalancingHeadlessServer
Quality of Service (QoS/qWAVE)	QWAVE
Simple Network Management Protocol	SNMP-SC
Subsystem for UNIX-based Applications	SUACore
Telnet Client	TelnetClient
Windows Server Backup	WindowsServerBackup
Windows Internet Naming Service	WINS-SC

Handling roles and features

Checking roles and / or features

One of Server Core's hidden gems is the oclist.exe program. As an administrator you can use it to see what roles and features you may install and what roles and features are installed. Simply run the following command on the console of your Server Core box:

oclist.exe

As Andrew Mason shows here you can also pipe the output of the command. For instance if you don’t want to include all of the many IIS options in the output of oclist.exe, run:

oclist.exe | find “Installed” | find /v “IIS”

In the same fashion you can make oclist.exe display a mere list of Roles and Features that are installed, using the following command:

oclist.exe | find "Installed" | find /v "Not Installed"

Installing roles and / or features

You'll find two commands to install a Role or a Feature: pkgmgr.exe and ocsetup.exe.

Both commands actually do the same thing in terms of installing a role or feature. One has more features than the other, but for the purpose of installing a role it makes no difference which command to use.

To install a role use one of the following commands:

start /w ocsetup.exe RoleOrFeatureName

start /w pkgmgr.exe -iu:RoleOrFeatureName

Where RoleOrFeatureName needs to be replaced with the Case sensitive (!) name of the Role or Feature you want to install.

Exception: Active Directory Domain Services

While you can install the Active Directory binaries to your hard disk by installing the Active Directory Directory Services Role, this will not result in a working Domain Controller. You need to run dcpromo.exe. More information here.

Removing roles and / or features

The previous two commands (pkgmgr.exe and ocsetup.exe) can also be used to remove a previously installed Role and / or Feature from your Server Core box.

To uninstall a role use one of the following commands:

start /w ocsetup.exe RoleOrFeatureName /uninstall

start /w pkgmgr.exe -uu:RoleOrFeatureName

Where RoleOrFeatureName needs to be replaced with the Case sensitive (!) name of the Role or Feature you want to uninstall.

Exception: Active Directory Domain Services

Uninstalling the DirectoryServices-DomainController-ServerFoundation Server Role from a Server Core Domain Controller will seriously cripple your installation to the extend where it won't boot normally anymore. Please use dcpromo.exe with appropriate command line switches.

Removing sources

Another great tip Andrew Mason shared publicly is how to use pkgmgr.exe to delete the local installation sources of the roles and features discussed above. This might get in handy when:

You want to free up some hard disk space on your server's hard disk
You strive to make your Server Core box the leanest and meanest server out there
You want to protect other system administrators against themselves by prohibiting them from installing roles and features they wouldn't understand anyway.

Highlevel steps

The highlevel steps to remove a source are:

Run:

     start /w pkgmgr /up:SourceToRemove

Where SourceToRemove is the Case sensitive (!) and architecture-dependent (!) name of the installation source you want to remove.
Reboot (you can remove multiple packages before rebooting)
Wait about 30 minutes for the disk cleanup to occur

Source names

The name of the installation sources are different than the names of the roles and include the architecture (x86 or amd64) and the version (6.0.6001.18000 for Windows Server 2008 RTM, other version numbers available here) in the following manner:

Microsoft-PackageDescription~31bf3856ad364e35~Architecture~~Version

Where PackageDescription can be any of the following:

Hyper-V-Package

Windows-BLB-Package

Windows-DFSN-ServerCore

Windows-DFSR-ServerEdition-Package

Windows-DhcpServerCore-Package

Windows-DirectoryServices-ADAM-SrvFnd-Package

Windows-DirectoryServices-DomainController-SrvFnd-Package

Windows-DNS-Server-Core-Role-Package

Windows-FailoverCluster-Core-Package

Windows-FileReplication-Package

Windows-IIS-WebServer-Core-Package

Windows-Internet-Naming-Service-SC-Package

Windows-MultipathIo-Package

Windows-NetworkLoadBalancingHeadlessServer-Package

Windows-NFS-ServerFoundation-Package

Windows-Printing-ServerCore-Package

Windows-QWAVE-Package

Windows-RemovableStorageManagementCore-Package

Windows-SecureStartup-OC-Package

Windows-SNMP-SC-Package

Windows-SUA-Core-Package

Windows-Telnet-Client-Package

Windows-ServerCore-EA-IME-Package

Windows-ServerCore-EA-Fonts-Package

Note:
While removing sources sounds appealing you should be aware it cannot be undone. Once you remove a package for a Role or Feature you can only install the Role and/or Feature after a reinstall of the Operating System.

Example:

start /w pkgmgr /up: Microsoft-Windows-SUA-Core-Package~31bf3856ad364e35~amd64~~6.0.6001.18000

Concluding

You can install 9 roles and 16 features, without even searching for the installation media.

If you're happy with your Server Core installation running some roles and some features, simply remove the sources of the other roles and features to make your server even leaner and meaner!

For beta or for worse

2008-04-14T08:23:26Z

I've been beta testing a lot of unfinished software products in the past years. Not surprisingly most of these were Microsoft products. (and mostly unknowingly also many products from other vendors...) Let's dive into the world of alphas, betas, release candidates and other test versions, because I suspect seemingly more people using beta software isn't just a result of Beta marketing; there are multiple factors at play.

Beta Usage

I think there are five main reasons why a lot of people use Beta software nowadays:

It's everywhere nowadays
Beta software is getting more exposure
New software is mostly built on top of existing software
Development times have increased
Virtualization makes it easier to experiment

(I also think not all five reasons might apply to all beta software products.)

It's everywhere

Did you know that a lot of products from Google are still in beta development fase? If you look at Google Blog Search, Google Book Search, Google Video and even Google Mail you can clearly see the 'beta' thingy in each of these logos. And what to think of Joost, Corel WordPerfect Lightning and of course parts of the Live family of products? It's not just limited to 'big companies' though: Many Web 2.0 start-ups like GENi, Scrybe, GrandCentral, nsyght and many others prominently display the B word on their pages.

All these services and software are beta and some of us use (some of) them every day, like they consider them to be finalized products. They're not.

No wonder we don't get scared from the 'beta' word anymore - We're surrounded by it, we've come to love it (and in Microsoft terms: come to 'live' it) and we are made to believe using beta software is as easy, comfortable and hassle-free as the 'finalized' product.

Exposure

Back in the previous century it was considered 'a cool thing' to test unfinished software. You could brag to friends you were running a beta version of some new Windows version and only big companies had access to the beta bits to prepare them for the new technologies. I guess everyone wants to brag to their friends once in a while and every company wants to make its software ready for the next big product. It has become a way to differentiate between IT Professionals more than a way to differentiate between software manufacturers.

Let's look at the Windows Operating System. Windows 2000 Beta and Windows XP beta were only available to roughly 500.000 people. Windows Vista Beta 2 was available to millions of people in 2006. I feel Microsoft made a good decision there. Windows Vista was looked at closely by IT Pros, but also by customers in the TAP and RDP programs. At the same time Microsoft picked up on the many blogs and websites surrounding Windows Vista.

A newer form of "showing off" beta status was Microsoft's IIS7 Go Live initiative. It was an easy way. You could be part of a Beta incrowd, whilst you don't need a luminescent light bulb above your head in the form of a new revolutionary Web 2.0-style sociological experiment accompanied by start-up capital.

Evolution instead of revolution

Let's look at the situation most software manufacturers find themselves in. They have a good piece of software, a nice place in the market, customers know how to work with it and they've managed to eliminate most of the bugs. Of course they'd be stupid to re-engineer the whole piece and write all the code again. The risk of introducing new bugs, harming the reputation of the company and losing customers is just too high. Unless the current strategy or architecture of the software is really becoming a threat software will just evolve further.

Software users seem to know this and they receive help from IT Professionals. From Windows 9x or Windows NT4 to Windows 2000 is a revolution, from Windows 2000 to Windows XP is an evolutionary process. (looking at NT versions this makes even more sense)

If you'd know the next version of Windows is just Windows Vista with some new features you would find the risk of beta testing more acceptable in contrast to the situation where you'd know the project team for the new version of Windows is going to be lead by a Jim Allchin-like manager, which isn't scared of really changing the product to make it something.

Development time

We live in an age of complex technology. We have 24bit color screens instead of monochrome screens, calculators that rival the computing power of the early mainframes and use software, consisting of millions of lines of code.

Imagine a software company wants to make big changes to a software product. To make these changes the company will have to hire a lot of people (if these people are available for hire) or these changes will take a lot of time.

Looking at Windows Vista I saw a lot of people wanting to testdrive the new version of Windows, just because it took five years. They were still looking at the same Windows interface, while Mac enthusiasts worked with the spiffy new MacOS X environment.

Virtualization

Virtualization is useful for server consolidation. It's also widely used for testing purposes, because it allows to easily put a machine together to run a specific piece of software on. Various products from VMWare, Microsoft and Xen (among others) allow you to test something quickly without having to mess with physical hardware, physical installation media and space.

Developers use these products as well. As a tester you can expect most of the beta products to run smoothly on (at least one of) these virtualization platforms. Testing on the same platform as the developer provides a hassle-free beta experience most of the time: You don't have to worry about unsupported drivers or unsupported hardware. It'll all work out of the box.

Virtualization won't allow you to test anything though and your experience won't always be as painless as I described above. Jorge had a hard time getting certain Windows Vista builds to work on ESX. DirectX, 64-bit and Ubuntu are things you won't be able to experience in Virtual PC or Virtual Server guests.

Beta Marketing

Beta used to be a way to quietly test products amongst a defined universe of users before making them public. I guess marketing teams have adopted the B word and made it a marketing phrase. Clearly 'Beta' got bombarded as a Web 2.0 buzzword. Buzzwords are fit for marketing purposes.

How can a technology developer benefit from using Beta exposure? I can think of five good reasons:

The Hype scenario

In marketing lingo 'Hyping' a product before release is called creating a pull-market for your product in an sensational way. When there's no-one actually 'working' with your stuff (Beta of course) creating a hype or buzz will be far more difficult: A hype tends to be coming from others places than just your marketing department. It's about enthusiasts getting excited by a concept (or not) and promoting it. What better way than 'leaking' some screenshots and then making a beta available to hype your technology?

The Exclusivity scenario

You can make the use of a product feel 'exclusive' by letting it get tried out while it isn't ready for the public, regardless of whether or not the beta is accessible to everyone. Exclusivity tends to create strong customer preference for a brand. Invite systems seems to be mandatory in this scenario.

The Complexity scenario

I can think of a lot of situations where things have to be tested "in the wild" by a lot of people. Service-Oriented Architecture and Microsoft's Hyper-V sure have the potential to create such situations. When you read along you'll find this scenario is closely tied to the quality scenario.

The Business scenario

Shareholder Value, Start-Up Capital and Market Relevance are three main keywords for businesses. These keywords might compel you to show yourself to the outside world. A beta product might show what's coming, while still unfinished.

The Quality Scenario

Software testing costs money but plays a vital role in quality management. A beta program might provide you with free beta testers. On the other hand you can't expect a thorough or specific test by someone you're not paying... I think the only way to successfully engage in this scenario is to first hire some testers and make them perform specifically targeted quality tests before you do it publicly. Of course you need to keep a tester on staff to specifically test the enhancements you make according to public beta feedback.

The Perma-Beta scenario

When you have a product, but no way of making money from it or the inability to take responsibility for it, you can leave a product as a beta product permanently. This will stop complaints or at least give you a reason for not acting customer friendly when people complain.

One might argue Google's policy is a form of Perma-Beta.

Concluding

Beta is a marketing game. Both customers and technology developers seem to play it. Technology developers seem to be using "Beta Marketing" and customers seem to be falling for it since the reputation of Beta products has improved dramatically.

For a product to become hyped however a technology developer needs to make sure enthusiasts jump on their bandwagon. (besides having some strong Unique Buying Points)

Disclaimer Beta Software

The information on this webpage applies to software that was in testing phase but utilizable by experienced users by the time the webpage was written. This software has not been released for sale, distribution or usage for the general public. The information on this webpage and the beta software are provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.

The things that are better left unspoken

Monitoring Server Core from the command line

Task Manager

Performance Monitor

Selecting counters

Building the data collector

Viewing the data collector

Starting the data collector

Modifying the data collector (if need arises)

Using collected data

Other tools and products

Disk usage (du.exe)

Process Explorer

Concluding

Further reading

Installing Windows Server 2008

Installation methods

Using the physical DVD

Using an image

Virtual deployments

Physical deployments

Hardware redirection

Using a bootable USB device

Using the network

Using Windows Deployment Services

Using the Microsoft Deployment Toolkit

Using 3rd party solutions

Concluding

Further reading

Related reading

Remotely managing your Server Core using RSAT

Contents

Installing RSAT

Fulfilling system requirements

Downloading the standalone setup package

Installing the package

Selecting RSAT features

Selecting Applicable Tools

Displaying Administrative Tools

Using RSAT

Active Directory Domain Services Tools

Group Policy Management Tools

DNS Server Tools

DHCP Server Tools

File Services Tools

Share and storage management

Concluding

Further reading

Related reading

Handling Server Core Roles and Features

Roles

Features

Handling roles and features

Checking roles and / or features

Installing roles and / or features

Exception: Active Directory Domain Services

Removing roles and / or features

Exception: Active Directory Domain Services

Removing sources

Highlevel steps

Source names

Concluding

Further reading

For beta or for worse

Beta Usage

It's everywhere

Exposure

Evolution instead of revolution

Development time

Virtualization

Beta Marketing

The Hype scenario

The Exclusivity scenario

The Complexity scenario

The Business scenario

The Quality Scenario

The Perma-Beta scenario

Concluding

Further reading

Disclaimer Beta Software