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 [email protected]  -PSTFolderPath C:PSTFilesathan.pst

(For detailed directions for exporting mailboxes, see the Microsoftarticle “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 theexternal Autodiscover FQDN.

Continued on page 2

So, what do you need to do? Assume you have a single Exchange 2007 server called exchserver1 running the Mailbox, Hub Transport, and Client Access roles and you want to access the server using OWA internally via the URL https://owa.example.local and externally via the URL https://owa.example.com.

First, you need the relevant DNS A records in your internal and external DNS zones so that the URLs resolve to the IP address of the server. For external access, make sure incoming traffic traverses any firewalls over port 443. When DNS resolution is working, you create a certificate request by running thefollowing PowerShell command in EMS:

 New-ExchangeCertificate  -GenerateRequest:$True  -SubjectName "c=US, o=company,  cn=owa.example.com"  -DomainName owa.example.com,  autodiscover.example.com,  exchserver1, example.local,  example.com,  exchserver1.example.local  -FriendlyName ExchOWACert  -PrivateKeyExportable:$True  -Path C:ExchOWACert.req

This command creates a request file, which you then send to your certificate authority (CA), be it an internal or public one. It’s important that the SubjectName parameter is correct and represents your company. Otherwise, it’s unlikely a public CA such as VeriSign will be able to authorize your request.

After your CA authorizes your server, it sends you a .cer file. You must import that file to the server using the command

 Import-ExchangeCertificate  -Path C:ExchOWACert.cer

The output of this command shows that the certificate has been imported and lists the certificate’s thumbprint. Copy the thumbprint to the clipboard; you’ll need it to enable the certificate. To enable the certificate, use the following command, where thumb is the copied thumbprint:

 Enable-ExchangeCertificate  -Thumbprint thumb  -Services "IIS,POP,IMAP,SMTP"

You’re almost done. All that remains is to set the URLs required to access Exchange. But first, I should introduce a couple of parameters. The InternalURL and ExternalURL parameters can be specified on web-accessible virtual directories such as OWA, Offline Address Book, Autodiscover, Exchange ActiveSync, Unified Messaging, and Exchange Web Services. Each of these virtual directories has a URLs property page that lets you configure its internal and external URLs. The InternalURL and ExternalURL parameters let you specify different URLs for access to the Client Access server. The InternalURL parameter is set by default on installation and is what the default self-signed certificate uses for its principal name. When a Client Access server is externally accessible, the ExternalURL parameter should be configured with the URL used to access the service, such as owa.example.com/owa.

Setting these parameters in larger Exchange deployments can be complex, but in this scenario, things are fairly simple. Use this command to set up the virtual directory for OWA:

 Set-OWAVirtualDirectory  -Identity "OWA (Default Web Site)"  -InternalURL https://owa.example  .local/owa  -ExternalUrl https://owa  .example.com/owa

The command is the same for other virtual directories, but substitute the corresponding EMS cmdlet (i.e., Set-OABVirtualDirectory, Set-UMVirtualDirectory, Set-WebServices- VirtualDirectory) and identity parameter.

Having completed these steps, you should now have secure access to OWA both internally and externally from the URLs specified. You should also have a solid base to begin the process of enabling Outlook Anywhere with Autodiscover because the certificate and InternalURL/ExternalURL configurations are already in place.

Lack of Native Backup in Server 2008
My final annoyance is the lack of a built-in backup utility for Exchange 2007 running on Windows Server 2008. Exchange needs an Exchange-aware backup program. Ever since the first version of Exchange (4.0) shipped, the Exchange installation has modified NTBackup to provide just such a program. However, with the move to Volume Shadow Copy Service (VSS)-based backups on Server 2008—and consequently, the removal of NTBackup—Exchange no longer has a usable backup utility. The only options left are to purchase Microsoft System Center Data Protection Manager or third-party backup software. Unfortunately, right now there’s nothing else that can be done, but in June 2008 a member of the Exchange Server product team announced that Microsoft plans to release a VSS-based plug-in for Windows Server Backup. The plug-in will let customers take Exchange-aware VSS backups on Server 2008. At press time, however, no updates have been released about theplug-in.

As someone who has worked with Exchange 2007 for a while now, I often have clients moan to me about the bits they don’t like. I hope this article gives you ideas about how to work around some of the challenging areas of Exchange—and I hope Microsoft will improve some of these problem areas in thenext version of Exchange.