Exchange Queue & AWe Have All the Answers (Because We Made Up the Questions)

KC Lemson and Paul Bowden

Hello, and welcome to the first installment of Exchange Queue and A! We're kicking off with a series of questions that, to be honest, we came up with ourselves, so it's probably unfair to position this as a genuine question-and-answer column

because it's only Q&A insofar as the Qs and As happen in an echo chamber. We do, however, believe that these questions may be representative of questions on the minds of Microsoft® Exchange Server customers, and so we claim the moral high ground. In the future, we certainly welcome your questions, so feel free to send them to queuea@microsoft.com.

Our current vision for this column is that it will be a rotating cast of authors (kind of a "throw the writers at the wall and see which ones stick"), but all of us have been involved with Exchange for many years. This month the answers (and questions!) were coauthored by KC Lemson and Paul Bowden, Lead Program Managers in the Exchange product team at Microsoft. Both of us are old-timers in Exchange development. We've moved around quite a bit, but have never been able to get away from messaging.

KC has worked in the Exchange group for the last six years where she's held a variety of roles including a program manager on Microsoft Outlook® Web Access (OWA) and lead program manager in charge of the Exchange pre-release customer program. She is currently the User Experience Manager for Exchange, in charge of product design and customer research. Before joining Exchange, she was a tester in Outlook for three years, and was responsible for the testing of attachments during the era when people thought it was a double-plus-bad thing to block executable attachments in e-mail. KC blogs at blogs.technet.com/kclemson.

Paul has spent the last three years working on that nifty little Exchange Best Practices Analyzer (ExBPA) tool. In fact, he won an award for it a couple of months ago and had his photo taken with Bill Gates. However, with the Exchange Server 2007 project wrapping up, it's time to shuffle the deck. Paul needs to stop dreaming in XML and come back to the real world. He's going to be the Release Manager for the next version of Exchange (the version that we'll start working on just as soon as Exchange Server 2007 has shipped).

By the way, did you enjoy the incredible amount of wit demonstrated in the naming of this column? We, of course, can't even take credit for the name; it was suggested by a reader of KC's blog. (Enjoy the shirt, Tim!) Runner-up suggestions were "Pushing the Envelope" and "When I'm X64", the latter of which KC enjoyed so much that she registered www.whenimx64.com and pointed it to her blog just because she could. If only we could be as empowered about everything in our lives.

Side note: KC first proposed naming this column "The Monthly Queue and A" until our editor aptly pointed out that we are as yet an unknown quantity and our ability to deliver on schedule can't be trusted (he was more polite and less blunt in his response than we are here, but we knew what he was thinking). Along those same lines, we have no idea what the feedback will be from readers of this column, and whether or not it's worth repeating it. Therefore we met in the middle with the name and you'll just have to let us know what you think at queuea@microsoft.com.

And so, without further ado, on to the questions...

Q Why should I be excited about Exchange Server 2007?

A We realize it's risky to open the first column with what is essentially a marketing question, but we are so excited about Exchange Server 2007 that we really want to share it with you. So we will attempt to limit the "market-ecture" in this response and instead just speak to a few of the many technical reasons why an Exchange administrator or user should be excited about Exchange 2007, from one geek to another.

Scalability and Performance Improvements

First off is the obvious one: 64-bit. What's the big deal, you ask? Well, 32-bit Windows® can only support a total of 4GB (232 bytes) of memory, and 2GB are taken by the kernel by default, leaving only 2GB for applications. The current version of Windows supports a /3GB switch in boot.ini that gives applications up to 3GB of memory headroom, but once you've used that the Windows kernel gets a little uncomfortable, and it won't be long until you're having to reboot that server to reclaim resources.

Happily, 64-bit support, along with significant changes to the underlying database engine (JET) in Exchange, solves this problem. Since Exchange servers are traditionally far more bound by disk I/O than by any other system resources (such as CPU), adding memory to the system means that you can significantly reduce the disk I/O by keeping more information in memory instead of having to read the disk. As a result, with Exchange 2007 you can support far larger mailboxes for your users on similarly equipped physical hardware than with Exchange 2003. The mail server I am on at Microsoft, for example, supports 4,000 users with 2GB mailbox quotas, resulting in 6 terabytes (TB) of data. To be clear, just because Exchange 2007 can take advantage of more memory doesn't mean that it needs that much memory-we've tested a box running 32-bit Windows Server® 2003 and Exchange 2003 with 4GB or less of memory, installed 64-bit Windows Server 2003 and Exchange 2007, and saw similar performance.

Exchange 2007 also includes two new ways of improving availability: Clustered Continuous Replication (CCR) and Local Continuous Replication (LCR). These technologies reduce the risk of a storage failure causing serious problems. LCR keeps a local copy of your databases on the same machine, but you can put them on different storage media. CCR can do the same between two machines over a network. CCR, combined with the disk I/O improvements we touched on earlier in this column, opens up new options for storage hardware; if you would like to use direct-attached storage media such as SATA or SCSI drives, it is now a much more cost-effective, performance-improving option.

Administration

Microsoft invested heavily in a new administrative experience in Exchange 2007, which includes the command-line interface shown in Figure 1. It's called the Exchange Management Shell (EMS) and is based on Windows PowerShell™. If you are not a fan of the command line, that's fine-the GUI is still there for you, only now it's called the Exchange Management Console (EMC) and it's a far more intuitive interface than the old System Manager (see Figure 2). If you are already an advocate of command-line interfaces or want to become one, check out the EMS in Exchange 2007.

Figure 1** Storage Group Status in Exchange Management Shell **(Click the image for a larger view)

Figure 2** The Same Status in Exchange Management Console **(Click the image for a larger view)

In Exchange 2003 you may have had to use Windows Management Instrumentation (WMI) scripts to perform some of the more complex administrative tasks, but with EMS these tasks can be done by anyone who sees "CD C:\TEMP" and doesn't think it's an album from a new band (ba dum bump). Although one of us is a former UNIX sysadmin, and therefore our objectivity may be questioned here, we can point you at plenty of unbiased third parties who will vouch for how the shell is incredibly intuitive even if you've never used a command line before (more on that in the next Exchange Queue and A column).

One of the beauties of Windows PowerShell is that it is object-based. When you retrieve information from the server, such as a list of mailboxes or SMTP connectors, the information is automatically stored in an object or variable and streamed to stdout as text for easy reading. That object can then be passed directly to another command and operated on in the pipeline (in which case it passes along the object rather than the text, making it easy to modify the data or operate on parts of it). Here's a simple example:

Get-Mailbox | Set-Mailbox -ProhibitSendQuota 250MB

The Get-Mailbox command retrieves a list of mailboxes in the system. The | (called the pipe symbol) indicates that the output of the command on the left should be passed to the command on the right. The next part, "Set-Mailbox-ProhibitSendQuota 250MB" means that all of those mailboxes now have a quota such that they can no longer send e-mail after they reach 250MB in size. You could also have set it to 250000000 or 250000KB or .25GB as well-the shell is very flexible in how it handles data.

Another helpful administrative improvement in Exchange 2007 is the ability to create transport rules, using a rules wizard very much like the one in Outlook to apply business logic to messages flowing through your system. Want to block any e-mail that appears to contain Social Security numbers in the body based on a regular expression? Check. Want to set up an ethical wall so that two divisions in your organization can't e-mail each other? Check. Want to add a disclaimer to every e-mail that is going outside your organization? Check.

One last administrative feature that we are very excited about is customizable system messages: out of the box you can now add your own custom text to non-delivery reports as well as (finally!) the message users see when they are over their storage quotas.

Help the Help Desk

One of the biggest expenses for many customers is the help desk costs related to configuring new profiles in Outlook. With Autodiscover in Outlook 2007, just start Outlook and it will automatically look up your e-mail address and retrieve your Exchange server information from Active Directory® using the Service Connection Point. If you're not connected to Active Directory, just enter your e-mail address and password and the Autodiscover lookup can download an XML file from a specified Web server (such as https://autodiscover.contoso.com) that has basic configuration information in it such as the server to use for RPC over HTTP (now called Outlook Anywhere).

Another help desk cost is managing the seemingly inevitable false positives from your anti-spam filter. Users can keep safe lists in Outlook of senders whose messages should not be subjected to content filtering, but until Exchange 2007 those lists only let the messages bypass the Outlook filter. However, because the Exchange filter acts on the messages before Outlook ever sees them, users could still miss e-mail from people they trusted.

Exchange 2007 helps here too: if you use the anti-spam content filter with either the Edge or Hub server role in Exchange 2007, you can configure it to propagate users' safe-sender lists to that server, so that messages from those senders will bypass the spam content filter. Of course, what is spam for one user is a newsletter for another, so the safe-sender aggregation happens on a per-user basis.

End User Delight

With Unified Messaging (UM) in Exchange 2007 you can receive inbound voicemail and faxes in your Inbox. (If you've never had this before, you don't know what you're missing.) You can also call up your Exchange server and tell it to notify every participant of your 8 A.M. meeting that you're running late. Even the smallest of organizations can easily have a customized and branded automated attendant so that when your customers call you, your system can route them in the right direction. In order to use UM, you will need either an IP-based PBX (IP/PBX) or you can hook up your traditional circuit-switch based PBX to a Voice over IP (VoIP) gateway.

Link Access is a new feature in OWA 2007. What if you're on the road without a VPN client installed and you need to view a Microsoft Word document on a file share or a SharePoint® site on the corporate network? No problem-just load OWA 2007, go to the Documents link, and type in the name of the share or SharePoint site (https://mysharepointsite or \\server\share) to browse and open files. Of course there are plenty of security controls for administrators to lock this down however they desire-all servers allowed except a certain list, all servers denied except a certain list, only allow access to the documents if users log in to OWA from private computers, and so on.

OWA also includes WebReady Document Viewing (that's "transcoding" in geek speak) where you can tell Exchange to render certain types of file types into HTML if you don't have the right application installed locally. Exchange 2007 will ship with support for transcoding the following file types by default: DOC, DOT, RTF, WBK, WIZ, XLS, XLK, PPT, PPS, POT, PWS, and PDF. The transcoding engine has a pluggable architecture so that we could add support for new file types in a service pack. There are also administrative options so that you can determine which file types users are permitted to transcode, or to disallow transcoding entirely.

If you have mobile devices that synchronize with Exchange using Exchange ActiveSync®, you'll be happy to know that when you reply to or forward an e-mail thread, the message will no longer be converted to plain text. Your text is added at the top but the HTML body from the rest of the message remains as-is. This works for any device that supports ActiveSync, it does not require functionality in the client.

Q I've heard that Exchange 2007 is "64-bit only for production purposes." What does that mean?

A Exchange 2007 is available in both 32-bit and 64-bit flavors. The 64-bit version is intended for production "live" usage of the core server roles (Mailbox, Hub Transport, Edge Transport, Client Access, Unified Messaging). The 32-bit version is intended for evaluation of the new features of Exchange 2007. The management tools can also be used in 32-bit in production, so that you can manage your 64-bit Exchange 2007 production servers from your 32-bit Windows XP desktop machine. Also note that the Exchange 2007 schema must be installed from a machine in the root domain-Exchange itself does not need to be installed in the root domain, but we require the schema extension to happen in the root domain as a way of ensuring good network connectivity to the schema master. If you don't have a 64-bit server in that domain, you can use the setup.exe from the 32-bit version to extend the schema.

What's wrong with 32-bit servers, I hear you ask? If you've had the pleasure of running thousands of users on a single server, you know it can be quite a balancing act between performance and stability with the memory limitations we described earlier. If you've bought a new computer in the past two years, chances are that it already supports x64 extensions. In fact, it's pretty difficult to buy a new computer that doesn't support 64-bit mode these days. Thus, it may be that the machine already running Exchange in your environment is 64-bit capable; it's just that it's running a 32-bit operating system. Which brings us to a good point-once you've got your new 64-bit-capable computer, remember to install the 64-bit version of Windows Server 2003 SP1.

So why do you see all the warnings in setup about not using 32-bit installs in production? Although it's pretty easy to compile Exchange in multiple flavors, each component is 100 percent optimized and tuned for 64-bit (some of the code paths we've chosen to achieve the improvements in disk I/O on 64-bit systems actually cause a performance degradation in 32-bit environments). In fact, when you're kicking the tires with 32-bit, don't even think about getting it to perform under load (simulated or otherwise); you won't get a realistic picture of how it will perform in a 64-bit system or how many users you can fit on the server.

So we're all clear? You can use the 32-bit version of Exchange 2007 to:

• Evaluate the new features on a test server with no live user mailboxes on it.
• Drool over the new administrative console, shell, or OWA interface (mind the drool on the keyboard, though).
• Administer your Exchange 2007 servers.
• Extend the schema in your Active Directory forest.

Once you're ready to move mailboxes, you need the servers to be running a 64-bit operating system with 64-bit Exchange 2007. If you don't, you'll have both setup and ExBPA bleating at you (see Figure 3). Paul knows this for a fact-he wrote the code!

Figure 3** Trying to Install 32-Bit Where Only 64-Bit Should Go **(Click the image for a larger view)

Q How much memory do I need to run Exchange 2007?

A Your base install needs at least 1GB of physical RAM. As I mentioned earlier, some of the server roles are on the heavy side. If you're looking to install an all-in-one server (such as Mailbox, Client Access, Hub Transport and Unified Messaging), you'll probably want to start with 2GB of RAM and scale it based on the number and usage of mailboxes. If you're looking to install either the Edge role or a cluster, then those need to be installed on separate machines. A cluster can only have the Mailbox role installed-nothing else.

You'll be excited to hear that you can finally install more than 4GB of RAM in your Exchange server. Many current machines come standard with 6 or 8GB, and it's always a crying shame to take those double data rate (DDR) modules out or use /BurnMemory to get the RAM down to 4GB (unfortunately, Exchange 2003 will perform worse and be less stable if you have more than 4GB-see go.microsoft.com/fwlink/?LinkId=76537 for details).

For your infrastructure servers (Hubs, Client Access, and such) you'll be fine with less than 4GB of RAM, even under the heaviest of loads. Where you want to spend your money is the Mailbox servers. That newly optimized 64-bit JET cache will want to make use of as much memory as you can throw at it. Of course, unlike Exchange 2003, Exchange 2007 supports up to 50 storage groups.

Although each storage group can support multiple databases, this won't really buy you any savings-especially as LCR and CCR (the two forms of database replication we discussed earlier) can only work with storage groups that have a single database. You'll certainly have to power up that extra RAM if you intend to create a bunch of storage groups or live the dream of 2GB+ mailboxes for each user. There's some great detailed information on RAM sizing on the Exchange team blog, but Figures 4 and 5 provide cheat-sheets to get you started.

Figure 5 RAM and Storage Groups

Figure 4 RAM by User Type

By the way, Microsoft IT uses a number of storage groups that is a multiple of seven, because they have a rotating backup schedule whereby on any given day, only a few of the storage groups get backed up. We call this schedule "candy cane backups" because of the Excel spreadsheet that describes the backup schedule, where the storage groups getting backed up on any give day are colored red in a cascading way. Hope this was helpful. Please send "real" questions for the next issue.

KC Lemson is a lead program manager on the Exchange Server team. She spends her free time helping safeguard the money of Nigerian royalty.

Paul Bowden is also a lead program manager on the Exchange Server team. He spends much of his free time reconfirming his PayPal account information upon request.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.