5. Chkdsk improvements
Today’s businesses must be able to manage larger and larger amounts
of data. At the same time, the capacity of hard disk drives has grown
significantly, whereas the price of very large drives has continued to
decline. This has posed problems for organizations that have tried to
deploy multi-terabyte disk volumes in their environments because of the
amount of time Chkdsk takes to analyze and recover from file system
corruption when it occurs.
In earlier versions of Windows Server, the time taken to analyze a
disk volume for potential corruption was proportional to the number of
files on the volume. The result was that for server volumes containing
hundreds of millions of files, it sometimes took many hours (or even
days) for Chkdsk to complete its operations. The volume also had to be
taken offline for Chkdsk to be run against it.
In Windows Server 2012, however, Chkdsk has been redesigned so that
the analysis phase, which consumes most of the time it takes Chkdsk to
run, now runs online as a background task. This means that a volume
whose file system indicates there may be file corruption can remain
online instead of needing to be taken offline for analysis. If analysis
by Chkdsk determines that the file system corruption was only a
transient event, no further action need be taken. If Chkdsk finds
actual corruption of the file system, the administrator is notified in
the management consoles and via events that the volume needs repair.
The suggested repair process may require that the volume be remounted,
and the server may need to be rebooted to complete the repair process.
The result of this redesign of Chkdsk is to reduce the time it takes
to analyze and repair a corrupt large disk volume is reduced from hours
(or days) to minutes or even seconds. Additional improvements to NTFS
in Windows Server 2012 include enhanced self-healing, which
automatically repairs many issues without the need of running Chkdsk.
The overall result of such improvements is to ensure continuous
availability even for servers having very large disk volumes with
hundreds of millions of files stored on them.
6. Easy conversion between installation options
Windows Server 2008 and Windows Server 2008 R2 offered an alternative installation option called Windows Server Core that included only a subset of the server roles, features, and capabilities found in the full installation option. Server
Core included only those services and features needed to support common
infrastructure roles such as domain controllers, DNS servers, and DHCP servers. By eliminating unnecessary roles and features, and also most of the graphical user interface (GUI;
the Server Core user interface only presents a command-line interface),
the result is a minimal Windows Server installation that has a smaller
disk footprint, a smaller attack service, and requires less servicing
(fewer software updates) than the full installation.
A limitation of how installation options were implemented in Windows
Server 2008 and Windows Server 2008 R2 is that you cannot switch an
installation between the full and Server Core options. So if you have a
DNS server with a full installation of Windows Server 2008 R2, the only
way to change this into a DNS server with a Server Core installation is to reinstall the operating system on the machine.
Starting with Windows Server 2012, however, you can now switch between Server Core and GUI
installations. For example, if you have deployed a GUI installation of
Windows Server 2012 and you want to remove the GUI management tools and
desktop shell to convert it into a Server Core installation, you can do
this easily by running the following PowerShell command:
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -restart
When you run this command, it first collects data for the system and then starts the removal process:
Once the GUI and management tools and desktop shell have been
removed, the server restarts, and when you log on, you are presented
with the bare-bones Server Core user interface:
The process can be reversed by running the following command to convert the Server Core installation back into a GUI one:
Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Restart
In addition to the Server Core and GUI installation options, Windows Server 2012 can be configured in a third form called Minimal Server Interface.
This form is not available when you install Windows Server 2012, but
you can configure it using Server Manager or using PowerShell.
There are several reasons you may want to configure the Minimal
Server Interface. First, it can function as a compatibility option for
applications that do not yet support Microsoft’s recommended
application model but still want some of the benefits of running Server
Core. Second, administrators who are not yet ready to use remote
command-line-based management can install the graphical management
tools (the same ones they would install on a Windows client) alongside
the Minimal Server Interface or Server Graphical Shell.
The Minimal Server Interface is similar to the GUI installation, except that the following are not installed:
However, the following management tools are available on the Minimal Server Interface:
Benefits for organizations
A key benefit of the easy conversion between installation options
available in Windows Server 2012 is the added flexibility you gain by
being able to convert between the GUI and Server Core installation options. For example, you could deploy your servers with the GUI
option to make them easier to configure. Then you could convert some of
them to Server Core to reduce footprint, enable greater consolidation
ratios of VMs, and reduce your servicing overhead. You can also select
the Minimal Server Interface for application compatibility needs or as
a compromise for administrators who are not yet ready to administer
without a GUI.
Managing servers without the Metro start menu
Installations of previous versions of Windows Server included binaries for all server
roles and features even if some of those roles and features were not
installed on the server. For example, even if the DNS Server role was
not installed on a Windows Server 2008 R2 installation, the system
drive of the server still included the binaries needed to install that role, should it be needed later.
In Windows Server 2012, you can remove the binaries for roles or
features that aren’t needed for your installation. For example, if you
won’t be installing the DNS Server role on a particular server, you can
remove the binaries for this role from the server’s system drive. Being
able to remove binaries used to install roles and features allows you
to reduce the footprint of your servers significantly.
Completely removing features
Binaries of features can be removed by using PowerShell. For
example, to completely remove a feature including its binaries from a
Windows Server 2012 installation, use the Uninstall-WindowsFeature
cmdlet.
If you later decide you want to install the feature whose binaries
you have removed from the installation, you can do this by using the
Install-WindowsFeature cmdlet. When you use this cmdlet, you must
specify a source where Windows Server 2012 installation files are
located. To do this, you can either include the Source option to
specify a path to a Windows Imaging (WIM) mount point, or you can leave
out this option and let Windows use Windows Update as the source
location.
DHCP servers are a critical part of the network infrastructure of
most organizations. Therefore, ensuring that a DHCP server is always
available to assign IP addresses to hosts on every subnet is essential.
In previous versions of Windows Server, two approaches could be used to ensure the availability of DHCP servers. First, two DHCP servers can be clustered together using Failover
Clustering so that the second server could take over the load should
the first one fail. The problem with this approach, however, is that
clusters are often using shared storage that can be a single point of
failure for the cluster. Providing redundant storage is a solution, but
it can add significant cost to this approach. Configuring a failover
cluster is also not a trivial task.
The other approach is to use split scope approach in which 70
percent to 80 percent of the addresses in each scope are assigned to
the primary DHCP server, while the remaining 30 percent to 20 percent
are assigned to the secondary DHCP server. This way, if a client can’t
reach the primary server to acquire an address, it can get one from the
secondary server. This approach also has problems, however, because it
does not provide for continuity of IP addressing, is prone to possible
overlap of scopes due to incorrect manual configuration, and is
unusable when the scope is already highly used.
The DHCP Server role in Windows Server 2012 solves these problems by providing a third approach to ensuring DHCP server availability. This approach is called DHCP failover, and it enables two DHCP
servers to replicate lease information between them. That way, one of
the DHCP servers can assume responsibility for providing addresses to
all the clients on a subnet when the other DHCP server becomes
unavailable.
