Windows Server 2008 was the
first Operating System that came with PowerShell 1.0 by default,
although it was available as a download as far back as Windows Server
2003. In case you don't know about it, PowerShell is a very potent
command-line interface which can be used to fully manage your Windows
server, and the first Microsoft application to fully utilize it was
Exchange Server 2007; the Exchange Management Shell is actually a
superset of commands built on top of PowerShell. Product Teams within
Microsoft create their own Management Shell solutions, and Exchange
Server was one of the first products building theirs. Naturally, there
are other tools with Management Shells, such as the System Center
products for example, and many of them are also built on top of
PowerShell.
Exchange Server 2010 uses PowerShell version 2 (as
does Exchange Server 2007 SP2), and in addition to the command-line
interface this version also has an "Integrated Scripting Environment,"
which is an integrated graphical user interface that can be used to
easily create PowerShell scripts. As I mentioned earlier, PowerShell 2.0
is also integrated with Windows Remote Management (WS-MAN), making it
possible to use PowerShell to remotely manage your Exchange 2010
environment using the standard HTTPS protocol. All that's needed is a
workstation or a server that has PowerShell version 2 installed on the
workstation!
Even the Exchange Management Console uses the Management Shell (i.e. is written on top of it), and so there are some functions which are not available in the Console but are
available in the Shell, such as Attachment Filtering in the anti-spam
options. As the Exchange Management Shell is the primary management tool
in Exchange Server 2010 (as it was in Exchange Server 2007), this
development direction may hurt a little bit if you're a diehard GUI
administrator.
When the Exchange Management Shell is started, you'll
basically see an empty box with just a command prompt – exactly like
the Windows command prompt. You can get a list of all available commands
at this stage by entering Get-Command.
For the benefit of those diehard GUI administrators, a
PowerShell command consists of two parts: a Noun and a Verb. Verbs can
be instructions like get, set, new, remove, enable, disable etc., and
the Noun component can be any objects in Exchange Server. Just combine
the Noun and the Verb like this:
Get-ExchangeServer – retrieve a list of all Exchange 2010 Servers in the organization.
Set-MailboxDatabase – set a property on a Mailbox Database.
New-Mailbox – create a new mailbox enabled User.
Remove-Mailbox – deletes a user object and its mailbox.
If you want to learn more about PowerShell commands, a quick web search will turn up scores and scores of learning resources.
NOTE
Besides the Exchange
Management Shell, there's also the Windows 2008 PowerShell on your
server or workstation. If you start the PowerShell instead of the
Exchange Management Shell, you'll see a Command Prompt with a blue
background, and the Exchange Server 2010 cmdlets won't be available. If
you are new to PowerShell and the Exchange Management Shell, there will
be a day when you start the wrong Shell.
1 Exchange Management Shell help
If there's anything you're not sure about when you're
using the EMS, you have a friend in the form of the Quick Reference
Guide, located in C:\Program
Files\Microsoft\ExchangeServer\v14\bin\en\ExQuick.htm. This contains the
most important and most-used cmdlets, and their variables.
If you need help on the fly, it's also possible to
use the Shell's built-in help function. To get a list of all available
help items, just type help *. If you need help about a specific cmdlet, just type help and the name of the cmdlet. To get help about mail-enabling an existing user, for example, just type help enable-mailbox.
2 Pipelining
Another great feature in PowerShell and the Exchange Management Shell is the pipelining
function, which uses the output of one cmdlet as the input for a second
command. This can drastically reduce the amount of work you need to put
in to accomplish relatively complex tasks, and is more or less just
limited by your own ingenuity.
For example, if you want to move all mailboxes in a mailbox database called "Mailbox Database 1988197524" to another mailbox database called "Mailbox Database 0823751426", you can use the following command:
This is what happens:
Get-Mailbox –Database "Mailbox Database 1988197524"
retrieves a list of all mailboxes in this particular database. The
output of this cmdlet is used as the input of the second cmdlet, the
request to online move mailboxes to the other database. It's also
possible to use more specific queries. For example, to get a list of all
mailboxes whose name starts with "Chris" you would use the following
command:
You can then use this as the input for a request to move all these mailboxes to another database:
3. Bulk user creation in the Exchange Management Shell
This can be very useful, particularly when you need
to create a lot of mailboxes in a hurry. Suppose you have an
Organizational Unit named "Sales" in Active Directory, where 100 user
objects reside. This command will create a mailbox for each user in this
Organizational Unit:
When there are multiple Organizational Units called "Sales" you have to specify the complete path of the Organizational Unit:
It's also possible to filter the output of the
Get-User command with the –Filter parameter. For example, to
Mailbox-Enable all users whose company attribute is set to "Inframan,"
enter the following command:
If you want to be even more specific, for example to
Mailbox-Enable all users whose company attribute is set to "Inframan"
and whose department attribute is set to "Intern," enter the following
command:
The following operations are available for the –Filter option:
In some cases, you'll find it useful to import a list
of users from a .CSV file. This list can be exported from another
Active Directory or even from an HR (Human Resources) application. It is
actually relatively easy to import a .CSV file using PowerShell; the
only thing that you need to be mindful of is that the –Password option
doesn't accept clear text input. The input to this field has to be
converted to a secure string:
On the first three lines, three parameters are set
that are used during the actual creation of the user and the mailbox.
The file is read in a ForEach loop, and the actual users and the
mailboxes are created as this loop progresses.
The SecurePassword
function reads the password from the output .CSV file and converts it
into a secure string which is used, in turn, as the password input
during the creation of the users. The .CSV file itself is formatted like
this:
To make this script usable, save the script file as "create.ps1" in a directory like c:\scripts. You'll also need to save the .CSV output file as users.csv
in the same directory. To actually use the script, open a PowerShell
command prompt, navigate to the c:\scripts directory and enter the
following command:
