Challenges Implementing Autodiscover

One of our visitors recently asked whether there are any challenges with implementing Auto Discover effectively, and Owen, our resident expert, had this to say:

The simple answer, the setup can be as simple or as complex as your corresponding Exchange environment. In a simple Exchange 2007 scenario, where Exchange routes for only one domain, the setup is fairly straightforward. As part of the Exchange 2007 CAS server installation, the necessary Autodiscover components are installed by default on the CAS server, and corresponding SCP records created in Active Directory. For users connecting from remote systems, such as laptops or home computers, an external DNS record is required which directs requests to autodiscover.yourdomain.com to the external address of the Exchange 2007 CAS server.

For more complex Exchange 2007 implementations, with multiple email domains, many external users, and custom SSL certificates, there are a few issues to overcome. Microsoft recommends that a separate website be created for a heavily utilized Autodiscover service. For multiple email domains, individual DNS records for each email domain need to be directed to one common HTTP based URL, which should to be configured to redirect all requests to an HTTPS enabled CAS server hosting the Autodiscover web site. This allows the use of multiple email domains, but one common Autodiscover site and corresponding SSL certificate. Otherwise, individual Autodiscover websites would need to be created on the CAS server, each with individual SSL certificates, which would become cumbersome and expensive to manage.

As Exchange 2007 has introduced a new web based delivery mechanism for Offline Address Books (OABs) for Outlook 2007 clients, replacing the Public Folder method used for Outlook 2000 through 2003 clients, a fully functioning Autodiscover service is required to maintain full functionality for Outlook 2007 clients. The same is true for Unified Messaging and Availability services, therefore a good understanding of and well designed Autodiscover implementation is key to a successful Exchange 2007 deployment.

For further information, Microsoft has published a good description on their TechNet site that describes the various scenarios, and potential solutions.

Autodiscover in Exchange 2007 and Outlook 2007

Exchange administrators and end users alike will praise the new Exchange 2007 feature known as Autodiscover. This new feature, combined with Outlook 2007, makes the setup of new Outlook profiles as simple as logging into your webmail. Simply provide Outlook your email address and password, and your Outlook profile is configured with no other information required. Gone are the days of needing to know your server name, or hunting for the settings and location to input your RPC over HTTP information.

This feature is elegantly accomplished through external DNS records, and features included on the new Exchange 2007 Client Access Servers (CAS). Administrators simply need to publish a DNS record on the internet for autodiscover.yourdomain.com, directing it to the CAS server of their Exchange email environment. The CAS server then provides the settings to Outlook 2007, including their Exchange server name, their RPC over HTTP settings (now called Outlook Anywhere), their offline address book web URL, their display name, and any other information required. This information is provided through a file called Autodiscover.xml, which is hosted by an IIS website on the CAS server, secured through NTLM authentication and SSL communications.

Similar principles are in place for Outlook 2007 with regards to personal accounts provided through user’s Internet Service Providers or free email providers. Many providers have the required information published that allows a user to simply input their display name, email address, and password, and Outlook 2007 automatically applies the required settings. You no longer need information regarding your incoming mail server, outgoing mail server, authentication settings, etc.

Simply put, Autodiscover makes accessing your email that much easier.

The Exchange database engine

Exchange can be considered to be a special purpose database application. The database is all the email and calendar entries in everybody's mailbox. Rather than writing a database from scratch, Microsoft used the Jet Database engine also used by Microsoft Access. What's that you say, gasping in horror, Microsoft Access is running my corporate email system??? Yup. It also runs your Active Directory, by the way.

Why doesn't Microsoft switch to a "real" database like SQL Server. There's certainly been talk about this for years, and a lot of rumors that would happen in E2K7, but it didn’t go down that way. And here's the rub: Jet is actually way faster than SQL Server.

SQL Server is built from the ground up to be a true multi-client, multi-machine, client-server database, and that carries lots of overhead.

All the clients need to create ASCII "SELECT" statements, send them over a skinny little pipe to the server, have the server parse and execute the queries, and then send the results back over the same skinny pipe to be parsed on the client end and then served up to the application.

By contrast, the Jet data and Jet engine sits right on the same computer as the application accessing the db, and uses big fat shared memory communications. Meanwhile, Exchange has customized and optimized the heck out of it to ensure the database performance is super-optimized for Exchange. Because the Exchange store.exe process manages all the communications to the database, there is no need for all the overhead of a true client-server database.

For a true client-server app, there is no substitute for a nice robust relational database like SQL server. But for an app like Exchange where all communications to a given computer are already funneled through a “front-door” process (store.exe), it’s really not necessary… honest…

Outlook or Google mail?

The UK's ITWeek asks whether or not Outlook should be consigned to the scrap heap and replaced with Google mail.

This writer makes some interesting points, but we'll wager he hasn't tried Exchange 2007 yet. His primary issues - the fit between Outlook and Exchange 2007 is on our top eleven list, as are the improved Outlook Web Access, and how 2007 addresses expanding mailboxes with a revised architecture - are all addressed in Exchange 2007. As for Google - we'd like to hear from readers who are considering or using Gmail for their businesses - would you go with a service like Gmail for corporate mail? Why or why not?

What's caching, really?

In the last post I told you that E2K7 (that’s short for Exchange 2007) uses lots and lots of caching to improve performance, especially on 64-bit architectures where lots and lots of memory is available.

One way to improve performance is to keep all data in zippy-fast RAM (random access memory) as opposed to on slug-like hard drives. Trouble with RAM is that when you reboot the machine, all contents are wiped away whereas hard drives can keep everything between reboots. So you can't only use RAM. The other problem with RAM is that there is never enough of it. 16GB is the practical limit of RAM you can load into a reasonably priced machine nowadays, whereas that same machine could take several Terabytes of disk.

So a compromise is needed. That compromise is caching. Caching means "fronting" the slow disk with fast RAM, and it relies on a property of most applications called "locality of access". The actual number of disk pages accessed during any small period of time is much smaller than the total amount of disk, especially with Exchange. Think about the 1GB of data in your mailbox - how much of it do you ever use at the same time? That means that the whole "working set" of disk pages can be mirrored in RAM, if you have enough of it.

On the first read operation, Exchange can bring the 8 KB disk page containing your data (and some nearby data) into RAM. All subsequent reads and writes can occur onto the mirrored page in RAM. When the user moves onto something else 10 or 12 seconds later (an eternity to a CPU running with a 3GHz clock speed) the RAM-mirrored page begins "ageing", and if it is not touched in a while, it is written back to disk so that the RAM can be used to mirror a different disk page that is in more active use.

This technique vastly reduces the number of iops to disk in favor of mops to RAM, which, are much, much faster, and don't require that you pay for all those expensive disk spindles to supply you with your necessary dose of iops.

One caveat with Exchange is that it is a database (albeit a cheesy one, but more on that in another post), and so there is a requirement to write data back to disk. In databases, this is handled by writing changes to the database to a "transaction log" straight to disk without any pesky caching getting in the way. That way, if the server suddenly crashes, the combination of whatever is on the disk plus the transaction log can bring the database right back up to date. So in the case of Exchange, big caches don't save on log write operations, but they sure save on store iops, which are by far the most common operation.

There are other ways of speeding up access to data other than caching, but they all require reorganizing the data radically and moving away from a more standard relational database organization to a super-customized disk organization, specifically geared towards your application. Even then, customized application-driven caching can still dramatically improve matters from there.

Taking a sub-optimal storage layout and throwing a 64-bit address space worth of caching at the problem as was done for E2K7 may not be elegant, but it sure gets the job done

E2K7 Feature Rankings - here’s what you’ve said so far!

Here are the top 11 features of Exchange 2007 according to your rankings so far! Agree? Disagree? Vote at http://www.ceryx.com/exchange2007.asp for your favourites.

Top 3 Features:

Outlook Web Access
Improved Calendaring and Scheduling
Improved Function Management from Mobile Devices

Next 2:

Sharepoint and RSS integration
Outlook Voice Access

Bottom 5:

Better search and message management
Out of Office Privacy and Config Mgmt
X64 Architecture
Native replication
Regulatory Compliance


Check back as we post updates to the survey!

Why x64?

Exchange 2007 is only supported on 64-bit hardware and operating systems. This will cost a lot of people a lot of time and money to replace servers. Why did Microsoft do this? I’ll try to explain the thinking here.

Disk i/o operations per second (iops) is the single biggest constraint in Exchange 2003. A heavy user in E2K3 uses about 1 iops to the disk subsystem. A typical disk drive running at 10,000 rpm can deliver about 100 iops (your mileage may vary depending upon how much caching is in place in the disk subsystem. For example, a SAN will typically cache a lot and give you an effective iops more like 150 for the same disk).

Unfortunately, iops are SLOW, slow like molasses compared to quick in-memory access. An iop needs to wait for disks to spin, and disk heads to move, and processor interrupts, and finally transfers of data over impossibly slow busses. That means that users accessing large mailboxes are slowed way down as well.

The time-honored, brute force solution to slow iops and not enough of them is to keep recently used data mirrored in RAM (called caching). RAM is very speedy and the number of mops (memory operation per second) that can be done is vastly greater. Consider 1066 MHz RAM: that can do 1,000,000 mops. A lot faster than the 100 iops a disk can do (the comparison is a bit bogus because transfer size is not considered, but you get the idea).

Exchange 2003 used as much cache as it possibly could within the confines of a 4GB memory size imposed by 32-bit hardware and operating systems. They even put in a special /3GB switch to tell Exchange to use up to 3GB of cache on a machine configured with 4GB of RAM to tell Exchange that there is nothing else running on the machine and it's ok for it to hog it all like that. So, 32-bit machines are limited to addressing 4GB of memory. 64-bit machines, on the other hand, can address, well, LOTS of RAM (about 17 million Terabytes, which Bill assures us "ought to be enough for anybody", but who's counting).

So by going to 64-bit hardware (which in turns needs an operating system specially compiled and optimized to use the 64-bit hardware) this allows Exchange to make the database cache as large as you can afford.

The difference between a server with 4GB or RAM and one with 32GB of RAM is about $13K. The difference between one with 4GB RAM and one with 16GB is $2K. I think I'll stick to 16GB servers for now, thanks all the same. Microsoft reckons you need 2GB of RAM plus anywhere from 2MB up to 5MB extra per mailbox depending upon how heavy the user is (no fat jokes, please).

So a server with 16GB of RAM can host about 3000 heavy users. 3000 heavy users used to require 3000 iops, which can only be supplied by a whopping 30 disk drives. Definitely expensive SAN territory. And at about $1400 for a 10krpm 300GB Fiber Channel SAN disk drive, that's an extra $42K for disk drives.

Microsoft also reckons that the iops load drops to about 30% of what is was in E2K7. That means that the same storage can be had from fewer, less expensive 500GB 7200 rpm disks, which cost about the same as the smaller faster 300GB drives. We can make do with 18 of these disks instead (or fewer if you venture into RAID5 territory).

So we spend $2K extra for the RAM, but we save $17K on disk drives. Makes sense to me. And it will keep making better and better sense as RAM prices continue to drop, and as the size of disks continue to get larger (for the same $) but spin no faster (hence no extra iops).

Not only is it cheaper, but much larger mailboxes, no longer constrained by the speed of iops, can be used in Exchange 2007, and the same-sized mailboxes are faster to access on loaded servers. All good news.

Couldn’t Microsoft have also put out a 32-bit version of Exchange 2007 to support up to 400 heavy users? Actually, the eval is 32-bits, so it’s clearly possible. Why not support it in production? The cynic might say “sell more hardware and OS licenses?”. As a developer, every extra platform supported costs extra money, and if the world, and especially Longhorn is going 64, well…

So while this is great news if you're going out to buy a brand new Exchange 2007 back-end server, if you have an existing Exchange server you would like to upgrade, chances are it's all wrong for you. Oh well, you needed a beefy 32-bit server for that old accounting package anyways.