Working with the Exchange Management Shell
Strong Shell
Exchange Server has a customized version of PowerShell in the form of Exchange Management Shell (EMS). The extensions for the mail server are already loaded in the shell. The EMS is now clearly superior to the Exchange Management Console, and many administrative tasks are only possible via commandlets, which is a good reason to look more closely at PowerShell for Exchange.
Resistance is futile not only for Exchange administrators but also for managing SharePoint or Internet Information Services (IIS). Those who steer clear of the console do not have the options for performing all administrative tasks.
Microsoft has not necessarily followed a straightforward path regarding the implementation of PowerShell in Exchange Server since the 2007 version. After a brilliant beginning, Exchange Management Shell and Exchange Management Console were neck and neck in the 2010 version. An action such as activating an anti-spam agent on a hub transport server also created a corresponding management tab in the GUI.
Advantage: Shell
This equality no longer exists in Exchange Server 2013. The advanced settings of ActiveSync Policies have also been relocated. Permissions are now configured exclusively via the console. The options for granting individual rights using checkboxes no longer exist. Even rights such as the use of Internet Explorer or the camera can now only be set using parameters of the cmdlet Set-ActiveSyncPolicy
.
In this article, I will focus on mailbox permissions. PowerShell offers a script interpreter for PS1 files as well as a console. PowerShell processes command types called "monards" (function, alias, cmdlet) on this command level. These monards are grouped with command families, which are in turn shaped by common "nouns." Actions, the "verbs," are then allocated to each noun.
This principle becomes obvious if you consider the cmdlet Get-Mailbox
. The command's target is a mailbox, the action is Get
. The mailbox settings are represented by the noun MailboxPermission
, which is logically located in User/Mailbox
. If you enter the following command in PowerShell:
Get-<Command> -<noun> <MailboxPermission>
you will see the commands for mailbox permissions (Figure 1).
Managing Permissions
You can recognize the fundamental objective of the commands from the verbs:
Add
: adds a new permission to a mailboxGet
: shows the existing permissions.Remove
: removes a rights entry.
You will always find at least one "get" associated with a noun. It is therefore always possible to retrieve the existing information for a managed object. I will list the existing permissions to get started. Unfortunately, it is not possible to do everything in one fell swoop as in:
Get-MailboxPermission
or
Get-MailBoxPermission -Identity *
The command Get-MailboxPermission
absolutely requires the parameter -Identity <value>
. In this case, <value>
can assume the following information:
- GUID
- ADObjectID
- Distinguished name (DN)
- Domain|Account
- User principal name (UPN)
- LegacyExchangeDN
- SmtpAddress
- Alias
Transmitting a username would therefore be possible with:
Get-MailboxPermission -Identity office.onmicrosoft.com\office
You can qualify this list using the parameter -user
to avoid unnecessary filter operations. By using the command:
Get-MailboxPermission -Identity office.onmicrosoft.com\office -user Tom
you can identify the permissions of user Tom for the corresponding mailbox.
In addition to the restriction on the rights holder, the switch parameter owner
lets you focus on the right owner. This parameter does not expect a value but is instead set to False by default. If applied, only information about the owner is displayed. However, a combination with -user
is not possible.
Return values are information about access rights (permissions). It is a complex object with attributes. The following functions are implemented:
Deny
: deny yes/noInheritanceType
: inheritanceUser
,Identity
IsInherited
: inherited right yes/noIsValid
,ObjectState
: modification
As well as specifying the desired mailbox using the parameter -Identity
, PowerShell provides you with much more flexible means for the query. The construct for this is the PowerShell pipeline. This allows you to transmit lists conveniently as InputObjects
. The pipeline iterates over the values and binds them individually to the -Identity
parameter. In the following example,
myfirst@mydom.com,mysecond@mydom.com, mythird@mydom.com | Get-MailboxPermissions
try replacing the corresponding sample values with valid mailboxes.
New Permissions Needed
If you want to set a new permission, use the Add-MailboxPermission
command. Table 1 shows some parameters that you can use to control the command.
Table 1
Parameters for the Target
Parameter | Target |
---|---|
deny
|
Deny (yes/no) |
user
|
Mailbox, access to the target box is granted |
owner
|
Owner of the target mailbox |
identity
|
Account that receives a right |
AccessRights
|
Access rights as list |
To put this simply: The right or rights (AccessRights
) are granted to the account user
for the mailbox identity
, which itself can again be a list. Next, I'll look at the rights types. One or more of the following access rights can be set:
ExternalAccount
FullAccess
DeleteItem
ReadPermission
ChangePermission
ChangeOwner
Everything is in place from assumption of ownership to full access. Values bound to the parameter AccessRights
define the character of the right granted. Thus, if you want to give the user Tom read access to Jane's mailbox, you would invoke the following command:
Add-MailboxPermission -Identity jane -User tom -AccessRights ReadItems
If you want to change the ownership rights, use owner
instead of user
. It is not, of course, possible to use both parameters simultaneously. So, if Tom is to take over Jane's mailbox, you can do this using:
Add-MailboxPermission -Identity jane -Owner tom
If you want to change multiple mailboxes in your rights structure, use the pipeline. However, be careful: The pipeline operates very slowly. Large amounts of data are passed through the pipe individually, so processing does not take place in real time. The following command gives the user Tom full access to all mailboxes:
Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox')} | \ Add-MailboxPermission -User tom@mydom.com -AccessRights fullaccess -InheritanceType all
If you only want to control individual folders, use an extra cmdlet for this. You can apply the rights key a little more precisely to the mailbox folders using Add-MailboxFolderPermission
. The parameters are almost identical, and the values transmitted are also of the same type:
Add-MailboxFolderPermission -Identity jane:\Sales -User tom -AccessRights Owner
Ownership of the mailbox folder Sales
is now taken over by Tom. Revoking a right again follows the same path as an assignment:
Remove-MailboxPermission -identity jane -User tom -AccessRights full-access -InheritanceType all
Tom's full access to Jane's mailbox has been revoked. Inheritance is active, as in the example above.
Buy this article as PDF
(incl. VAT)