Managing Windows 2012 with Performance and Reliability Monitoring Tools
Windows Server 2012 continues to extend the
support for viewing, identifying, reporting on, and assisting in the
monitoring of the Windows-based environment. Windows performance and
reliability monitoring tools help network administrators better
understand the health and operations of Windows Server 2012 systems.
Just as with the Group Policy Management Console, you can launch the
Reliability and Performance Monitor from the Server Manager console.
When you click Tools, Performance Monitor, the tool displays a screen
similar to what is shown in Figure 5.
Figure 5. Performance Monitor console.
The new tool keeps track of system activity
and resource usage and displays key counters and system status on
screen. The Reliability Monitor diagnoses potential causes of server
instability by noting the last time a server was rebooted, what patches
or updates were applied, and when (chronologically) services have
failed on the system so that system faults can potentially be traced
back to specific system updates or changes that occurred prior to the
problem.
Using this combination (in single
console) of what used to be three or four tools back in Windows 2003,
administrators can now look at system performance, operational tasks,
and historical event information as they analyze a server problem or
system instability.
Leveraging the Best Practice Analyzer
Included in Windows Server 2012 is a built-in Best Practice Analyzer (BPA), shown in Figure 6.
Found in the Server Manager console tool, the BPA runs a series of
tests against Active Directory roles, such as the Hyper-V role, the DNS
role, and the RDS role, to assess whether the role has been installed
and configured properly and to compare the installation with tested
best practices.
Figure 6. BPA in the Server Manager console.
BPA results might tell
administrators they need to add more memory to a server, move a role to
a separate server to improve role optimization, or shift a database to
a different drive on the server to distribute disk performance demands
on the system.
Windows Deployment Services Integration
Windows Server 2008 introduced a new tool
called Windows Deployment Services (WDS), which was formerly known as
Remote Installation Services (RIS) in earlier versions of Windows
Server. Unlike RIS, which was focused primarily on scripted
installations and client images, WDS in Windows Server 2012 can
distribute images of Windows 7 and Windows 8 clients or Windows Server
2008 and 2012 servers in a significantly more flexible and modifiable
deployment process.
Like RIS, WDS allows a client system to
initiate a Preboot Execution Environment (PXE), effectively “booting”
to the WDS server to see a list of images that can be deployed on the
system. Alternatively, an organization can create a Windows PE boot
disc and have an image initiated from a CD or DVD.
With Windows Server 2008/2012 and
Windows 7/8, the image can be created in Windows Imaging (WIM) format,
which allows for the injection of patches, updates, or even new code to
a WIM file without even booting the image file. This provides the
organization with more than just static images that get pushed out like
in RIS, but rather a tool that provides ongoing and manageable updates
to image files.
Distributed File System Replication
Introduced in Windows 2000, improved in
Windows 2003 and 2008, and now a core component of the branch office
offerings in Windows Server 2012, Distributed File System Replication
(DFSR) allows files to be replicated between servers, effectively
providing duplicate information in multiple locations. In most
organizations, files are distributed across multiple servers throughout
the enterprise. Users access file shares that are geographically
distributed, but can also access file shares sitting on several servers
in a site within the organization. In many organizations, when file
shares were originally created years ago, server performance, server
disk capacity, and the workgroup nature of file and print server
distribution created environments in which those organizations had a
file share for every department and every site. So, files have
typically been distributed throughout an entire organization across
multiple servers.
Windows Server 2012 DFSR enables an
organization to combine file shares to fewer servers and create a file
directory tree not based on a server-by-server or share-by-share basis,
but rather an enterprisewide directory tree. This allows an
organization to have a single directory spanning files from multiple
servers throughout the enterprise.
Because the DFSR directory is a logical
directory that spans the entire organization with links back to
physical data, the actual physical data can be moved without having to
make changes to the way the users see the logical DFS directory. This
enables an organization to add or delete servers, or move and
consolidate information, however it works best within the organization.
For branch office locations, DFSR allows for
data stored on a file server in a remote location to be trickled back
to the home office for nightly backup. Instead of having the remote
location responsible for data backup, or the requirement of an
organization to have tape drives in each of its branch offices, any
data saved on the branch office can be trickle replicated back to a
share at the main office for backup and recovery.
If the main office has data that it wants to
push out to all remote offices, whether that is template files, company
policy documents, standard company materials, or even shared data that
a workgroup of users needs to access and collaborate on, DFSR provides
the ability to push out data to other servers on the network. Users
with access rights to the data no longer have to go across a WAN
connection to access common data. The information is pushed out to a
server that is more local to the user, and the user accesses the local
copy of the information. If any changes are made to remote or
centralized copies of data, those changes are automatically
redistributed back to all volumes storing a copy of the data.
One of the enhancements made in Windows
Server 2008 and extended in Windows Server 2012 specific to DFSR is the
ability for an administrator to set a DFS replica to be read-only. In
the past, DFS replicas were all read/write replicas, and so a user in a
remote location could accidentally overwrite files that would then
replicate to all replicas in the environment. Administrators have
compensated for this potential issue by setting file-level permissions
across files and folders; however, for many remote branch offices, if
the administrator could simply make the entire replica read-only, it
would simplify the security task dramatically. Therefore, read-only
replicas can now be set so that an entire server or branch of a DFS
tree can be set to replicate to a remote server on a read-only basis.
