If you would like to read part 2 of this article series please go to Overview of E12 Features (Part 2)
Introduction
A new version of popular software is always exciting. “Features!” everyone cries. Everything we dreamt of will be in the next version, the previous version’s clutter and bugs will be swept away by new and rebuilt software. In some cases new versions are a disappointment, bringing as much confusion and software glitches and as many unnecessary features. Sometimes the new architecture is disappointing and actually seems to miss some of the well loved features of the previous version, much to the chagrin of the early adopters.
Exchange 2000 was such mixed blessing. Along with an anticipated move to Active Directory and adoption of Internet standards, the new version presented a very complex architecture with so many components that required manual intervention. While in Exchange 5.5 when you created a mailbox for a user, it was simply created, as expected, while in Exchange 2000, it had to first be created in Active Directory, and then go through all kinds of stampings. This was a bit confusing, especially for people with a single Exchange server. There were also a lot of issues with migration as Exchange 2000 and Exchange 5.5 had widely differing architectures and the bridging and migration mechanisms had a lot of issues and some bugs. Each build of Exchange tried to ease the upgrade process.
Exchange 2003 was perceived as a minor upgrade to Exchange 2000, much like a service pack, except for the rebuilt and much improved Outlook Web Access interface
E12, will be a major upgrade, but not a revolution, which I think is a good strategy at this point in time.
Everybody Loves SQL
Originally, the next version of Exchange was supposed to move away from the Jet store to a new SQL database. Jet has been a popular database store and is also used for DHCP, WINS and Active Directory itself. However, unlike SQL, it has been less than a great solution for a large database such as Exchange.
Exchange is infamous for its database problems. Anyone who has ever had to migrate all the information using Exmerge because of a database problem knows what I’m taking about. A single corrupt item in Exchange can bring a whole server down. I’ve seen it happen.
On the other hand, SQL has always been Microsoft’s most solid product. Unlike Exchange, it hasn’t changed its core for years. It didn’t have to. A lot of features were added but there was no real reason for changing the basic mechanisms. Customers were happy, the server functioned well under all kinds of conditions and proved as fast and as stable as the competitor’s offerings.
After much grumbling, Microsoft decided on making all of its future products SQL instead of jet-based. The first of these was Sharepoint which successfully migrated from an Exchange like database to a SQL one. However, the Jet database is much more flexible than the SQL one. SQL has n-dimensional type tables, making information easy to find. Exchange, on the other hand, like Active Directory, has objects, placed in a tree structure that can vary.
This has caused Sharepoint to lose some minor features in the migration process which was not a big deal, seeing as the product wasn’t as widely adopted yet as Exchange is.
To bridge the gap, the new SQL version, now dubbed SQL 2005, is supposed to bring about an unstructured database type. E12, however, will not use this type of database. Though a version of Exchange actually ran for a while on SQL in Microsoft’s labs, this will have to wait for the next version of Exchange.
Microsoft executives, remembering the Exchange 5.5 to Exchange 2000 migration fiasco, decided not to burden Exchange administrators with having to change their architecture once again while user experience remained the same for most Exchange users, since the 5.5 version.
Instead, Exchange will remain essentially the same, yet a more mature and well-rounded environment.
Continuous Backup
Some of the database improvements that were promised as a result of migration to a SQL database will find their way into Exchange, but using an improved Jet database.
One of these is the ability to replicate changes in on Exchange database to another. Known as “log shipping”, this has been a useful mechanism in SQL for performing continuous backup.
With Exchange you typically will want to backup the entire database during the night. Some will backup incremental changes which is even worse, seeing that on Tuesday you will need many tapes to restore an Exchange database, praying that they are all intact and with correct date labels.
SQL administrators are more used to having a backup set of their databases on a disk drive. A backup database is continuously updated by replicating the updates from the production database. You can always roll back changes or use the backup database for lab tests. You can also have an off-site copy of your database handy in case of an emergency.
There have been a few third party attempts for creating such a mechanism with Exchange by doing bit-level replication for Exchange database and log files, but this was never really reliable nor mainstream. With E12, creating a disaster recovery backup site will become much easier.
Edge Services
Unlike Linux, and other open source software, Microsoft’s offerings are considered “closed”, “propriety” and all kinds of other derogatory terms. This is not strictly true since early on, from the beginning of Windows, Microsoft offered extensions called APIs (Application Programming Interfaces) to programmers wanting to extend its platform. This meant that you could easily make a buck by writing a popular application leveraging Windows mechanisms. Microsoft had a solid operating system, an Office suite and some server offerings but not much else. You needed third-party application to complement Windows, and these became more important as Windows grew and the computing environment evolved.
Native written applications such as Paint(brush) or (NT) Backup might have had their names changed over the years but their functionality remained the same.
When IMF was released for Exchange 2003, this seemed to be a part of the same strategy that served Microsoft over the years. While IMF has nice hidden features and does not require complex tweaking to make it work, it is not exactly robust.
However, it seems, Microsoft is now willing to hurt some of it’s third-party partners by rolling out a more professional offering by the name of “Edge Services”. This departure from its long tradition is apparently a new strategy, seeing as Microsoft is inching into new software territories all the time and will soon be offering its own Anti-virus (and also replace Paint and Windows backup with free more robust programs).
Edge Services is essentially a sophisticated system of mail relaying. For large enterprises, it allows to implement a three-tier protection:
SMTP Gateway Will accept e-mail from the Internet and will protect you from basic SMTP based attacks.
E-mail message hygiene server – Will extend the IMF component, weeding out Junk Email and also check e-mail for viruses. It is unclear at this point whether Microsoft itself will provide its own anti-virus mechanism though third-party support is still promised.
E-mail routing hub – Not really a new feature, as this existed in some form from the Exchange 5.5 days, also known as a gateway or routing bridge server.
For smaller organization, the benefits of Edge Services will be tighter security and more protection options such as anti-phishing, anti-spoofing and SenderID support as Microsoft strives to prove that it is serious about security. Some of these features will debut in Exchange 2003 SP2 and will be updated later on with the E12 release.
Outlook Auto Setup of Profiles
Outlook was designed to be different entity than Exchange, unlike, say, Lotus Notes and the Notes client. It seemed over the years that Microsoft made some zigzagging in terms of how Outlook relates to Exchange.
One of the annoying features that remains to this day is the inability of Outlook to determine the appropriate Exchange server for a user. This is a bit silly, seeing that the information is handily available on the nearest global catalog server. The new wizard provided with Outlook XP and 2003 is perhaps more user friendly, but takes more time to configure manually.
There are some ways for automatically configuring Outlook for Exchange but these are not straightforward and take time to learn and implement.
What Exchange administrators really want to see is the ability to configure Outlook using GPO settings in Active Directory. Since this requires a change in the architecture of Outlook, the benefit of automatic configuration will probably only be available to Outlook 12 and perhaps back ported to Outlook 2003.
E12 will also have an extended ability to verify client configuration and build to prevent connections from unsecured clients.
Redesigned ESM UI
The Exchange 5.5 UI was a real mess. Lots of configuration pages, almost no wizard, conflicting settings. The Exchange 2000 UI, based on the new MMC interface now used by most Microsoft applications improved the situation some, but not by much, adding some of its own confusion.
Unlike Office, where all the applications look the same, the Back Office applications were only the same because they were written for the Windows platform. ISA, SQL and Exchange have widely differing User interfaces.
Microsoft decided on a creating the WS System Common Engineering criteria which will create similar looking server applications, based on the same scripting language and updated by a single mechanism.
ESM will now look more like one of the brand new Microsoft server applications, based on MMC 3.0. The new ESM will look much like the new ISA and MOM versions, providing administration web pages inside MMC when you click an object.
Each ESM component is, behind the scenes, a “Monad” script. Monad is actually developed for the Longhorn (now called Vista) wave of Microsoft products as a universal scripting language resembling the UNIX shell languages. This means any Exchange operation can be scripted using the command line as demonstrated here:
http://blogs.technet.com/exchange/archive/2005/08/16/409299.aspx
Updating Exchange will also be much easier, based on MSI 3.0. Updates will be incremental, delta-based and will require less restarts.
64-Bit version
My very first network as a system administrator had a 64-bit version of Windows NT, run on the Alpha platform. This version no longer exists, since the Windows 2000 beta was dropped, but now 64-bit is back with a vengeance for the Windows platform. Why should you care? By the time E12 is released all new servers will support 64-bit. This will tempt even small Exchange shops to buy a 64-bit version of E12. The next major version of SBS is promised to be 64-bit only.
64-bit promises increased software stability and better use of your hardware and will probably become mainstream in upcoming years for server applications. Though 32-bit support is promised on 64-bit platforms I would not recommend running Exchange 32-bit third-party components such as anti-viruses and fax packages on a 64-bit platform, so you should probably ask your vendor for a new version before making the leap.
Improved search functionality
Microsoft is constantly trying to improve search functionality with Exchange, by indexing the Exchange information. This usually relies on existing Windows indexing components.
The next version might just get it right by combining new technologies that are supposed to create smart indexing based on Google-like technologies. These technologies, already in beta as part of the MSN search services, working on the client side, will make the transition to server side with E12, and later on with the Longhorn (Vista?) server.
Web Services API
As Exchange grows, more interfaces are added to it, but most of them matter to developers, rather than end users. Adding Web Services API to Exchange means it can serve information over the web more easily.
It’s easy to dismiss this as one more interface. However, this API might become a major player in the way applications communicate with each other. I wouldn’t be surprised if this technology will be used in the future for standard Exchange and Active Directory communications instead of RPC or SMTP.
Mobility
OMA was designed the text only version of Outlook Web Access but since then all of the major mobile vendors decided to support ActiveSync, so OMA is on its way out.
Seeing the way the mobile market evolves, this is probably a smart move by Microsoft.
Some new ActiveSync features planned for E12 will already be available with Exchange 2003 SP2, but I expect event more features to be available, making mobile devices closer to their PC cousins in terms of functionality.
Outlook Web Access
One area that has been continuously improving through the years is the Outlook Web Access interface. The next version will have more Office related features available through OWA. The general idea is to make OWA as similar to Outlook as possible, providing access to forms, Sharepoint, DRM and other features. Eventually, I expect, OWA will have more new features than Outlook since it is easier to update for a large number of clients.
This will increase the use of OWA as an Outlook alternative.
Unified messaging
This is also an area previously only covered by third-part applications. Do you want Exchange to read you your e-mail? How about using Exchange as a fax solution or phone message service?
This seems to be one of the more exciting new features in E12, and one the first in many years to provide actual enhancement to the desktop and will probably be promoted as the “killer” feature of E12.
The unified messaging components in E12 already exist in some form in other Microsoft products such as Speech Server and the SBS fax solution so this will not exactly be version 1 of this solution. This is not to say that it will be bug free, as most unified messaging solutions are, but at least it will be a useful tool, and promote the use of these cool technologies in the mainstream market.
Improved Calendaring functionality
There are numerous calendar add-ons out there, some free for improving groups scheduling, booking resources and more. Some of these were actually written by Microsoft employees, partners and MVPs. With E12, Microsoft aims to integrate these capabilities into Exchange.
Conclusion
E12 promises to be an exciting product, building on the success of existing technologies, and thankfully not trying to jump too high. Expect thorough testing of this product in Beta and during the rest of 2005 and 2006. Microsoft will not release this product before it’s ready, but when it does it’s expected to be one of the better releases of Exchange.
f you would like to read part 2 of this article series please go to Overview of E12 Features (Part 2)
