So many possible things to talk about in this UPDATE: We've got continued problems with Android synchronization through Exchange ActiveSync (summary: Android 2.2 seems problematic); a lively discussion about the patch prerequisites for Microsoft Exchange Server 2010 SP1 (summary: yes, you need hotfixes, but they're fully supported); and the opening of a new NFL season, in which I hope my beloved New Orleans Saints will repeat as Super Bowl champs.
However, today's topic is a return to something from a couple of weeks ago: new Exchange Management Shell (EMS) cmdlets in Exchange 2010 SP1 that let you work with items in mailboxes. Exchange 2007 included cmdlets for managing mailboxes themselves, but if you wanted to count, create, remove, or otherwise deal with the items therein, you were constrained to use MAPI, Collaboration Data Objects (CDO), or other black arts. In my previous UPDATE, I mentioned Get-MailboxFolder, New-MailboxFolder, and Get-MailboxFolderStatistics. Now it's time to talk about some more esoteric, but equally useful, cmdlets for mailbox item management. We can broadly separate them into two groups: cmdlets for working with mailbox configuration and cmdlets for working with mailbox permissions.
In the first group, most of the cmdlets are oriented toward settings that are stored in folder associated items. FAIs are hidden messages of a special type, which you can access only by using MFCMAPI or a similar tool. Microsoft Office Outlook and various Exchange components can, of course, access them directly. One example: the out-of-office (OOF) settings for a mailbox, which control whether an OOF message is returned to people who send the mailbox owner a message, what the message says, when it's sent, and so on. The most interesting cmdlets in this group are as follows:
- Get-MailboxAutoReplyConfiguration and Set-MailboxAutoReplyConfiguration let you control the OOF settings for a mailbox. Want to get a list of all mailboxes that have OOF enabled, or turn OOF on or off for a given user or group? That's exactly what these cmdlets are for.
- Get-MailboxCalendarConfiguration and Set-MailboxCalendarConfiguration are used to see and set the parameters that the Exchange calendaring assistant, Outlook Web App (OWA), and Outlook use for calendar management. For example, you can set the working hours for a mailbox, control the display of week numbers in the OWA calendar, and set the behavior you want for calendar reminders with these cmdlets.
- Get-MailboxMessageConfiguration and Set-MailboxMessageConfiguration gives you control over a wide range of settings, some of which I didn't know existed as settable preferences. For example, you can set the default font, color, and font size that OWA uses—a valuable tool if you have users who think it's acceptable to use Comic Sans in their messages. You can also see and set the way that OWA sorts conversations.
There are also cmdlets for managing the regional settings (Get-MailboxRegionalConfiguration and Set-MailboxRegionalConfiguration) and OWA spell-checking settings (Get-MailboxSpellingConfiguration and Set-MailboxSpellingConfiguration). The point behind these cmdlets is twofold: They let you quickly apply consistent settings to large numbers of mailboxes, and they give you a way to change or fix settings on a mailbox without having the ability to log on to it—exactly what you'd want for a Help desk or IT support role that doesn't need full mailbox access.
The permissions cmdlets come in two flavors: Add-MailboxPermission, Get-MailboxPermission, and Remove-MailboxPermission are for permissions that apply to the entire mailbox, and their counterparts, Add-MailboxFolderPermissions, Get-MailboxFolderPermissions, Set-MailboxFolderPermissions, and Remove-MailboxFolderPermissions, apply only to individual folders within a mailbox. You can think of these cmdlets as an EMS tool that uses the same settings as the familiar Outlook permissions dialog box. The Set cmdlets let you edit existing permissions, and the Add and Remove cmdlets are for creating or removing permissions.
Of course, the ability to manipulate permissions isn't something to be given lightly, so it's a good thing that you have full use of Exchange 2010's Role Based Access Control (RBAC) features to restrict which users can run these permissions and when. In my next UPDATE, I'll discuss exactly how you'd do that to give you a feel for how RBAC works in real life.
Related Reading:
