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 |
PowerShell introduces many new terms which are worth listing just so that we’re all on the same page
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.
I find that my most commonly used cmdlets includes the following:
The help information provided by Get-Help is pretty much the same as what you will find in Technet for each cmdlet
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
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