Automating mailbox settings
Many properties can be set to control exactly how a mailbox
functions, but some are more important than others. All the properties
can be manipulated with EMS, and the most critical through EAC.
However, it’s easy to forget to update or set a property. Automation
comes to the rescue in the form of the Exchange cmdlet extension agents , a feature that first appeared in Exchange 2010.
One of the standard agents, called the scripting agent, is designed to
support the automation of common tasks such as mailbox creation. The
most common use of the scripting agent is to update the properties of
new mailboxes after they are created.
For example, if you create
a new mailbox by using EMS or EAC, its language and regional settings
are not updated, and the user will be prompted to provide these
settings the first time that he accesses the mailbox with Outlook Web
App. The scripting agent gives you an easy way to ensure that default
language and regional settings are applied to new mailboxes, thus
avoiding the need for the user to become involved in the process. If
the default settings are not correct, the user can select new values
through Outlook Web App options.
The scripting agent is disabled
by default. The agent uses an XML configuration file stored in the
\V15\Bin\CmdletExtensionAgents folder to understand what processing it
must perform and when it is invoked. Exchange provides a sample
configuration file called ScriptingAgentConfig.xml.sample
that you can edit to add your instructions. The sample file contains a
number of interesting examples with which you can experiment, but your
purposes require only a very simple file that can be created with any
text editor and named ScriptingAgentConfig.xml.
The example ScriptingAgentConfig.xml that follows tells the scripting agent that:
It
should be invoked whenever the New-Mailbox or Enable-Mailbox cmdlets
are run by any process. These cmdlets are used to create a new mailbox
or enable a mailbox for an existing Active Directory account.
The specified code is invoked when the cmdlets have completed processing (the OnComplete event).
The
Name parameter is to be retrieved from the provisioning handler (the
framework that surrounds the scripting agent). The name is the
identifier for the object being processed, in this case, a mailbox.
Three
cmdlets are to be run. Set-Mailbox sets a default language value of
en-us; Set-MailboxRegionalConfiguration sets the appropriate date and
time formats; and Set-MailboxCalendarConfiguration sets the start of
the working day.
<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">
<Feature Name="Mailboxes" Cmdlets="New-Mailbox, Enable-Mailbox">
<ApiCall Name="OnComplete">
if($succeeded) {
$Name= $ProvisioningHandler.UserSpecifiedParameters["Name"]
Set-Mailbox $Name -Languages "en-US"
Set-MailboxRegionalConfiguration $Name -DateFormat "dd-MMM-yy" -TimeZone
"Pacific Standard Time"
Set-MailboxCalendarConfiguration $Name -WorkingHoursStartTime "08:30:00"
}
</ApiCall>
</Feature>
</Configuration>
To
enable the scripting agent so that it processes the code in its
configuration file, run the Enable-CmdletExtensionAgent cmdlet:
Enable-CmdletExtensionAgent "Scripting Agent"
This
is an organization-wide setting, so it is obviously important to have
the same configuration file in place on every Mailbox server so that
the same behavior happens throughout the organization. Make sure that
you develop and test the configuration file on a test server before
introducing it into production because any error in the file might
prevent EAC or EMS from completing an operation. After the
configuration files are deployed and the scripting agent is enabled,
Exchange faithfully executes the specified commands to automate the
finalization of mailbox settings.
After
you assign quotas to mailboxes, users start to populate the mailboxes
with various items. The Get-MailboxStatistics cmdlet provides a
snapshot of what’s in a mailbox and what type of items are stored. For
example:
Get-MailboxStatistics –Identity 'Redmond, Tony'
| Select DisplayName, ServerName, Database, LastLogonTime, ItemCount, DeletedItemCount, AssociatedItemCount,
TotalItemSize, TotalDeletedItemSize
Among
the interesting information this command reveals is the total items in
the mailbox (ItemCount) and the storage required for these items
(TotalItemSize). You also have a deleted item count (DeletedItemCount),
or the number of recoverable items in the mailbox, and the size of
those items (TotalDeletedItemSize).
The associated items
(sometimes called folder-associated item [FAI] messages) are hidden
items Exchange and Outlook use to store configuration data about the
mailbox. For example, if you change a mailbox setting through Outlook
Web App, this information is written to a hidden item in the mailbox.
The number of associated items varies from mailbox to mailbox and
depends on user activity, but it is commonly between 10 and 60 items.
The lower end of the range is for mailboxes that are relatively new,
and the upper end is typical of mailboxes that have been in use for
some time.
You can also generate data for all mailboxes in a
database or on a specific server with the Get-MailboxStatistics cmdlet.
The second example pipes the output in CSV format to a file that you
can open with Excel or Access and use for reporting purposes.
Get-MailboxStatistics –Database 'DB1'
Get-MailboxStatistics –Server 'ExServer1' | Export-CSV 'C:\Temp\Mailboxes.CSV'
If
you use Get-MailboxStatistics with the –Server parameter on a server
that hosts database copies from a DAG, you’ll see an error for the
database copies that tells you they are not mounted or are unavailable.
This is because the cmdlet can’t open these databases to read mailbox
data because the databases are mounted in a special way that allows
replication to occur but blocks other access.
Ready-to-go custom attributes
Exchange has always provided administrators with a set of
custom attributes by which to store information about mailboxes,
contacts, and groups. The logic here is that it is impossible for the
designer of any general-purpose directory to include all the attributes
required by every company that might use the directory. It’s easier to
provide a set of custom attributes than to go into the support
nightmare that might occur if everyone attempted to extend the schema
to add her own set.
To access the custom attributes in Exchange 2013, select an object in EAC, view its properties, and click Custom Attributes. Figure 6
shows the set of custom attributes for a mailbox. It’s common to use
attributes to store employee identifiers, department codes, job codes,
identifiers for synchronization with other email directories, and an
indicator of whether the mailbox is used by a permanent employee.
Caution
Be
careful to ensure that the data you hold about people in Active
Directory comply with applicable privacy laws in any jurisdiction in
which you operate.
The custom attributes are also accessible through EMS. For example:
Get-Mailbox –Identity 'EPR' | Select Name, Custom*
Set-Mailbox –Identity 'EPR' –CustomAttribute1 '8ZW' –CustomAttribute12 'Temporary Assignment'
Set-DistributionGroup –Identity 'Sales' –CustomAttribute10 'Synchronized 10-Dec-2013'
Set-DynamicDistributionGroup –Identity 'Texas Users' –CustomAttribute3 'Dallas'
Set-MailContact –Identity 'Ruth, Andy' –CustomAttribute1 'Lotus Notes User'
