Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
become outdated as the environment, processes, and procedures change as the business
changes.
ptg
Quarterly Maintenance
As the name implies, quarterly maintenance is performed four times a year. Areas to main-
tain and manage on a quarterly basis are typically fairly self-sufficient and self-sustaining.
Infrequent maintenance is required to keep the system healthy. This doesn’t mean,
however, that the tasks are simple or that they aren’t as critical as those tasks that require
more frequent maintenance.
Checking Storage Limits
Storage capacity on all volumes should be checked to ensure that all volumes have ample
free space. Keep approximately 25% free space on all volumes.
Running low or completely out of disk space creates unnecessary risk for any system.
Services can fail, applications can stop responding, and systems can even crash if there
isn’t plenty of disk space.
Changing Administrator Passwords
Administrator passwords should, at a minimum, be changed every quarter (90 days).
Changing these passwords strengthens security measures so that systems can’t easily be
20
compromised. In addition to changing passwords, other password requirements such as
password age, history, length, and strength should be reviewed.
696
CHAPTER 20
Windows Server 2008 R2 Management and Maintenance Practices
Although administrators can easily get caught up in daily administration and firefighting,
it’s important to structure system management and maintenance of Windows Server 2008
R2 to help prevent unnecessary amounts of effort. Windows Server 2008 R2 provides
many tools, such as the server roles and Server Manager, to enable administrators to more
effectively manage their servers.
Server Manager is a one-stop shop for the management and monitoring of most of the
functions of a Windows Server 2008 R2 server. The operating system automatically adds
the appropriate snap-ins to manage the features and the roles that are installed on the
server as they are installed. This makes it the home base for administrators and simplifies
their tasks by placing the tools and techniques in a single location.
Systems management and maintenance is not just about the cool technologies, but also
about how those technologies are used. Following a management and maintenance
regimen reduces administration, maintenance, and business expenses, while at the same
time increasing reliability, stability, and security.
ptg
The following are best practices from this chapter:
. Use System Manager as the central point of administration for Windows Server 2008
R2 servers.
. Manage servers based on their roles.
. Try to maintain the network environment’s systems periodically to avoid any ineffi-
ciency.
. Audit not only to identify security breaches or suspicious activity, but also to gain
insight into how the network, network devices, and systems are accessed.
. Enable audit policies through the local system policy or Group Policy Objects.
. Remotely manage systems using Role and Feature tools, Remote Desktop for
Administration, scripting, Windows Remote Management, and command-line utilities.
. Use System Center Operations Manager 2007 to proactively manage Windows
Server 2008 R2.
. Identify tasks that are important to the system’s overall health and security.
. Install the appropriate service packs and updates on each production server and
client machine to keep all systems consistent.
. Thoroughly test and evaluate service packs and updates in a lab environment before
installing them on production servers.
Best Practices
697
. Use Windows Software Update Services to minimize administration, management, and
maintenance associated with keeping up with the latest service packs and updates.
. Distribute the service packs and hotfixes downloaded from WSUS to a lab server
for testing.
. Categorize and document daily maintenance activities, such as checking server func-
tionality, verifying that backups were successful, and monitoring Event Viewer events.
. Categorize and document weekly maintenance processes and procedures, such as
checking disk space, verifying hardware operation, archiving event logs, defragment-
ing volumes, and diagnosing domain controllers with DCDIAG.
. Categorize and document monthly maintenance processes and procedures, such as
maintaining file system integrity, testing UPS functionality, validating backups,
updating ASR sets, and updating documentation.
. Use the Data Collector Sets and reports to analyze server performance and pinpoint
problems and resource issues.
. Categorize and document quarterly maintenance processes and procedures, such as
checking storage limits and changing administrative passwords.
ptg
20
This page intentionally left blank
ptg
IN THIS CHAPTER
Automating Tasks Using
. Understanding Shells
. Introduction to PowerShell
PowerShell Scripting
. Understanding the PowerShell
Basics
. Using Windows PowerShell
Shells are a necessity in using operating systems. They give
the ability to execute arbitrary commands as a user and the
ability to traverse the file system. Anybody who has used a
computer has dealt with a shell by either typing commands
at a prompt or clicking an icon to start a word processing
application. A shell is something that every user uses in
some fashion. It’s inescapable in whatever form when
working on a computer system.
ptg
Until now, Windows users and administrators primarily
have used the Windows Explorer or cmd command prompt
(both shells) to interact with most versions of the Window
operating systems. With Microsoft’s release of PowerShell,
both a new shell and scripting language, the current stan-
dard for interacting with and managing Windows is rapidly
changing. This change became very evident with the release
of Microsoft Exchange Server 2007, which used PowerShell
as its management backbone, the addition of PowerShell as
a feature within Windows Server 2008, and now the inclu-
sion of PowerShell as part of the Windows 7 and Windows
Server 2008 R2 operating systems.
In this chapter, we take a closer look at what shells are and
how they have developed. Next, we review Microsoft’s past
attempts at providing an automation interface (WSH) and
then introduce PowerShell. From there, we step into under-
standing the PowerShell features and how to use it to
manage Windows 2008. Finally, we review some best prac-
tices for using PowerShell.
700
CHAPTER 21
Automating Tasks Using PowerShell Scripting
A shell is an interface that enables users to interact with the operating system. A shell isn’t
considered an application because of its inescapable nature, but it’s the same
as any other process running on a system. The difference between a shell and an applica-
tion is that a shell’s purpose is to enable users to run other applications. In some operating
systems (such as UNIX, Linux, and VMS), the shell is a command-line interface (CLI); in
other operating systems (such as Windows and Mac OS X), the shell is a graphical user
interface (GUI).
Both CLI and GUI shells have benefits and drawbacks. For example, most CLI shells allow
powerful command chaining (using commands that feed their output into other
commands for further processing; this is commonly referred to as the pipeline). GUI
shells, however, require commands to be completely self-contained. Furthermore, most
GUI shells are easy to navigate, whereas CLI shells require a preexisting knowledge of the
system to avoid attempting several commands to discern the location and direction to
head in when completing an automation task. Therefore, choosing which shell to use
depends on your comfort level and what’s best suited to perform the task at hand.
NOTE
ptg
Even though GUI shells exist, the term “shell” is used almost exclusively to describe a
command-line environment, not a task that is performed with a GUI application, such
as Windows Explorer. Likewise, shell scripting refers to collecting commands normally
entered on the command line or into an executable file.
A Short History of Shells
The first shell in wide use was the Bourne shell, the standard user interface for the UNIX
operating system; UNIX systems still require it for booting. This robust shell provided
pipelines and conditional and recursive command execution. It was developed by C
programmers for C programmers.
Oddly, however, despite being written by and for C programmers, the Bourne shell didn’t
have a C-like coding style. This lack of similarity to the C language drove the invention of
the C shell, which introduced more C-like programming structures. While the C shell
inventors were building a better mousetrap, they decided to add command-line editing
and command aliasing (defining command shortcuts), which eased the bane of every
UNIX user’s existence: typing. The less a UNIX user has to type to get results, the better.
Although most UNIX users liked the C shell, learning a completely new shell was a chal-
lenge for some. So, the Korn shell was invented, which added a number of the C shell
features to the Bourne shell. Because the Korn shell is a commercially licensed product,
the open source software movement needed a shell for Linux and FreeBSD. The collabora-
tive result was the Bourne Again shell, or Bash, invented by the Free Software Foundation.
Understanding Shells
701
Throughout the evolution of UNIX and the birth of Linux and FreeBSD, other operating
systems were introduced along with their own shells. Digital Equipment Corporation
21
(DEC) introduced Virtual Memory System (VMS) to compete with UNIX on its VAX
systems. VMS had a shell called Digital Command Language (DCL) with a verbose syntax,
unlike that of its UNIX counterparts. Also, unlike its UNIX counterparts, it wasn’t case
sensitive, nor did it provide pipelines.
Somewhere along the way, the PC was born. IBM took the PC to the business market, and
Apple rebranded roughly the same hardware technology and focused on consumers.
Microsoft made DOS run on the IBM PC, acting as both kernel and shell and including
some features of other shells. (The pipeline syntax was inspired by UNIX shells.)
Following DOS was Windows, which went from application to operating system quickly.
Windows introduced a GUI shell, which has become the basis for Microsoft shells ever
since. Unfortunately, GUI shells are notoriously difficult to script, so Windows provided a
DOSShell-like environment. It was improved with a new executable, cmd.exe instead of
command.com, and a more robust set of command-line editing features. Regrettably, this
change also meant that shell scripts in Windows had to be written in the DOSShell syntax
for collecting and executing command groupings.
Over time, Microsoft realized its folly and decided systems administrators should have
better ways to manage Windows systems. Windows Script Host (WSH) was introduced in
ptg
Windows 98, providing a native scripting solution with access to the underpinnings of
Windows. It was a library that allowed scripting languages to use Windows in a powerful
and efficient manner. WSH is not its own language, however, so a WSH-compliant script-
ing language was required to take advantage of it, such as JScript, VBScript, Perl, Python,
Kixstart, or Object REXX. Some of these languages are quite powerful in performing
complex processing, so WSH seemed like a blessing to Windows systems administrators.
However, the rejoicing was short-lived because there was no guarantee that the WSH-
compliant scripting language you chose would be readily available or a viable option for
everyone. The lack of a standard language and environment for writing scripts made it
difficult for users and administrators to incorporate automation by using WSH. The only
way to be sure the scripting language or WSH version would be compatible on the system
being managed was to use a native scripting language, which meant using DOSShell and
enduring the problems that accompanied it. In addition, WSH opened a large attack
vector for malicious code to run on Windows systems. This vulnerability gave rise to a
stream of viruses, worms, and other malicious programs that have wreaked havoc on
computer systems, thanks to WSH’s focus on automation without user intervention.
The end result was that systems administrators viewed WSH as both a blessing and a
curse. Although WSH presented a good object model and access to a number of automa-
tion interfaces, it wasn’t a shell. It required using Wscript.exe and Cscript.exe, scripts had
to be written in a compatible scripting language, and its attack vulnerabilities posed a
security challenge. Clearly, a different approach was needed for systems management; over
time, Microsoft reached the same conclusion.