Windows Server 2008 R2 Unleashed (151 page)

ComputerName parameter, the client machine might become overwhelmed. To help prevent

the client machine or your network from drowning in an asynchronous connection

storm, the Invoke-Command cmdlet will, by default, limit the number of concurrent

remote connections for an issued command to 32. If you want to tweak the number of

concurrent connections allowed, you would use the ThrottleLimit parameter.

NOTE

The ThrottleLimit parameter can also be used with the New-PSSession cmdlet.

An important concept to understand when using the Invoke-Command cmdlet is how it

actually executes commands on a remote machine. By default, this cmdlet will set up

temporary runspace for each of the targeted remote machine(s). Once execution of the

specified command has finished, both the runspace and the connection resulting from

that runspace are closed. This means, irrespective of how the ThrottleLimit parameter is

used, if you are executing a number of different commands using the Invoke-Command

cmdlet at the same time, the actual number of concurrent connections to a remote

machine is the total number of times you invoked the Invoke-Command cmdlet.

Needless to say, if you want to reuse the same existing connection and runspace, you need

to use the Invoke-Command cmdlet’s Session parameter. However, to make use of the

Using Windows PowerShell

761

parameter requires an already existing runspace on the targeted remote machine(s). To

create a persistent runspace on a remote machine, you would use the New-PSSession

21

cmdlet, as shown in the following example:

PS C:\> new-pssession -computer “sc1-infra01”,”sc1-ad01”

After executing the previous command, two persistent runspaces on each of the specified

targets will have been created. These runspaces can then be used to complete multiple

commands and even share data between those commands. To use these runspaces, you

need to retrieve the resulting runspace object(s) using the Get-PSSession cmdlet and then

pass it into the Invoke-Command cmdlet. For example:

PS C:\> $Sessions = new-pssession -computer “sc1-infra01”,”sc1-ad01”

PS C:\> invoke-command -scriptblock {get-service “W32Time”} -session $Sessions | ft

PSComputerName, Name, Status

PSComputerName Name Status

------------ ---- ------

sc1-ad01 W32Time Running

sc1-infra01 W32Time Running

ptg

First, the $Sessions variable is used to store the two resulting runspace objects that are

created using the New-PSSession cmdlet. Next, the $Sessions variable is then defined as

the argument for the Session parameter of the Invoke-Command cmdlet. By doing this,

the command that is defined as the argument for the ScriptBlock parameter is executed

within each of the runspaces represented by the $Sessions variable. Finally, the results

from the command executed within each of the runspaces is returned and piped into the

Format-Table cmdlet to format the output. In this case, the output shows the current

status of the W32Time service on each of the specified remote machines.

After you have finished executing commands, it’s important to understand that the

runspaces that were created will remain open until you close the current PowerShell

console. To free up the resources being consumed by a runspace, you need to delete it

using the Remove-PSSession cmdlet. For example, to remove the runspaces contained in

the $Sessions variable, you would pass that variable into the Remove-PSSession cmdlet:

PS C:\> $Sessions | remove-pssession

Using the New-Object Cmdlet

The New-Object cmdlet is used to create both .NET and COM objects. To create an

instance of a .NET object, you simply provide the fully qualified name of the .NET class

you want to use, as shown here:

PS C:\> $Ping = new-object Net.NetworkInformation.Ping

By using the New-Object cmdlet, you now have an instance of the Ping class that

enables you to detect whether a remote computer can be reached via Internet Control

762

CHAPTER 21

Automating Tasks Using PowerShell Scripting

Message Protocol (ICMP). Therefore, you have an object-based version of the Ping.exe

command-line tool.

To an instance of a COM object, the comObject parameter is used. To use this parameter,

define its argument as the COM object’s programmatic identifier (ProgID), as shown here:

PS C:\> $IE = new-object -comObject InternetExplorer.Application

PS C:\> $IE.Visible=$True

PS C:\> $IE.Navigate(“www.cnn.com”)

Summary

In this chapter, you have been introduced to PowerShell, its features, concepts, and how it

can be used to manage Windows. Of all the topics and items covered in this chapter, the

most important concept that should be remembered is that PowerShell should not be

feared—rather, it should be used. The PowerShell team has produced a CLI shell that is

easy and fun to use. With practice, using PowerShell should become second nature.

After all, the writing is on the wall. With the inclusion of PowerShell in the Windows

Server 2008 R2 operating system and with the integration into its next generation of

products, Microsoft’s direction is toward embracing PowerShell. This trend toward all

ptg

things PowerShell is even clearer when looking at all the community-based projects and

third-party products being developed and released that use or enhance PowerShell. After

all, PowerShell is the answer that Microsoft has been seeking as the management interface

for Windows and its platform products. Thanks to a good feature set, which includes

being built around the .NET Framework, being object based, being developed with security

in mind, and so on, PowerShell is a powerful tool that should be part of any administra-

tor’s arsenal.

Best Practices

The following are best practices from this chapter:

. If a function needs to persist across PowerShell sessions, define that function within

your profile.ps1 file.

. To access block information about a base, use the BaseObject property with the

PSBase standard name.

. When naming a variable, don’t use special characters or spaces.

. When using aliases and variables in a script, use names that other people can

understand.

. If possible, try not to use aliases in a script.

. In a production environment, don’t configure the PowerShell execution policy as

unrestricted and always digitally sign your scripts.

. If built-in PowerShell cmdlets don’t meet your needs, always remember that you can

fall back onto existing automation interfaces (ADSI, WMI, COM, and so forth).

CHAPTER 22

IN THIS CHAPTER

Documenting a
. Benefits of Documentation

. Types of Documents

Windows Server 2008 R2
. Planning to Document the

Windows Server 2008 R2

Environment

Environment

. Knowledge Sharing and

Knowledge Management

As technology advances, we, as implementers, work to

. Windows Server 2008 R2

learn it, understand it, and figure out how to use it to make

Project Documents

our environments more reliable, more secure, and help end

. Administration and

users be more productive. We upgrade from one version of

Maintenance Documents

an application to the next, and although some of the tech-

nology becomes obsolete, the need for accurate documenta-

. Network Infrastructure

tion remains the same.

. Disaster Recovery

Documentation

Documentation serves several purposes throughout the life

ptg

cycle of the Windows Server 2008 R2 operating system and

. Change Management

is especially important for the planning and execution of a

Procedures

Windows Server 2008 R2 implementation project. In the

. Performance Documentation

initial stages of a project, it serves to provide a historical

record of the options and decisions made during the design

. Baselining Records for

Documentation Comparisons

process. During the testing and implementation phases,

documents such as step-by-step procedures and checklists

. Routine Reporting

guide project team members and help ensure that all steps

. Security Documentation

are completed. When the implementation portion of the

project is complete, support documentation plays a key role

in maintaining the health of the new environment. Support

documents include administration and maintenance proce-

dures, checklists, detailed configuration settings, and moni-

toring procedures.

This chapter is dedicated to providing the breadth and

scope of documentation for a Windows Server 2008 R2

environment. Equally important, it provides considerations

and best practices for keeping your messaging environment

well documented, maintained, and manageable.

764

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

Benefits of Documentation

Documentation that is developed with specific goals, and goes through a review or

approval process, is typically well organized, complete, and contributes to the overall

professionalism of the organization and its knowledge base. The following sections

examine some of the other benefits of professional documentation in the Windows Server

2008 R2 environment.

Organizational Benefits

Many of the benefits of documenting your Windows Server 2008 R2 environment are

obvious and tangible. Documentation is an integral part of the installation or design of a

Windows Server 2008 R2 environment as well as the maintenance, support, and recovery

of new or existing environments.

Other benefits can be harder to identify. For example, the process of putting the informa-

tion down on paper encourages a higher level of analysis and review of the topic at hand.

The process also encourages teamwork and collaboration within an organization and

interdepartmental exchange of ideas.

In today’s world of doing more with less, the intangible benefits of good documentation

ptg

can become a challenge to justify to upper management. Some key benefits of documenta-

tion include the following:

.
Collaboration—
Producing the documentation to support a good Windows Server

2008 R2 implementation requires input from departments across the organization.

This teamwork encourages deeper analysis and more careful review of the project

goals. With better base information, the project team can make more informed deci-

sions and avoid having to go back to the drawing board to address missed objectives.

.
Historical records—
Implementation projects are composed of several different

stages during which goals are identified and key decisions are made to support them.

It is important to make sure these decisions and their supporting arguments are

recorded for future reference. As the project moves forward, it is not uncommon for

details to get changed because of incomplete information being passed from the

design stage onto the implementation stage.

.
Training—
Life is ever changing. That might sound a bit philosophical for a book on

technology, but when it comes to people, we know that some of them move on to

other challenges. And that is when good documentation becomes an invaluable tool

to provide information to their replacement. This is equally true for the executive

sponsor, the project manager, or the engineer building the Windows server.

Financial Benefits

Proper Windows Server 2008 R2 documentation can be time consuming and adds to the

cost of a project. In addition, ongoing costs can come up for maintenance and disaster

recovery documents. In lean economic times for a company or organization, it is often

difficult to justify the expense of project documentation. However, when looking at docu-

Types of Documents

765

ments for maintenance or disaster recovery scenarios, it is easy to see that creating this

documentation makes financial sense. For example, in an organization where downtime

can cost thousands of dollars per minute, the return on investment (ROI) in disaster

recovery and maintenance documentation is easy to calculate. In a company that is

growing rapidly and adding staff and new servers on a regular basis, tested documentation

on server builds and administration training can also have immediate and visible benefits.

22

Financial benefits are not limited to maintenance and disaster recovery documentation.

Well-developed and professional design and planning documentation helps the organiza-

tion avoid costly mistakes in the implementation or migration process, such as buying too

many server licenses or purchasing too many servers.

Types of Documents

Each document should be created with a specific goal in mind and knowledge of the

target audience. The following list specifies the main document categories that are used to

implement a Windows Server 2008 R2 project and maintain the environment: