After updating AD information, you must
commit the changes, so I call the $user object's
SetInfo method. I then display two messages
by using the Write-Host cmdlet. The first message says the account has been disabled. The
second message displays the account's distinguished name (DN).
The code in callout E highlights the final
part of the script, which is an Else statement
block. The Else statement runs when the If
condition evaluates to false. For this script, the
Else statement uses the Write-Host cmdlet to
display a message that says the user account
wasn't found.
That's all there is to DisableUser.ps1. When you run this script, you must
have access to the AD store. I tested this script on a computer running Windows
2003 Enterprise Edition that was configured as a domain controller (DC). I also
tested the script on an XP machine against a Windows 2000 DC.
FindShares.ps1
FindShares.ps1, which Listing 3 shows, retrieves
a list of the user-defined shares on a computer. Like DisableUser.ps1, FindShares.ps1
begins by defining a parameter. As callout A shows, the $computer parameter
passes the computer name to the script when you run it. However, the parameter
uses a default value rather than returning an error message when a parameter
isn't provided. In this case, the default value is a period, which refers to
the local computer.
The code in callout B uses the Get-WmiObject cmdlet to create a WMI object.
The cmdlet uses the -Class option to specify the Win32_ Share class, the -Namespace
option to specify the root\CIMV2 namespace, and the -ComputerName option to
specify the computer name in $computer. Of these options, the -Class option
is the most important because it determines the type of information you can
access through the WMI object.
After accessing the WMI class information, I pass it down the pipeline to a
Where-Object cmdlet. The Where-Object expression, enclosed in curly brackets,
includes three conditions. The first condition uses the not equal (-ne) operator
to compare the Caption property's value to the phrase default share.
For the condition to evaluate to true, the property's value can't equal the
phrase. The second condition uses the -notlike operator to compare the Caption
property's value to the remote* value. Notice the use of the wildcard,
which can represent any characters. For the condition to evaluate to true, the
Caption property's value can't begin with the word remote, but it can
end with any characters. The final condition is similar to the second condition,
except that the Caption property's value can't begin with the word logon.
The Where-Object expression uses the -and logical operator to link the
three conditions, which means that they all must be true for a share to be included
in the list. I pass the filtered list down the pipeline to a Sort-Object cmdlet,
which sorts the list of shares based on the Name property (by default, in ascending,
or alphabetical, order). I assign the sorted WMI information to the $shares
variable.
The code in callout C is an If statement block. The If condition ($shares -ne
$null) uses the -ne operator and the $null system variable to specify that the
$shares variable can't contain a null value. When the $shares variable's value
isn't null (i.e., the If condition evaluates to true), the If statement block
runs.
The If statement block begins with the Write-Host cmdlet. Because the cmdlet
specifies no content, it simply returns a blank line. This provides extra spacing
to better display the information in the PowerShell window.
The next statement is a ForEach statement. The ForEach statement isn't the
same as the ForEach-Object cmdlet, even though they perform the same function.
Adding to the confusion is the fact that one of the ForEachObject cmdlet's aliases
is ForEach. Here's how you can tell them apart: When ForEach is at the beginning
of a command, it's a ForEach statement. When ForEach is within a pipeline, it's
a ForEach-Object cmdlet.
The ForEach statement iterates through the objects (i.e., shares) in the $shares
collection. The statement defines the $share variable, which refers to the current
object. The ForEach expression uses the $share variable to take action on each
object. The first command in the ForEach expression is a Write-Host cmdlet that
writes the Name property's value to the PowerShell window. The script accesses
the name property through the $share variable. The second WriteHost cmdlet writes
the Path property's value to the PowerShell window. The final Write-Host cmdlet
simply adds a line after each iteration to make it easier to read the list of
shares.
When the If condition ($shares -ne $null) evaluates to false, the Else statement
block in callout D runs. The Else statement block contains its own If and Else
statement blocks. The nested If condition specifies that the computer name must
equal a period. When the computer name is a period, Write-Host uses the COMPUTERNAME
environmental variable to return the name. Note that to access an environmental
variable, you must precede the variable name with $env:. When the computer name
isn't a period, Write-Host returns the name stored in $computer.
When you run FindShares.ps1, you'll obtain a list of shares. Figure
2 shows sample output from this script.
Only Scratching the Surface
As you can see, with PowerShell, you have a lot of flexibility in the type of
information that you can access and what you can do with that information. These
three examples of how to use PowerShell only scratch the surface. The more effort
you devote to learning PowerShell, the greater your payoff will be. And who
knows, with these new skills, you might have time to complete last year's projects.