BeingExchanged

Musings on Microsoft's Messaging and Collaboration Platform: Exchange Server

Back to Basics: The Mailbox Role in Exchange 2007/2010

The Mailbox Server Role (MBX) has evolved dramatically since the days of the Back End server in Exchange 2003 and earlier. While these database servers used to also be responsible for handling most types of processes, they’ve become highly specialized devices with Exchange 2007; and even further specialized in the 2010 version of the platform. You can put other roles on the MBX server, but this role itself is now strictly for the processing of mailbox and Public Folder data, and nothing else.

Exchange 2007 started the process by removing the POP3, IMAP and OWA communications platforms from the overall responsibilities of the MBX role. This meant that all non-MAPI clients would communicate exclusively with other roles, and it would be those roles that would move information into and out of the databases that the MBX role managed. Outlook clients still communicated directly with the MBX role for their mail interactions, but only when connecting via the MAPI protocol.

In Exchange 2010, even MAPI connectivity was removed from the MBX role, allowing this set of tools and solutions to focus exclusively on managing and maintaining the databases that drive Private Mailboxes and Public Folders.

The MBX role is not inconsequential, however. This role is responsible for receiving mail from the Hub/Transport role, and properly committing it to the appropriate mailboxes stored within its databases. In Exchange 2007, this role performs all necessary activities to provide replication to another copy of the database locally (LCR), within an Active-Passive cluster (CCR) or across a WAN (SCR). Though failover was only present for CCR, the management of the database replicas was a critical function of this role that would put significant strain on the hardware the MBX role was run on. Typically, Microsoft would either require that all other roles be on other servers (CCR); or strongly recommend it (LCR and SCR) so that the MBX role did not get bogged down, or slow down other roles in the process.

In Exchange 2010, the MBX role is still responsible for Disaster Recovery and Availability for the databases housed on it. This is now accomplished by creating and maintaining multiple copies of the data on other MBX role servers, with a process known as Database Availability Groups (DAG’s). The overhead of the process has been greatly reduced, so while Microsoft still recommends putting other roles onto other servers, they are now allowed to run on MBX role servers if required.

The MBX role holds many other functions (Archiving, Searching) but those described above make it quite clear why this is a mandatory role for any Exchange 2007 or 2010 environment.

Next week, the Hub/Transport role!

Back to Basics: Server Roles in Exchange 2003

Following up on last week’s post, let’s discuss the different server roles in Exchange Server.  Prior to Exchange 2007, there were only two roles that an Exchange 2000 or 2003 Server could hold.  Though they were known officially and otherwise by several names, most people came to know them as simply “Front-End” and “Back-End” (FE and BE).

FE servers were used in order to offload some of the Internet-connectivity and processing from the Mailboxes and Public Folders.  FE systems could run common Internet-standard protocols like POP3 and SMTP, as well as providing a connection point to mobile users via Outlook Web Access.  This was a very limited role, meant solely to offline processing overhead away from the servers that were holding Mailboxes and Folders, and they were not required to exist at all.  Typically, only larger shops would implement these FE servers, in order to handle the high load of many remote users attempting to send/receive/manage their email from a variety of web-based and 3rd-Party clients.

BE servers, on the other hand, were a required component for Exchange 2000 and 2003.  These servers held all databases (Mailbox and Public Folder) and managed all communication to the internal organization.  This meant that they are responsible for maintaining database operations and moving all email and folder messages around those databases.

In addition, BE servers were the only contact point for MAPI clients – the native Exchange client found in Outlook.  While an Outlook client might initially use a FE server to find the mailbox; once connected, Outlook communicates directly with the BE server from that point on.

If no FE server is present, the BE server also managed external mail.  This means it can host POP3, IMAP and SMTP connectors that allow it to communicate with the outside world, in addition to Outlook clients internally.

Simply stated, FE servers (when present) would talk to the world at large and to the BE servers.  BE servers communicate with internal clients and with other BE servers, as well as the outside world where FE servers are not in play.

Next week, the Server Roles in Exchange 2007 and 2010. 

Back to Basics I: Databases

I figured it was about time to get back to my roots of explaining Exchange Server technologies in plain English.  No small task, for sure.  Let’s start today with the basics of Exchange Databases.

Exchange Server has used databases of one form for another since its inception as an enterprise mail platform.  While many think that Microsoft SQL server would be the database platform of choice for Exchange Server, the truth is that Microsoft has never used that codebase for the email and collaboration platform tools.  Instead, the Extensible Storage Engine (ESE) is used to house email information and other components of the Exchange architecture.

ESE is built on the Joint Engine Technology platform, and therefore is often referred to as the JET Engine (getit?).  Either term can be used to describe the database engine behind the Exchange Server storage architecture, but ESE is used most often in official documentation, as there are several flavors of JET engines used in various Microsoft systems.

In Exchange 2000 and 2003, the ESE included 3 moving parts.  First is the transaction log system, which keeps a running tab of all operations performed to databases, allowing for recovery of lost transactions when required.  Since the data tables will employ a memory-based caching system to speed up writes, having a running transaction list becomes critical to getting the system back up after unexpected reboots and other semi-routine operations that might not allow the cache to clear.

As mentioned above, there are data tables that are also used for these versions of Exchange.  The EDB file contains all MAPI-compliant data that runs through user mailboxes on the Exchange Server.  The STM (for STreaMing) database contains all other email information that’s not native to the MAPI protocols used in Outlook clients.

An Exchange Database (or Storage Group) will contain a unified set of transaction logs, and at least one EDB and STM database.  There can be more than one set of EDB/STM databases, but all files for each Storage Group must reside on the same physical server or cluster.  The most common configuration for Enterprise Exchange Configurations was one set of Public Folder databases held in a Storage Group, with a second Storage Group being used to hold user Mailbox data.  In larger organizations, there we multiple Mailbox Storage groups, each holding one or more EDB/STM file set, and sharing a common log set.

In Exchange 2007 and 2010, the STM file type was dropped as there was no longer a differentiation between MAPI and non-MAPI data from an Exchange perspective.  Now, all data is stored in an EDB file.  The transaction logging is still in play, however now there is one set of logs and one EDB per Storage Group, instead of possibly having multiple data tables.  While you could group together multiple data tables, this prohibits you from using most of the advanced features of Exchange 2007 and 2010, so it is rarely done these days.

Information flow through the databases is very similar to data in Microsoft SQL databases.  First, a log write is created to begin the operation.  Then data is either read from the table in question or written to cached pages from the table, depending on what operation was called for.  Each read or write is flagged in the logs for continuity, so that no operation can occur without a corresponding log entry happening first.  As the page writer systems take data from the cache and commit it to the database files on disk, the log is again updated to reflect that the transaction is complete and checkpointed. 

This is a bit of an over-simplification of how the system works, but it does outline the basic procedures Exchange uses to store information as data flows through the server itself.

Next week, we’ll talk about the various server Roles, both in Exchange 2003 and in the more current versions of the Exchange Server Platform.

Should you install Exchange 2007 SP3?

Exchange 2007 SP3 has been out for a while now, and many folks are asking how necessary it is to upgrade?  This is probably due to a lot of the press reporting that the Service Pack was dedicated mostly to preparing an Exchange 2007 environment for upgrade to Exchange 2010.  While this is true, there are some key updates that may prompt you to update to SP3 even if you’re planning on staying on Exchange 2007 for a while.

Server 2008 R2 Support

Up until now, Exchange 2007 has only run on Windows 2003 and 2008 x64 editions.  If you need to upgrade your server hardware at some point, you’ll probably be moving to Server 2008 R2.  Therefore, using the SP3 version of the Exchange 2007 bits is a requirement for most organizations, and you might want to just start using SP3 now.

Administrative Support for Windows 7

Many administrators prefer to manage their Exchange Server environment from their desktops, and up until Windows 7, this wasn’t a problem.  However, because of the new architectures in Windows 7, the pre-SP3 versions of the client tools wouldn’t install or function correctly.  SP3 brings an updated version of these tools, which can be installed and will run without any problems.

Better Password Reset Tools

When an end-user’s password expires, it is very difficult to change it directly.  This is because the end-user must provide a valid password to reach the “Change Password” page.  There are methods for setting up a password change site within your domain, but those sites are publically accessible, and not easy to use for the end-user.  It also didn’t work at all for Windows Server 2008-based IIS servers.

In SP3, you can enable a new feature that allows Exchange 2007 CAS servers to auto-redirect end-users with expired passwords to a reset password page.  This allows the end-user to securely input a new password, without having to manually navigate to another site first.  It also works on both 2008 and 2008 R2, allowing for more server configurations.

You can find out more about how to enable this feature (it is off by default) via this TechNet article.

Other Updates

SP3 also brings in a new version of Microsoft Search, 3.1.  This has several feature and performance enhancements that will benefit Exchange Server 2007 databases and operations.  Support for right-to-left disclaimer text is implemented in the Service Pack, which comes in handy for auto-signatures in languages that use a reverse-order reading pattern.

And, The Stuff We Knew About

Of course, the biggest change was the Active Directory updates to prepare the organization for migration between Exchange Server 2007 and Exchange Server 2010.  The Service Pack contains many updates specifically geared toward allowing a period of co-existence where both versions will be in play until the migration is complete.  If you have Exchange 2007, and you’re going to be moving to Exchange 2010, upgrade to SP3 now and save yourself a lot of headaches later.

SP3 is a good bet, even if you’re not planning on upgrading to Exchange 2010 in the near future.  The new functionality, updates and hot fixes, and other patches installed by SP3 will bring your Exchange Server closer to being “up-to-date,” and when time comes to begin the 2010 upgrade/migration, you will be one step closer.

As with all Exchange Server 2007 Service Packs, SP3 can be installed either to a server already running Exchange Server 2007 RTM, SP1 or SP2; or it can be installed to a server that is not running Exchange Server at all to create a new Exchange Server.  If you are installing to Server 2008 R2, you must use this version of the Exchange Server 2007 bits, or the install will not function properly.

Happy Service Packing!

Version affinity on Hub/Transport servers

Two post this week, as I realize I haven’t talked about – you know – Exchange in a while!

Many clients of mine are in the process of migrating from Exchange 2007 to 2010, or are planning to do so in the next 12 months.  This can lead to a few specific challenges that weren’t present in other migrations (say, 2003 to 2010) because certain restrictions were not in place or just didn’t exist in earlier versions of the Exchange Server Platform.

One that most will find out about the hard way is that different versions of Hub/Transport servers will not talk to the opposite versions’ Mailbox servers.  For example, an Exchange 2007 H/T server will not send mail directly to an Exchange 2010 Mailbox Server.  This means that you can’t just build the new Exchange 2010 Mailbox server and have everything route via the existing 2007 H/T platform.

Why this is important?  When configuring new systems for migration, you may not wish to build out the new, redundant front-end servers (CAS, H/T, etc) while you still have the existing, redundant 2007 roles up and running.  The extra hardware costs and administrative overhead might lead you to want to leverage the existing platform for mail routing, while you migrate your users via mailbox-moves to the new Mailbox servers.

The issue is that, due to changes in both AD interactions and the API for transport routing, the two versions’ H/T roles can’t properly communicate with the opposite back-end systems.  Originally, the thought was to go so far as to require independent domains for 2007 vs. 2010 platforms, but wisely the Exchange Team realized that this would make upgrades nearly impossible.

The trade-off was to lock each Mailbox Role to the same version’s H/T Role, and permit cross-platform mail to flow from Hub to Hub only, as opposed to Hub to Mailbox directly.  Slightly restrictive overall, but also logical and easier than the alternatives that were proposed.

How do you get around this?  Well, you don’t.  If you need to have a period of co-existence during your migration (which is almost definite), then you will need to set up at least one Exchange 2010 Hub/Transport server in order to allow for mail routing during the co-existence window.  As you get more and more users on the new platform, you can re-purpose 2007 H/T servers by reinstalling Windows and setting them up at 2010 H/T servers.  Just remember to leave at least one H/T for 2007 running in each site until you fully remove 2007 from your organization.

For more info on this, you can read the Exchange Team Blog posting on the subject here.

I’m Taking the Pledge!

Over at AGeekBlog, my buddy @Brian_Bell posted an intriguing article about the responsibility of the blogosphere and the Net in general to properly handle sensitive information that may fall within our sphere of influence.  The point is that security breaches that happen because someone with access to sensitive information can – and do – cause harm to others. 

His case in point was the Wikileaks publishing of thousands of pages of classified data from military sources regarding the wars that the USA is currently engaged in.  Exposure of this data can endanger troops and civilians in several theaters of operations, and should never have been allowed.  While many will argue (in some cases correctly) that these documents detail missteps and mistakes that have already caused loss of life, this doesn’t excuse the poster’s irresponsibility in endangering thousands more.

His point is interesting because – while citing that this leak could have been prevented – he highlighted that the issue is not solely that this information got out to the American public.  Brian points out that the information is available now to all those who would use it to harm the very public that the leak was supposed to serve.  Nothing is ever private on the Internet. No matter how tight the “security” restrictions you place over your online profiles, anyone can see anything you post if they try hard enough. 

This means that if you leak a story to stop corporate corruption, you may inadvertently create the means for another company to successfully hide the same acts.  Leaking information about one company passing blame to another for some misconduct can create the ability for both companies to better hide their tracks, now and in future.  Exposing the missteps of government agencies in high detail can give your own enemies information that they can use to exploit your own side.  The very same people you seek to harm can use the information to harm others, and more importantly; people who you had no idea wanted to cause harm can use the information just as effectively.

This isn’t to say that Wikileaks is wrong to post this information.  That is a moral decision that must be made by the poster and the website.  Reading the information and acting on it are also moral decisions that must be made by the readers.  Legal implications aside, I can’t say for sure if the posting was morally wrong, or right.  However, I can say that the impact of this leak will reach far beyond the poster’s intentions, and I can only hope that they realized the repercussions of their actions in deciding to post or not to post.

As for me, I’m following Brian’s lead and asking my fellow Blogger, Journalists and Readers to do the same.  I will not knowingly publish information that could cause harm to another person.  If I am not sure of the impact of the information I post, I will seek assistance from others to determine the true impact of this information before I post it.

Yes, we – as Journalists – have a responsibility to expose the truth and stop harm from coming to others.  However, this doesn’t excuse us from having to determine and understand the impact of that exposure.  Writing a story on government corruption is one thing, leaking the raw documentation that can cause much more harm than good is another entirely.

Think before you post. Know what you’re posting.  Most importantly, know the impact of what you are posting as completely as you can.  We all have a moral and ethical responsibility to be aware of the impact of everything we post.  Then, and only then, can we post information with authority and live up to the trust our Readers place in us.

No Post This Week

Hello, faithful readers!  As you folks probably already know, Double-Take Software (my employers) are announcing some great news this week.  In order to give them the whole stage, I’m not going to be posting a new blog entry this week.

Instead, head on over to http://www.doubletake.com and see what’s going on!

See you next week.

- Mike Talon

#EXCHhelp it is!

After quite a few responses (and with help from @SQLVariant), it appears that #EXCHhelp is the preferred hashtag for those looking for Exchange Server assistance on Twitter.

Please spread the word!  Also, remember that community is the cornerstone of this idea, so feel free to keep an eye out for the #EXCHhelp hashtag and answer questions when you can.

#EXCHHelp or #EXCHGHelp?

@SQLvariant posted on his blog about my request on Twitter for a hashtag for those seeking help with Exchange Server issues.  These were the two finalists, so I figured I’d put it out there for those who have an opinion!

Hop on Twitter and ping @SQLvariant and @TalonNYC (that would be me) and let us know what you think would be the better hashtag!

My Android Messaging Experience – or: What I Do for My Readers, Part II

Most of my readers know that I really like my Blackberry Smartphones, and that I’ve had them since back in 2001 in one form or another.  Lately, I’m on the Bold 9700 and loving it.  However, from time to time, I try out other Smartphone platforms so I can see how the Exchange ActiveSync (EAS) solutions work on non-BES devices.  I can’t try the iPhone because I’m not on that special carrier who shall not be named, but I can definitely have a go at several others.  This time around, it’s the Android-based Samsung Galaxy S.

The variant I used for this trial run was the Vibrant from T-Mobile, which appears to be very close to the Galaxy S distributed in Europe, and at least similar to the other variants being released here in the US on other carriers.  I worked with the stock OS (Android 2.1) and didn’t add anything but a gel-skin case and a larger Micro-SD memory card.

Android has made great strides in becoming more closely aligned with the Microsoft Exchange Server platform. By incorporating EAS into the mail/messaging client, they have now got the ability to communicate directly with an Exchange Server, which would usually would indicate a move toward the business market.  Unfortunately, hands-on experience doesn’t bear out that hypothesis.

After getting the basics set up, I was able to open the Email app (NOT the “Messaging” app, which only does SMS/MMS) and begin the EAS setup.  For the most part, it wasn’t difficult to configure at all, with a wizard that walks you through the configuration.  The system will first try to AutoConfigure if it can find an Exchange 2007 or 2010 CAS server, and then will prompt you for your webmail server address if AutoConfigure isn’t successful.  You supply your name, password, etc – much like with other EAS software.

Once the basics are set up, your email, calendar and contacts will sync with the mobile device.  You can change the basic settings quickly, allowing the device to store more or less data, setting up a return address and signature, etc.  The configuration options are similar to what you would find on Windows Mobile, so I can’t find fault with them.

That’s when the wheels began to come off the wagon. 

First and foremost, while the native Email app can handle POP3, IMAP and EAS, you can only have one signature across all accounts.  Since the device is designed to handle multiple accounts at once, it should be able to set up personalization (i.e. signatures) for each, but that’s not the case.  I can overlook this, as it will probably be fixed in a software release in the near future, but the problems didn’t stop there.

While syncing is hassle free, not all folders on my Exchange account would sync properly.  The basics were no issue, with the Inbox, Sent Items and Deleted Items being properly synced without fault.  The personalized folders I created via Outlook (and that were on the Server, not in a PST) did not sync correctly.  I could see that the folders existed, and they were set for sync, but no mail ever showed up in them.  This is problematic for those of us who like to keep the Inbox clean.  Speaking of which, a “Move to … Folder” menu item would have been a good idea – but couldn’t be found.  Note that the EAS system in Android syncs only email, contacts and calendar items, not Tasks or any other Exchange information.

The contacts system was a bit difficult to navigate, but very easy to search – as you’d expect from a Google-made OS.  Finding people in your contact list was not a problem overall.  The calendar application was surprisingly sparse.  Bare-bones functionality was there, but not much more than you’d get in Outlook Web App or similar webmail platforms.  A personal peeve, the Map It function for the “Where” field is only available if you edit the appointment, not when you’re just viewing it. I suspect that’s just an oversight, and will be corrected in Android 2.2.  Overall, the functions for calendar and contacts are suitable for most business users, about on par with other mobile platforms, though with all the other visual aspects of Android, I would have liked to see these tools be a bit more full-featured.

Creating new messages was straightforward, but typing the message itself was problematic. Once you are creating a new email, you can use the soft keyboard (or on some phones, a hardware keyboard) to create your message.  The Galaxy S is equipped with Swype, a soft keyboard extension that allows you to drag your finger from letter to letter to form words, instead of tapping out each letter.  This allows for a more natural predictive-text system, and minimizes errors.

Minimizes, but does not eliminate.  You can still tap in words that are not spelled correctly, and if you do it enough, Swype will “learn” the misspelled word. This, coupled with no spell-checker in all of Android makes for a very easy way to generate typo-filled email messages.  Every other Smartphone platform includes a native, integrated spell-checking software package of some kind.  Amazingly, Google has neglected this entirely, as there is no spell-checker included for any version of Android.  3rd-Party apps are available, but due to the way the messaging system works, they cannot integrate with the Email, Gmail or any other app.  You must put your text into a notepad-like window, spell check it, then copy and paste to your message.  This is totally unacceptable for a business device.  I know how to spell, but everyone makes typos.  Swype can minimize them dramatically, however that’s not the same as having an in-line spell-check system that can flag errors as you go.  Barring that, even a “check before sending” utility would have been more acceptable than the none at all method currently in play.

Finally, the battery life on the Galaxy S is unacceptable.  I do not expect any non-Blackberry Smartphone to be able to run for more than about 10 hours or so on a charge.  With larger screens, and faster processors, Smartphones are power-hungry animals and therefore can’t possibly run as long as the lower-speed and lower-power Blackberry handsets.  However, after fully charging the Vibrant (which took close to four hours), I was able to only get just over four hours before the battery warning started popping up.

Looking at the power app, I was able to see that the screen was using 81% of the power consumption, even though it had been dimmed to about 70% (any lower and the screen is invisible in sunlight).  Since the device would be used for messaging in the business world, and that means using the screen quite often to check and send mail, that is the use profile I went with.  No WiFi, Bluetooth on, but not connected, and GPS off – just over four hours with no phone calls at all when the phone wasn’t plugged into a charger.

I can say that the device was a wonderful Personal Media Player (PMP) device.  Videos were crisp, bright and beautiful on the 4 inch screen.  The media player worked well for audio playback, making it a suitable replacement for an iPod or similar device. So for a consumer Smartphone, this would probably be a great option for those who don’t want to go down the iPhone route.  The Android Market is stuffed with tools and utilities for just about every need (except integrated spell-check and/or multi-account personalization). So if you need an app to perform a function set, you’ll almost definitely find it quickly.

Here’s the final verdict:

The Galaxy S is a spectacular consumer-focused Smartphone.  It is a true competitor to the iPhone and has as much – if not more – functionality in the home-user market.  It is not, however, a suitable device for those looking for an EAS-based business device.  Lack of basic business tools (like personalization) clearly show the platform’s immaturity, and we’ll just have to wait a bit longer for a business Smartphone competitor to Blackberry’s reign.

Note: I have not received review units or other consideration from either Research in Motion or Samsung. Units mentioned were purchased by me, though the Android device will be going back =)

Switch to our mobile site