4. Using common and user-defined variables
PowerShell includes a number of variables you will use a lot. $True and $False are variables you can pass to shell commands and scripts to check for true and false conditions. Usually, $True is equivalent to setting a check box for an option in EMC, and $False is equivalent to clearing a check box. If you prefer numeric values, you can replace $True and $False with 1 (one) and 0 (zero), respectively. Other global variables you commonly meet as you work with PowerShell include $Null (no value), $home, which returns the user’s home folder, and $pwd, which returns the current working folder. Important Exchange variables include the following:
$ExBin. Points
to the directory in which Exchange binaries and other important files
are kept. On an Exchange 2013 server, this variable normally resolves
to disk: \Program Files\Microsoft\Exchange Server\V15\bin.
$ExScripts. Points
to the directory in which important Exchange .ps1 scripts are kept. On
an Exchange 2013 server, this variable resolves to disk: \Program
Files\Microsoft\Exchange Server\V15\Scripts.
$ExInstall. Points
to the root directory for Exchange. On an Exchange 2013 server, this
variable resolves to disk: \Program Files\Microsoft\Exchange Server\V15.
You can use these variables to access files in these directories. For example, to see a list of scripts Exchange provides, type Dir $ExScripts.
Checking that a value is $True or $False
is a common occurrence. For positive conditions, you can shorten the
check by just passing the property against which to check, and
PowerShell will assume that you want to check whether it is true. For
example, assume that you want to find out which mailboxes are enabled
to use Outlook Web App. You can use this command and, as you can see,
there is no mention of $True, but it works:
Get-CASMailbox | Where-Object {$_.OWAEnabled} | Select NameNote the use of $_ in the last command. $_
is a very important variable because it points to the current object in
the pipeline. Scripting languages on other platforms such as UNIX and
Linux also support pipelines, which compose complex commands by
allowing the output of one command to be passed as the input to
another. The | operator indicates that a pipeline is in place. Data are
passed as fully formed objects rather than as a text stream. This
enables PowerShell to operate on the full structure of data that are
pipelined, including the attributes and types that define the objects
piped from one cmdlet to another.
For
example, if you create a filter to look for people in a certain
department because you want to update the name of the department, you
might do this:
Get-User | Where-Object {$_.Department –eq 'Legal'} | Set-User –Department 'Law'The
Department property is prefixed with $_ to indicate that you want to
check this property for every object the call to Get-User passes
through the pipeline. You actually use $_. as the prefix because it
includes the “.” operator to specify that you want to access a
property. If you just passed $_ the comparison would not work because
PowerShell would compare “Legal” against the complete object.
User-defined
variables can be integer, decimal, or string—you decide by passing a
value to the variable you want to use. For example:
$Tony = 'Tony Redmond'
$Figure = 15.16
This
creates a string variable, and the second variable holds a decimal
value. Variables are case-insensitive and case-preserving. Using the
preceding example, you can refer to $Tony as $TONY or $tony or even
$ToNY, and PowerShell will refer to the same variable. Variables are
local unless you declare them to be global by prefixing them with
Global, as in:
$Global:Tony = 'Tony Redmond'
When a variable is global, you can reference it interactively and in scripts you can call from anywhere.
Tip
Do
not include hyphens when you name variables because PowerShell
interprets the hyphens as parameters. In other words, $ServerName is a
good name for a variable, but $Server-Name is not.
Like any
good scripting language, PowerShell supports conditional checking with
IF and ELSEIF that you will mostly use in scripts. It’s easy to
generate code that goes through a certain number of iterations with
constructs such as 1..100 | ForEach-Object <command…>.
5. Using PowerShell ISE with Exchange
If you don’t like the bare-bones nature of EMS, you might
prefer to use ISE, the PowerShell Integrated Scripting Environment. ISE
is installed on Windows 2008 R2 SP1 and Windows 2012 servers to provide
a GUI for PowerShell that allows users to write, test, and debug
scripts. PowerShell ISE is also installed by default on Windows 7 and
Windows 8 workstations.
ISE supports multiline editing, tab
completion, syntax coloring (or highlighting of different parts of
commands), context-sensitive help, and keyboard shortcuts. Because of
its debug features, ISE is a good way to write complex scripts for use
with Exchange 2013.
When you start ISE, it has no knowledge of Exchange
or how to create the kind of remote session with an Exchange server in
the way EMS does when it starts. Some work is therefore necessary to
integrate ISE with Exchange. The easiest way to do this is to insert
some code in the PowerShell profile so that ISE learns enough about
Exchange when it initializes to access Exchange when you need it to.
The
code you need to use with ISE is very similar to the code you met
earlier when discussing the basics of creating a remote PowerShell
session. Start ISE and type Notepad $Profile
to edit your PowerShell profile, and then insert the following code
(amending the reference to contoso.com to reflect your own environment):
$PSISE.CurrentPowerShellTab.AddOnsMenu.SubMenus.Add(
"Connect to Exchange", {
$user = Get-Credential
$Server = Read-Host "Connect to what Exchange server "
$connectpoint = $Server + ".contoso.com/PowerShell/"
$ExSession= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
$connectpoint -Credential $user
Import-PSSession $ExSession
},
"Control+Alt+1"
)
The
code defines a new menu choice called Connect to Exchange that appears
on the ISE Add-ins menu. The option can also be invoked with the
Control/Alt/1 key combination. In either case, when invoked, the code
prompts for user credentials and the server to which to connect and
then initiates a new remote PowerShell session with the selected
Exchange server. After the connection is established, you can work as
with EMS except that extra information and facilities are available to
you, such as a context-sensitive list of cmdlets that appears when you
start typing a cmdlet name (Figure 2).
