Exchange 2007 Shortcomings

Microsoft Exchange Server has gotten stronger in recent years, gaining both a solid reputation for stability and the lead in market share. With the release of Exchange 2007, Microsoft made massive changes to the product, and frankly, many of them were excellent. However, a few changes weren’t quite so good. In this article, I’ll take a look at a few of the most common annoyances with Exchange 2007 and, where possible, offer some solutions to the problems.

GUI Limitations
One of the key changes Microsoft made in Exchange 2007 was to build the entire product management toolset around Windows PowerShell. In itself, this is a good thing, but administrators used to using a GUI for some tasks can no longer do so. Examples of problem areas include setting public folder permissions, manipulating diagnostic logging levels, getting mailbox statistics, and exporting mailboxes. Here are suggestions to help you around a couple of these problems.

Getting mailbox statistics. In Exchange 2003, it’s easy to see the size and number of items in mailboxes, and even sort the view. In Exchange 2007, you must use the Get-MailboxStatistics command through Exchange Management Shell (EMS), as shown here:

 Get-MailboxStatistics | where
  {($_.objectclass -eq "mailbox")} |
  sort-object TotalItemSize |
  format-table DisplayName,
  @{expression= {$_.TotalItemSize.Value.ToMB()};
  label=”MBSize(MB)”},
  LastLogonTime, DatabaseName,
  ItemCount

This command gets mailbox statistics for all mailboxes (not including system mailboxes and other special mailboxes) and outputs the results in a table. Figure 1 shows the output, and you can see that I’ve labeled the TotalItemSize column as MBSize(MB) and that its values are in megabytes. The output is sorted by the TotalItemSize column.

For help with using PowerShell to manage Exchange, or for general information about PowerShell, see the learning path for this article. For more information about the Get-MailboxStatistics command, see the Microsoft article "Get- MailboxStatistics," at technet.microsoft.com/en-us/library/bb124612(EXCHG.80).aspx.

Exporting a mailbox to a PST. In Exchange 2003, we have the ExMerge utility, a GUI tool, to export part or all of a mailbox to a PST. However, ExMerge isn’t included with Exchange 2003; you have to download and install it separately. In Exchange 2007, the process for exporting to .pst files has improved because the ability is built into the product. However, it would be nice if you could simply right-click a mailbox in the Exchange Management Console to export it. Instead, you must use EMS.

First, ensure your account (in my example, Admin) is a Microsoft Exchange administrator and local administrator on the source server. Your account must also have full access rights for the mailbox from which you will export (in this case, Nathan). You can grant these rights with the following command:

 Add-MailboxPermission -Identity Nathan
  -User Admin -AccessRights FullAccess

To perform the export, you must be on a computer running the 32-bit administrative tools and with Microsoft Office Outlook 2003 SP2 or Outlook 2007 installed. I usually use a Windows XP workstation. As long as you meet the above prerequisites, you can run the export using the following command:

 Export-Mailbox
  -Identity nathan@gaots.co.uk
  -PSTFolderPath C:\PSTFiles\nathan.pst

(For detailed directions for exporting mailboxes, see the Microsoft article “How to Export Mailbox Data,” at technet.microsoft.com/en-us/library/bb266964.aspx.)

Certificates and Web Access
Certificates are one of the most common areas where people have problems in Exchange 2007. By default, Exchange 2007 is secured with a self-signed certificate. Although this method is secure, it often leads to users being prompted that the certificate isn’t trusted. Administrators usually prefer to access webmail through something such as owa.example.com. Therefore, it’s essential to request, create, and assign a new certificate. This certificate needs to secure access to Exchange when Exchange is referenced by a variety of names. You create such access by adding Subject Alternative Names (SANs) to the certificate. The SANs need to cover all names used to access Exchange, including the host name, the internal Fully Qualified Domain Name (FQDN), the external FQDN for Microsoft Outlook Web Access (OWA) and Outlook Anywhere, and the external Autodiscover FQDN.

Continued on page 2