Windows Server 2008 R2 Unleashed (140 page)

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

Summary

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

Best Practices

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

CHAPTER 21

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

Understanding Shells

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.