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.
What’s in a mailbox?
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.
Figure 6. Accessing Exchange custom attributes
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'
Microsoft Exchange Server 2013 : Creating new mailboxes (part 1)
Microsoft Exchange Server 2013 : Creating new mailboxes (part 2) – Languages
