I have to admit that the Exchange Management Shell (EMS) has spoiled me a bit. I like working from the command line not because there's anything wrong with the Exchange Management Console (EMC) in Microsoft Exchange Server 2010 and Exchange 2007, but because, to me, EMS is more interactive, more immediate, and much more flexible. Because EMC uses EMS behind the scenes, you can do everything from the command line that EMC does, but not vice versa.
One thing that Exchange has never really supported is a programmatic interface other than MAPI for working with items in mailboxes. MAPI development is something of an occult art. Although there are shortcuts (such as Dmitry Streblechenko's excellent Outlook Redemption class library), writing a tool to create, move, or modify items in users' mailboxes is not something to be undertaken lightly. That difficulty puts this capability out of reach of most Exchange administrators; only people who are comfortable writing standalone programs have really been able to use it.
This limitation might not seem like a big deal, but when you consider that many Exchange settings are stored as hidden items (known as folder associated items—FAIs) in user mailboxes, the limitation becomes more significant. To give one example, out-of-office (OOF) statuses and messages are stored as FAIs. Users can set their own OOF statuses from clients, including OWA, Outlook, Windows Mobile 6.x, and Entourage for the Mac, but as an administrator, you can't set, or see, these statuses, nor get information about who's got the OOF feature turned on.
Exchange 2010 SP1 includes several new EMS cmdlets that start to address this limitation. These cmdlets give administrators the ability to create folders in mailboxes, manage permissions on mailboxes and individual folders, and set options on user mailboxes. There are also cmdlets that give you access to specific types of data stored in FAIs, such as OOF status and spell-checking settings for OWA.
These cmdlets aren't all-powerful. First, they require that you have permission to access the mailbox you're working with. Second, there are no cmdlets for injecting, removing, or reading individual items (although you can use the Send-MailMessage cmdlet to send messages).
With those factors in mind, let's start looking at the cmdlets. I'll cover a couple in this UPDATE and continue with more in my next column.
First, we have New-MailboxFolder, which does what you'd think: creates a new folder with the specified name in the target mailbox. You can create a folder in the mailbox root or beneath any folder in the target mailbox. You could use this cmdlet to create a standardized set of folders in new mailboxes you create, similar to what managed custom folders could do in Exchange 2007. (Note that there doesn't seem to be a way to remove a mailbox folder after you create it!)
Get-MailboxFolder retrieves an object representing a target folder, which you can then use with Get-MailboxFolderStatistics to see its size, item count, and other useful properties. You can specify the folder by name, and you can use the GetChildren switch to indicate whether you want the child folders of the target, or not.
In the next UPDATE, I'll cover the cmdlets for managing two key things: configuration data stored in FAIs and mail folder permissions. Until then, happy folder management!