Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

   

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath
 
   

Testing Exchange 2007 - Part 1

Page 1 | Page 2

Changes to Device Drivers

In Windows today, and in Windows 2008, most device drivers must interface with the kernel to be able to communicate with the hardware in the computer.  (Note: Windows 2008 and Vista have replaced some kernel level driver support with a mini-port driver model that doesn't require 3rd parties to develop kernel level drivers anymore).  This requires that they are using the same size instruction sets of 1's and 0's, or information bits.  On x64 they are 64-bits long and on x86 they are 32-bits long.   So this requires that devices drivers are now "64-bit", which requires recompiling of them.  Therefore, we are now talking about a recompiled OS, driver, and application (Exchange).  As any developer knows, when you recompile your code with a different compiler changes sometime have to be made.  In addition to those changes, the OS, Exchange, and maybe even the drivers, have to have sections of code re-written to take advantage  of the new 64-bit memory registers, which in turn allow them to access up to 8 tebibyte of memory (in theory).  They also could have had sections of code re-written to utilize the other improvements in the x86-x64 architecture.  Of course with any code changes, including those made during recompiling, comes the chance for errors or unexpected results. 

This has a two-fold impact on Exchange or Exchange related software that requires special hardware, like faxing boards, RAID controllers, chipset features, and more.  First the vendor has to write new drivers to talk to their hardware on Windows x64, without the new driver the OS will not recognize the new hardware.  Second the code in Exchange or related add-on software may need to be re-written to work with the new driver.  So now you have a new version of Exchange interfacing with a new version of an application, which is communication with a new device driver, which is all running on a "new" OS (to most organizations and software vendors).  A symptom of this scenario is currently being seen with Windows Vista and many games.  These Issues are mainly due to the driver changes required in Vista and vendors (including Microsoft) providing poorly written drivers.  Having your game or Vista crash is one thing but have your Exchange server crash due to a bad driver is a completely different thing!  So any Exchange related software that requires special hardware, like faxing, Unified Communications (UC), backup, and others will need new versions and updates.  Some vendors, like the UC, calendaring, and faxing ones, may even choose to exit the market due to the new features in Exchange and the cost of redevelopment to work with Exchange 2007.

Deemphasized Functionality

So what does "Deemphasized" means?  Well on the surface this means that Exchange 2007 has support for these features but there may not be support for them in the next version of Exchange, code named E14.  But at a deeper level this could also mean that less testing and re-coding emphasis was done in these areas when Exchange 2007 was being tested and developed.  I then read into this that there may be a higher chance of bugs or "undocumented features" in these areas.

One big issue with Exchange to date has been the various ways developers could develop a solution for Exchange.  Basically, there were four or five ways to get at some data in Exchange or to do some tasks.  Therefore, developers had to choose the best, quickest, or most reliable way to interface with Exchange.  The problem is that based on what the solution was doing one interface might have been more reliable, but slower, or well documented but less reliable, etc.  So Microsoft decided to draw a line in the sand, a somewhat broken line, with Exchange 2007 and say some methods should not be used moving forward, since they may not be in future version of Exchange.  Others were completely dropped in E2k7, most of those were deemphasized in E2k0 or E2k7.

For application developers who are using any of the methods below, the writing should be on the wall that they MUST start looking at some of the new interfaces in E2k7, like Web Services.  While their application might work on E2k7 today, chances are very good it will not work with E14.  In addition, they may run into issues today due to changes caused by the transition to x64 and others.  So some developers may have to make the hard decision to fix their exiting code to make it work with E2k7 or provide a new version that only works with E2k7.  This type of decision is likely to cause some companies to stop development certain products for Exchange all together or not to support E2k7 for awhile while they fix issues that make their application incompatible with E2k7.

List of Deemphasized features:

  •  Public folders

    • Management

      • E2k7 RTM had no UI for public folder management or OWA access.

      • SP1 will provide some support, but some features that were in Exchange 2003 may never make it to the Exchange 2007 UI.

    • Organization Form

      • SharePoint and\or InfoPath is the suggested replacement.

    • Free/busy

      • Free/busy like support is provided by the Availability service

      • E2k7 will still update system public folders for legacy Outlook 2003 and earlier clients.

      • Outlook 2007 can use pubic folders data or the Availability service, which utilizes web services

  • Proxy or e-mail address generation

    • The Recipient Update Service (RUS) stamped addresses and other attributes on Exchange enabled objects in Exchange 2003\2007.

    • The RUS does not exist in Exchange 2007, it has been replaced by Exchange Management Shell (EMS) PowerShell cmdlets or "command lets".

      • The Exchange Management Console (EMS) is actually built on top of EMS cmdlets.

      • When an object is created in the EMS or EMC all required attributes are now set at creation time, unlike the RUS which queried for objects on a scheduled bases and then finishing provisioning the object.

    • Applications\code that only sets the minimal attributes for Exchange objects when it creates them will need to be re-written since the RUS will no longer set them. This can include, but is not limited, those use LDAP and CDO.

  • CDO 1.2.1

    • COM-based API used to primarily access mailbox objects

    • Provides a programmatic interface to objects in Exchange. This interface, or API, was commonly used by VB and VBScripts

    • Unlike previous version of Exchange CDO support it is NOT installed by default on Exchange 2007 servers

      • So if you have a server based application that uses CDO it will need to be installed on the E2k7 server. It can be downloaded here.

    • Exchange Web Services is the preferred interface in the place of CDO 1.2

  • MAPI32

    • MAPI is primarily a client protocol used by applications to interface with Exchange in a COM-like fashion

    • For more information see "Outlook, CDO, MAPI, and Providers Work Together"

    • Like CDO MAPI32 API support is not installed by default on E2k7 servers

      • It is included in a single CDO-MAPI package, which can be downloaded here.

    • Exchange Web Services is the preferred interface in the place of MAPI32

  • CDOEX (CDO 3.0)

    • Yet another COM based API that provide access to Exchange Data

    • Exchange Web Services is the preferred interface in the place of CDOEX

  • ExOLEDB

    • Used to access the Exchange store using OLE DB and ActiveX Data Objects (ADO) by using a Structure Query Language (SQL) syntax

    • Exchange Web Services is the preferred interface in the place of ExOLEDB

  • Exchange WebDAV extensions

    • Provides remote, HTTP, access to the Exchange store

    • Exchange Web Services is the preferred interface in the place of WebDAV

  • Store events

    • Used to provide procedures that respond to events that occur in the Exchange store

      • i.e. Sending of a message, saving of an item, etc

    • Exchange Web Services Event Notification service replaces store events

  • Streaming backup APIs

  • Exchange 2003 Virus Scanning Application Programming Interface (VSAPI)

    • The recommendation is for Anti-Virus vendors to build Transport based agents for E2k7

    • For more information see "Planning Antivirus Deployment" in TechNet

 

For more details on migrating from CDOEX, ExOLEDB, MAPI, Public Folders, Store Events, WebDAV, and Web Forms see this TechNet reference.

As you can see from above, 3rd party and internal developers have their work cut out for them to migrate their code based on the above methods to the new interfaces in E2k7 and later.  Even for those applications, that do use the above methods, they must be tested since bugs might have appeared in the porting and re-compiling of the Exchange 2003 code to 2007.  So I feel that all of these applications are suspect until validated against Exchange 2007.

Discontinued Features

Since these features are discontinued there really isn't much to test against since any application based on them should just not work.  So any application that uses these methods much be replaced with a new version from the developer or vendor or replaced with a different solution.  Here are a few areas to think about when trying to discover or come up with those applications.

  • WMI classes
    • Multiple system management and monitoring solutions have used\use WMI to get data out of Exchange.
    • Exchange Web Services is the preferred replacement for what used to be provided by WMI.
  • Support for multiple top-level public folder hierarchies
    • Check in Exchange 2003 System Manager and see if there are multiple trees under <Admin Group>\Folders. If there are you will need to find what applications use those other than the default "Public Folders" tree.
    • SharePoint is the preferred replacement for public folder based data.
  • Transport event hook or Event Sinks
    • There were used to intercept messages before they were sent to Exchange for further processing.
    • Some 3rd party spam filtering software utilized transport "sinks", for example.
    • E2k7 Transport Agents are the preferred replacement.
  • Exchange Installable Files System (ExIFS)
    • This commonly used by web based solutions to access data in Exchange.
    • Sometimes called the M: drive, which appeared only in Exchange 2000.
    • Exchange Web Services or MAPI are the preferred replacements.
  • ExMerge
    • While ExMerge is actually an application some companies have development solutions, mainly for DR purposes.
    • EMS cmdlet Move-Mailbox supports and export option to PST in the RTM version, SP1 will add support for importing PST data to a mailbox also.
  • Exchange 5.5
    • You cannot install Exchange 2007 into a mixed (5.5\2003) mode Exchange environment so you have to get rid of Exchange 5.5 before you can migrate to 2007.
  • NNTP
    • Some applications maybe accessing public folders via NNTP.

 

Again see this TechNet reference for more information.

Changes That Impact Other Areas

Besides those that have been deemphasized or discontinued you need to be worried about some of the areas below when it comes to applications.

  • OWA
    • OWA was completely rewritten for E2k7 so any code or customization build for OWA will need to be redone.
  • Backup software
    • Although streaming API support has been deemphasized it is the most common backup method for Exchange today.
    • There are multiple changes in the Exchange database that might affect your backup software. In addition to those changes E2k7 now supports LCR, CCR, SCR (in SP1), 50 storage groups or database.
  • Disaster recovery
    • With the addition of LCR, CCR, and SCR support DR plans should be revisited and revised.
    • ExMerge is not longer support which can also impact DR plans, ExMerge has been replaced by Export-Mailbox and Import-Mailbox cmdlets in E2k7 SP1. See this EHLO Blog reference for more information.
  • Recipient Management
    • ADUC can\should no longer be used to manage Exchange related attributes\settings in the AD. The EMC or EMS must now be used.
  • Message delivery troubleshooting
    • Routing is now based on AD sites and the tools used in E2k3 have been replaced by new tools in E2k7
  • Bulk management procedures
    • Those that used to be done with VBScripts or custom code may need to be replaces with EMC cmdlets.
  • Transport rules
    • These are like Outlook Inbox Rules but process EVERY messages sent or received by an E2k7 server running the Hub Transport (HT) role.
  • Anti-spam and Anti-virus solutions
    • E2k7 includes multiple improvements in the anti-spam area that might make 3rd party solution less of a requirement for some organizations.
    • Customers using Enterprise CALs also get Microsoft Forefront for Exchange for free. Forefront provides scanning using multiple 3rd party signatures for spam, virus, and phishing protection.
  • The MANY new and improved features in Exchange 2007
    • Server roles
    • Calendaring and resource mailboxes
    • Unified messaging
    • Outlook Web Access changes
    • Searching
    • Manage Folders and message classification
    • Others...

In Part 2 I will continue to go over areas that need to be looked at for testing, included clustering, scalability, server roles, transport rules, calendaring, and more

Testing Exchange 2007 - Part 1

Page 1 | Page 2

Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Stephen Bryant or Pro Exchange. OutlookExchange.Com, Stephen Bryant and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Copyright Stephen Bryant 2008