Archive for May, 2010

Here are some of the new features:

  • Automated System Recovery (ASR). This feature simplifies the restoration of the operating system partition.
  • Goodbye, Emergency Repair Disk. There is no more ERD in Windows Server 2003. The only repair options are the Recovery Console or ASR.
  • Emergency Management Services (EMS). If a server cannot be reached via the network, EMS provides an out-of-band connection to the server via a serial port.
  • Online Crash Analysis. The kernel-mode debugging utilities in Windows Server 2003 can now run on the same machine as the operating system they are monitoring. This permits running a variety of debugging chores at the console.
  • Volume Shadow. Locked files create problems for backup programs. Users get irate when you tell them that you can’t restore a file because it was locked during the backup while they were working from home. The Volume Shadow service takes a snapshot of a locked file so that the backup program can save the snapshot.
  • System Restore. This feature, only present on XP, periodically takes snapshots of the system configuration that you can use as checkpoints for rolling back the system to a previous configuration.
  • Online event tracking. If an application fails or otherwise causes a system error, the system collects information about the failure and sends that information to Microsoft, where it is compiled and analyzed for trends.
  • Shutdown Event Tracker. This “feature,” if you want to call it that, requires that you specify a reason each time you shut down a system. This reason is put in the Event log. If the system crashes, you must specify a reason when the system restarts.
  1. Open an empty MMC console using START | RUN | MMC.
  2. From the console menu, select CONSOLE | ADD/REMOVE SNAP-IN. The Add/Remove Snap-in window opens.
  3. Click Add. The Add Standalone Snap-in window opens.
  4. Double-click Certificates to load the snap-in. If you are logged on with an account that does not have administrator privileges, the only option is to load the your own personal certificates. Otherwise, you get additional choices of computer and service certificates.
  5. With the snap-in loaded, save the console with a descriptive name, such as Cert.msc. You may want to save it in \WINNT\System32 along with the rest of the console files so that another administrator can use it. The console does not point at your specific certificate. It loads the certificates of the user who launches the console.
  6. Expand the tree to CertificatesCurrent User | Personal | Certificates. Certificates issued to you are listed in the right pane. The Intended Purposes column lists the certificate’s function. If you have ever encrypted a file, you will have at least one EFS certificate. The domain Administrator account will have two certificates, one for EFS and one for File Recovery (FR).
  7. Double-click a certificate to view the contents.

You can use the Certificates snap-in to obtain new certificates. This is not generally necessary for EFS certificates because the EFS service obtains the certificate automatically when you encrypt a file. If you want to designate more Data Recovery Agents, though, you’ll need to obtain File Recovery (FR) certificates for them. You can request them using the Certificates snap-in.

EFS only issues one self-signed FR certificate. In a domain, it is issued to the domain Administrator account. For a local machine, it is issued to the first user who logs on to the machine following Setup. You’ll need a Certification Authority (CA) to issue any further FR certificates.

If you have evaluated EFS in Windows 2000 and found critical features missing, it’s worth taking a second look at EFS in Windows Server 2003 and XP. The changes include the following:

  • New and more cryptographically robust encryption methods. You can now choose between DESX encryption (used by Windows 2000) and 3DES (Triple-DES), an algorithm that complies with government standards for handling of non-classified documents.
  • Offline file encryption. This feature is one of the most significant improvements in Windows Server 2003 and XP. It enables users to use a highly convenient feature, offline file storage, while retaining the ability to protect their files with encryption.
  • Encrypted file transfer over WebDAV. The Web-based Distributed Authorizing and Versioning redirector uses HTTP rather than SMB. Encrypted files are transferred in their encrypted state rather than being decrypted prior to transport as happens with SMB. Also, servers can store encrypted files using WebDAV without compromising security with Kerberos delegations.
  • More flexible group policy control. EFS can now be disabled throughout a domain with a single click of the mouse in a group policy. This contrasts with Windows 2000, which requires removing and re-importing X.509 certificates to control encryption.
  • Shared encrypted files. Users with encrypted files can assign access to other users. This enhances the use of EFS in a workgroup. Only individual users can be given access, not groups. Additional users can only be selected by users who already have access.
  • Copy warnings. Explorer now warns users when they attempt to copy or move encrypted files to an unprotected location such as a Zip drive, floppy drive, or FAT partition. New switches in COPY and XCOPY permit overriding these protections, if necessary.
  • Visual cues. The Explorer shell now shows the names of encrypted files and folders in a different color, similar to the way compressed files are displayed in Windows 2000.
  • Improved command-line administration. The CIPHER command-line utility has been updated with several new features, including the ability to generate file recovery certificates, the ability to search for encrypted files on a volume, the ability to refresh certificates for all encrypted files on a volume, and the ability to wipe all unused disk space to remove temporary files. (The wipe feature was released in Windows 2000 SP3.)
  • Security improvements. Although not strictly an EFS improvement, the handling of the crypto Master key has been changed so that it is not updated when a local user password is changed by anyone other than the user. This eliminates a serious deficiency for standalone laptops and desktops. Now a hacker cannot use utilities to change a user’s password (or the Administrator password) on a standalone machine to gain access to encrypted files.

Not every change is a welcome one, however. In Windows 2000, files cannot be encrypted without the certificate of a Data Recovery Agent (DRA). This ensures that a user cannot encrypt files and then quit the company and leave you without a means of recovering the files. In Windows Server 2003 and XP, it is possible to encrypt files without a DRA. This “feature” has potentially serious consequences because users could encrypt their files and then lose the private key, thereby losing access to the files permanently.

As stated earlier in this chapter, the Windows XP/Windows Server 2003 boot sequence closely resembles that of Windows NT/2000. Listed below are the processes that take place when Windows NT-based operating system successfully starts on an x86-based computer:

  • Power On Self Test (POST)
  • Initial startup process
  • Boot loader process
  • Operating-system selection (if you have a multi-boot system)
  • Hardware detection
  • Hardware-profile selection
  • Kernel-loading process
  • Kernel-initialization process
  • User-logon process
Note The startup sequence quoted above applies to systems started or restarted after a normal shutdown. The startup processes begin when you do one of the following:

  • Turn on the computer
  • Reboot the system

However, this startup sequence does not apply when resuming from hibernate or standby modes.

When you log on, the process of loading Windows NT/2000, Windows XP, or Windows Server 2003 is completed, as well as are most of the initialization procedures. However, the startup can only really be considered as successfully completed after you log on to the system.

The following requirements need to be met to successfully begin the Windows NT/2000/XP/Windows Server 2003 startup:

  • Correct initialization of all the hardware.
  • Presence of all required files for starting the OS. If any of these files aren’t present in the correct folder or are corrupt, the startup will fail.

In this section, we’ll discuss the registry keys that are used for power management. You may edit any of them using one of the registry editors.

Note Changing registry entries responsible for power management won’t have an immediate effect. Windows only reads settings from the registry when you log on, when you click OK in Control Panel, or when a Powerprof.dll function is called on to read the registry.

The registry keys used for power management are listed below.

  • HKCU\AppEvents\EventLabels\LowBatteryAlarm – descriptive name of a low battery-power-alarm event
  • HKCU\AppEvents\EventLabels\CriticalBatteryAlarm – descriptive name of a critical battery-power-alarm event
  • HKCU\AppEvents\Schemes\Apps\PowerCfg\LowBatteryAlarm\.Current, HKCU\AppEvents\Schemes\Apps\PowerCfg\LowBatteryAlarm\.Default, HKCU\AppEvents\Schemes\Apps\PowerCfg\CriticalBatteryAlarm\.Current, HKCU\AppEvents\Schemes\Apps\PowerCfg\CriticalBatteryAlarm\.Default – filenames of the WAV files that will play as a low and critical power-alarm events
  • HKCU\Control Panel\PowerCfg\CurrentPowerPolicy – index of current user and machine power policy
  • HKCU\Control Panel\PowerCfg\GlobalPowerPolicy\Policies – the user global power policy (binary encoded data)
  • HKCU\Control Panel\PowerCfg\PowerPolicies\n\Name – name of power scheme n, where n = 0, 1, 2, etc.
  • HKCU\Control Panel\PowerCfg\PowerPolicies\n\Description – descriptive string for power scheme n, where n = 0, 1, 2, etc.
  • HKCU\Control Panel\PowerCfg\PowerPolicies\n\Policies – user power policy n, where n = 0, 1, 2, etc. (binary encoded data)
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\PowerCfg\LastID – index of the last power policy in the lists of user and machine power policies (for example, if there are six user power policies and six machine power policies in the registry, the value of this key is 5)
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\PowerCfg\DiskSpinDownMax – the maximum disk spin-down time that Control Panel will allow the user to set
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\PowerCfg\DiskSpinDownMin – the minimum disk spin-down time that Control Panel will allow the user to set
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\PowerCfg\GlobalPowerPolicy\Policies – the machine global power policy (binary encoded data)
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\PowerCfg\PowerPolicies\n\Policies – machine power policy n, where n = 0, 1, 2, etc. (binary encoded data)

Power management configuration in Windows 2000, Windows XP, and Windows Server 2003 is based on the concept of power schemes. A power scheme is a group of preset power options that are passed to the Power Policy Manager component of the operating system to control the machine’s power-management behavior.

Each power scheme consists of a global power-policy structure and a power-policy structure.

  • Global power-policy structures contain preset power options that are global across all power schemes.
  • Non-global power-policy structures contain power options that are unique to a particular power scheme.

These power-policy structures are further divided into machine structures and user structures.

  • Values in machine structures are stored in the HKEY_LOCAL_MACHINE registry key, and none of these values are exposed in the user interface. For example, you can’t set any of these values using the Power Options applet in the Control Panel.
  • Values in user structures are stored in the HKEY_CURRENT_USER registry key and some of these values are displayed in the user interface. Some of these parameters can be set using the Power Options applet in Control Panel.

The data structures defining power management policy are listed below:

  • GLOBAL_POWER_POLICY – used to manage global power policies. This structure contains the data common to all power schemes. This structure is a container for a GLOBAL_USER_POWER_POLICY structure and a GLOBAL_MACHINE_POWER_POLICY structure, which contains elements that are read from and written to the registry.
  • GLOBAL_MACHINE_POWER_POLICY – this structure is a part of the GLOBAL_POWER_POLICY structure. It contains the data common to all power schemes and users. The elements in this structure are read from and written to the HKLM key in the registry.
  • GLOBAL_USER_POWER_POLICY – this structure is a part of the GLOBAL_POWER_POLICY structure. It contains the data common to all power schemes for the user. The elements in this structure are read from and written to the HKCU key in the registry.
  • POWER_POLICY – used to manage non-global power policies. This structure contains the data unique for all power schemes. This structure is a container for the USER_POWER_POLICY and MACHINE_POWER_POLICY structures that contain the elements to be read from and written to the registry. There is one POWER_POLICY structure for each power scheme on a machine.
  • MACHINE_POWER_POLICY – this structure is a part of the POWER_POLICY structure. It contains the data unique to each power scheme, but common to all users. The elements in this structure are read from and written to the HKLM key in the registry.
  • USER_POWER_POLICY – this structure is a part of the POWER_POLICY structure. It contains the data unique to each user and power scheme. The elements in this structure are read from and written to the HKCU key in the registry.

As with previous versions of the OS, you use an ‘‘unattend’’ file for a Server Core installation or a regular Windows Server 2008 image. The unattended server install enables you to perform most of the initial configuration tasks during Setup. The following section describes an unattended installation of the Server Core image. If you have a number of servers to install, the unattended installation of Server Core can provide a host of benefits.

There is no need to perform initial configuration using command-line tools because you can include options in the unattend file that will enable remote administration. Once Setup completes you will be able to connect with various tools and applications and continue to fine-tune and configure.

To install a Server Core installation by using an unattend file, do the following:

1. First create an .xml file titled unattend.xml. You can use any text editor or the Windows System Image Manager.

2. Next copy the unattend.xml file to a local drive or place it on a shared network resource.

3. Place the Windows Preinstallation Environment (Windows PE), Windows Server 2003, or Windows XP media in the machine’s CD drive and start your computer.

4. Next place the CD of the Server Core installation image of Windows Server 2008 into your disk drive. As soon as the auto-run Setup window appears, click Cancel. This will bring you to the command prompt.

5. Next, change to the drive that contains the installation media, enter the following command, and press Enter:

setup /unattend:<path>\unattend.xml

The <path> is the path to your unattend.xml file described in step 2. Setup will run to completion with whatever you have in the unattend.xml file.

To create a server running on Server Core installation you need to have the following handy:

■ The Windows Server 2008 installation media

■ The product key

■ A computer with the recommended configuration for a Server Core installation

Before you begin, make sure you have clean or newly formatted hard disks or volume that you can allow installation to format for you. You cannot upgrade from a previous version of Windows Server to a Server Core installation. You also cannot upgrade from a full installation of Windows Server 2008 to a Server Core installation. Only a clean installation is supported.

Be sure of your needs and configuration before you start. Once you start a Server Core installation you cannot go back later and try upgrading it to a full installation of Windows Server 2008 with the Windows UI. Microsoft does not support that route and you would have to blow away the Server Core installation and start all over again.

To install a Server Core installation, perform the following:

1. Insert the Server Core Windows Server 2008 installation media into the DVD drive.

2. The auto-run dialog box will now appear. Click the Install Now option.

3. The installation wizard takes you through the instructions to complete Setup.

4. After the installation, press Ctrl+Alt+Delete and click Other User. At the login enter Administrator with a blank password, and then press Enter. You will now be able to log in and you will have the chance to set a password for the Administrator account.


Give Windows Server 2008 a hand, and it takes an arm . . . or at least another drive. Installation assesses all the hard-drive resources in the system, and if you have two drives (or partitions), the OS attempts to use both. The first active partition gets snagged for the system files . . . the minimum required to raise the system to a point where you can run recovery tools or the Recovery Console. Windows Server 2008 calls this the system volume.

Windows Server 2008 then snags a second drive or partition and uses it for the boot files, the files needed to boot the rest of the operating system all the way to the desktop on which you can log in. Windows Server 2008 calls this volume the boot volume. (This is a reversal of the old naming convention for boot and system partitions.)

Two reasons exist for the dual-disk consumption. First, Windows Server 2008 is optimized to use more than one hard-disk drive. Second, a minimum boot disk can be configured to hold just the boot files and can be formatted as FAT or FAT32 instead of NTFS. The theory is that if you lose the base operating system — that is, if you cannot boot to the desktop — you can atleast boot to a DOS diskette and then, from DOS, copy new base files over the corrupt ones (or replace a defective drive). Many NT and NetWare systems have been configured this way. However, a well-designed and managed system need not retain a FAT boot disk, which, because of its poor security, is a risk to the entire system because it does not support file-level security.

Windows Server 2008, however, enables you to boot to the Boot Options console (whenever it detects a disaster). Here you have several options, such as Safe Mode with Networking, and from there you can attempt to boot without certain services and debug the problem after you have the OS up and running. You can also boot the Recovery Mode Console, which takes you to a command line that you can use to access NTFS partitions and the boot disks. The practice of leaving boot or system files on FAT volumes is old-fashioned — the result of bad memories from Windows NT days. We recommend the partition arrangement options described in the following sections.

Option 1: One HDD

This arrangement uses one hard-disk drive, which forces Windows Server 2008 to put both boot files and system files onto the same drive and partition. To use this option, follow these steps:

1. Configure the system with one hard-disk drive of about 12GB in size. (Microsoft’s official recommendation is to supply at least a 10GB partition, but with roles and features to be added, as well as patches and fixes and new features coming down the road, you need to leave room for expansion.)

2. Format the partition during the install as NTFS.

3. Have Windows Server 2008 choose the default partition name.

The pros of this partitioning option are as follows: First, you save on hard-disk drives. Second, you can mirror this disk for fault tolerance. (Unfortunately, you can mirror the disk only under hardware disk mirroring because Windows Server 2008 does not enable you to mirror a disk that was installed as a basic partition . . . even if you make the disk a dynamic disk.)

The negatives of this partitioning option are that, if you must format the system or boot volumes as FAT, you end up with a disk consisting of numerous partitions. This is not necessary on a server and can later lead to problems, such as no capability to mirror or diminishing hard-disk space and the advanced features of dynamic disks. You may also have trouble providing dual-boot capability, but dual boot is not recommended, and besides, you have no need to provide dual boot on a production server.

Option 2: Two HDDs

This arrangement uses two hard-disk drives: Windows Server 2008 puts boot files on one disk and system files on the second disk. To use this option, follow these steps:

1. Configure the system with two hard-disk drives of about 2GB each in size.

2. Format the drives as NTFS during the install.

3. Have Windows Server 2008 choose the partition names and the default and put the files where it needs to.

The positive aspect of this partitioning option, as far as we can tell, is that you have the option of leaving the boot volume formatted as FAT (or FAT32) and formatting the rest of the partitions and drives as NTFS.

The negatives of this partitioning option are that you use up a second drive for a small amount of hard-disk space, but if you are bent on dual or multi-boots, the second drive can hold the additional OS.

Although you have a performance incentive to use a second hard disk, the increased performance is not worth the effort and the second drive, considering the speed and response of modern hard disks. We are also talking about Server Core here and not Active Directory, LOB servers, SQL Server, or Exchange, which are built to take advantage of additional drives. You would be better off using a second drive as a mirror of the first to gain a fault-tolerance feature.

The Server Core installation lets you install a minimal OS for running just the chosen server

roles that would not even need a GUI. This means that you don’t have the huge ‘‘attack’’ surface

that will ensue from all the service requirements. One more thing: Once you install just Server

Core you can stand your server up in a secure environment, both physical and online, and

worry only about securing the services you are actually running. Once Server Core has been

installed you can then open Server Manager (remotely or via scripting) and install, among many

others, the following server roles:

■ Active Directory Domain Services (AD DS)

■ Application Server

■ DHCP Server

■ DNS Server

■ File Services

■ Print Services

Here are some more benefits of the Server Core installation alternative:

■ Lower maintenance. You only need to maintain on the server what is actually installed

on the server. Why worry about maintaining File Services on a server that is nothing more

than a simple domain controller?

■ You need less disk space. The Server Core requires only about 1 gigabyte (GB) of disk

space to install and approximately 2GB for operations after the installation.

■ Less management. Management costs in realms like security, availability, and service

level are far less than previous installation scenarios. You would not have to worry about

supporting a bunch of services and code that you are not using.