Exchange PowerShell Quickstart – Part 1

Background

As we know Microsoft is firmly banking on PowerShell to be THE way to manage all of their operating systems and services, and with good reason. PowerShell is the most powerful method Microsoft has developed to manage their products. The concepts are similar to Unix style shells but it is a little more easily understood when reading a PowerShell script compared to a Unix shell script. This readability does however give rise to a few inconsistencies since they need to ensure backward compatibility too. The biggest inconcistency is the names of properties (attributes) used in Exchange PowerShell, AD PowerShell and what the AD schema has internally. AD PowerShell closely aligns itself to the schema, for example both the schema and AD PowerShell know about proxyAddresses as an attribute. Exchange PowerShell uses the term EmailAddresses instead. To help ease that pain I have put a small table below of the more common Exchange PowerShell properties and their AD attribute counterpart

Exchange Name AD Attribute
Alias mailNickname
CustomAttribute1-15 extensionAttribute1-15
DeliverToMailboxAndForward deliverAndRedirect
DisplayName displayName
EmailAddresses proxyAddresses
EmailAddressPolicyEnabled msExchPoliciesIncluded or msExchPoliciesExcluded set to {26491cfc-9e50-4857-861b-0cb8df22b5d7}
ExtensionCustomAttribute1-5 msExchExtensionCustomAttribute1-5
ExternalEmailAddress targetAddress (for Mailuser and Mailcontact objects)
FirstName givenName
ForwardingAddress altRecipient
ForwardingSMTPAddress targetAddress (for Mailbox objects)
GrantSendOnBehalfTo publicDelegates
HiddenFromAddressListsEnabled msExchHideFromAddressList
LastName sn
LegacyExchangeDN legacyExchangeDN
Name sAMAccountName
WindowsEmailAddress mail

Terminology

PowerShell introduces many new terms which are worth listing just so that we’re all on the same page

  • cmdlet – a command in the form of <verb>-<noun>, e.g. Set-Mailbox to perform an action on an object. A cmdlet is usually made available to you through importing a module or connecting to a session
  • module – a module is a collection of PowerShell cmdlets which can be imported into a PowerShell window
  • pipeline – a single line of commands seperated by | (pipe symbol) where the commands pass the results from the cmdlet on the left to the next cmdlet to the right, e.g. Get-TransportServer | get-MessageTrackingLog which will get the messaging tracking log off all transport servers
  • script – A set of cmdlets that are to be executed as a single unit. These files usually have the ps1 extension
  • session – a session is a connection to a remote PowerShell uri which then makes available any cmdlets provided by that uri
  • variable – a way of storing results of a cmdlet for subsequent processing. In PowerShell variables always start with $

Connecting to Exchange

Right so that was a bit on the background of PowerShell and how there are some inconsistencies to be aware of. So let’s get connected. There are two main ways of connecting to Exchange PowerShell. The way that is often used is to log into an Exchange server and run the Exchange Management Shell. Behind the scenes this actually runs a PowerShell script into the default Windows PowerShell which sets the initial size of the PowerShell window, discovers an Exchange server and connects to it. We can use this idea to actually run PowerShell locally on a laptop and remotely connect to PowerShell with the following sort of script

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://mail.contoso.com/PowerShell/ -Authentication Kerberos

where the ConnectionURI needs to be a CAS server or load balanced CAS name. Using Kerberos will silently authenticate you based on your log in credentials. The combination of Kerberos with http will ensure that Exchange does still encrypt all of the traffic between the client and the server using Kerberos encryption.

The best way to get started with Exchange PowerShell is to explore the Get-* cmdlets, which can be done very safely. Note that if Exchange is installed in a multi-domain forest then you need to call Set-AdServerSettings -ViewEntireForest $true otherwise you will only see recipients from the current domain.

Getting Help

I find that my most commonly used cmdlets includes the following:

  • Get-Help To get help on a particular cmdlet, e.g. Get-Help Get-Mailbox -Detailed
  • Get-Command To find out what commands there are, e.g. Get-Help *mailbox*
  • Get-Member To find out what the direct cmdlets (methods) and properties for an object e.g. Get-Mailbox someone@contoso.com | Get-Member

The help information provided by Get-Help is pretty much the same as what you will find in Technet for each cmdlet

Some basic Commands

The list below is just a list of Exchange cmdlets that you need to be familiar with and they you will no doubt use most days

  • Get-ExchangeServer – Gets a list of all Exchange servers
  • Get-ClientAccessServer – Gets a list of all Exchange servers with the ClientAccess role
  • Get-TransportServer – Gets a list of all Exchange servers with the HubTransport role (up to Exchange 2010)
  • Get-MailboxServer – Gets a list of all Exchange servers with the Mailbox role
  • Get-UMServer – Gets a list of all Exchange servers with the Unified Messaing role
  • Get-MailboxDatabase – Gets a list of all mailbox databases on all servers
  • Get-MailboxDatabaseCopy – Gets a list of all mailbox database copies on all servers
  • Get-Mailbox – Gets a list of all mailboxes
  • Get-Recipient – Gets a list of all recipients
  • Get-DistributionGroup – Gets a list of all distribution groups
  • Get-Mailuser – Gets a list of all mail users (i.e. users with an email address, but with their mailbox hosted on another messaging environment)
  • Get-MailContact – Gets a list of all mail contacts (i.e. users with an email address and typically external to your organization)
  • Get-ReceiveConnector – Gets a list of all receive connectors
  • Get-SendConnector – Gets a list of all send connectors
  • Get-MailboxPermission – Gets the permissions set on the mailbox itself
  • Get-MailboxFolderPermission – Gets the permissions set on a specific folder within a mailbox
  • Get-MailboxStatistics – Gets the statistics for a mailbox
  • Get-MailboxFolderStatistics – Gets the statitics for folders within a mailbox
  • Get-MessageTrackingLog – Gets message tracking information from the message tracking logs
  • Get-Queue – Gets a list of all of the open message queues
  • Get-TransportConfig – Gets the Transport Configuration
  • Get-TransportRule – Gets a list of all of the transport rules
  • Get-JournalRule – Gets a list of all of the journal rules
  • Get-ADPermission – Gets the ad permissions set on an object (e.g. mailbox, mailbox database, send/receive connector, etc.)
  • Get-AcceptedDomain – Gets a list of all of the accepted domains
  • Get-RemoteDomain – Gets a list of all of the remote domains

There are many many more, so have a good browse around and use Get-Command and Get-Help to explore.

When it comes to creating, updating and deleting then PowerShell changes the first part of the cmdlet (known as the verb) These typically come in pairs such as add/remove, new/delete, enable/disable as well as set. Add/Remove are normally used to add an item to an existing object or remove it from an existing object, e.g. Add-ADPermission, Add-MailboxDatabaseCopy. New/Delete are used to create something brand new or delete it altogether, e.g. New-Mailbox and Delete-Mailbox will create a brand new object in AD or remove it from AD altogether. Enable/Disable are used to add a feature to an object or remove it, e.g. Enable-Mailbox adds a mailbox ‘feature’ to an existing AD User, Disable-Mailbox would remove the feature and leaves the AD User. Set is used to update properties of an object, e.g. Set-Mailbox to change aspects of a mailbox.

Always be careful when running non Get-* cmdlets, and it always pays to add a -WhatIf parameter to them so that PowerShell will inform you what would happen without actually doing it

Have fun exploring the various cmdlets!

We will be back next week to discuss the pipeline before moving on to creating PowerShell scripts

Twan van Beers

Twan is a senior consultant with over 20 years of experience. He has a wide range of skills including Messaging, Active Directory, SQL, Networking and Firewalls. Twan loves to write scripts and get deep and dirty into debugging code, in order to understand and resolve the most complex of problems.

This Post Has 4 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Search