As a systems administrator, you're well aware of how busy you are. If you're
not putting out four-alarm fires, you're playing catch-up on last month's and
maybe even last year's projects. The idea that you can squeeze anything else
into your schedule seems as preposterous as Microsoft Bob 5.0. Yet there's one
technology that's well worth making time for—Windows PowerShell, an interactive
scripting and command-shell environment that lets you automate administrative
tasks and access a wide range of information.
With PowerShell, you can run commands directly at the command prompt or run
scripts that contain those commands. PowerShell supports its own scripting language,
which leverages the Microsoft .NET object model to combine the rich features
of object-oriented programming with the ease of command-shell scripting. What
that means for you is a powerful environment that can turn complex and repetitive
tasks into simple operations. Through PowerShell, you can access a variety of
systems and technologies, such as Active Directory (AD) and Windows Management
Instrumentation (WMI) to perform such tasks as retrieving event log entries,
disabling user accounts in AD, and retrieving a computer's user-defined shares.
PowerShell runs on Windows Vista, Windows Server 2003 SP1, Windows Server 2003
Release Candidate 2 (R2), and Windows XP SP2. It will also run on Windows Server
2008 (formerly code-named Longhorn Server). You can install PowerShell on x86,
x64, and IA64 processor architectures. However, before you install PowerShell,
you must first install Microsoft .NET Framework 2.0. You can download the .NET
Framework at http://msdn2.microsoft.com/en-us/netframework/aa569263.aspx
and PowerShell at http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx.
To install either product, simply run the setup program and follow the steps
in the installation wizard.
After you've installed PowerShell, you're ready to go. Click Start, All Programs,
Windows PowerShell 1.0, then Windows PowerShell. In the PowerShell window, you
can run commands or PowerShell scripts (.ps1) files by entering the command
or filename at the command prompt. To test your installation, type
get-help
at the command prompt and press Enter. This displays information about getting
help in PowerShell—a handy command to be sure. (For more cmdlets that
are helpful when learning PowerShell, see the sidebar "PowerShell
Pointers.")
You're now ready to run commands and scripts. All you need to do is to learn
a little about the PowerShell language. To help you with that, I'll review three
sample scripts—RetrieveAppEvents.ps1, DisableUser.ps1, and FindShares.ps1—that
demonstrate many of the basic concepts in the language and show you how easy
it is to get started with PowerShell.
RetrieveAppEvents.ps1
RetrieveAppEvents.ps1 in Listing 1 retrieves
entries from the local application event log and saves them to a text file.
As callout A shows, I begin the script by defining the $date variable. A dollar
sign always precedes parameter and variable names. The variable uses the Get-Date
cmdlet to retrieve the current date and time (aka datetime). A cmdlet, which
is similar to a function, performs a specific action and usually takes the form
of verb-noun. I then use the AddDays method to obtain the datetime exactly
24 hours (i.e., 1 day) prior to the current datetime and assign that value to
the $date variable.
Next, I create the FormatEntryType function, as callout B shows. A function is a named
block of code that performs a specific action.
After you create the function, you can reference
it anywhere in your script and the block of code
will run. In this case, the FormatEntry function
retrieves the content of a text file, modifies
that content, and saves it to a second text file.
The function takes the $file parameter, which
passes the pathname of the target text file into
the function.
The first command in the function's statement block (enclosed in curly brackets)
uses the Get-Content cmdlet to retrieve content from the text file in $file.
Notice that a pipe (|) follows the cmdlet. This indicates that the content should
be passed down the pipeline to the next cmdlet. One feature that makes PowerShell
so useful is the ease with which you can create pipelines to pass information
from one statement to the next.
In this function, I pass the data retrieved by Get-Content down the pipeline
to a ForEachObject cmdlet, for which you can use the alias ForEach or %. The
ForEach cmdlet lets you iterate through objects within a collection. In this
case, the collection is made up of the content of the text file. By default,
the objects in a file collection are delineated by line breaks, which means
the collection contains one object per line. (You can override the default behavior,
but for the purposes of this example, line breaks work well.)
The ForEach cmdlet uses an expression,
enclosed in curly brackets, to process each
object in the collection. The expression begins
with the $_ symbol, which refers to the current
input object from the collection. The expression then uses the -replace operator to replace
any error object with an *** ERROR *** object.
In other words, any line that contains only the
word error is replaced with *** ERROR ***. A
second ForEach cmdlet performs a similar
operation on warning objects.
The second ForEach cmdlet pipes the content to the Out-File cmdlet, which sends the
content to the AppEvent_EntryTypes.txt file.
Each time you run the function within a script,
the content will be inserted into that file.
The code at callout C retrieves the application event entries and assigns the results to
the $events variable. To retrieve data from the
application events log, I use the Get-Eventlog
cmdlet and specify Application as a parameter.
I then send the event data down the pipeline to
the Where-Object cmdlet. The backtick (`) at
the end of the line indicates that the statement
continues to the next line. However, you don't
have to use a backtick when a line breaks at a
pipe.
Previous
Register
