We will fully support these features in Exchange 2007 through 2016. And we do not plan to support these features in Exchange “14”.

n  Public Folders

n  CDOEx

n  WebDAV

n  ExOLEDB

n  Store events

n  Streaming backup

 

         Public Folders – Long term, SharePoint is Microsoft’s strategic technology for team workspaces.

1) Public Folders will still exist in Exchange 2007, but it is recommended that customers evaluate SharePoint as an alternative technology in the future.

2) Migrate as much as possible to SharePoint. Although SharePoint does not support all the features offered by public folders today, it does provide other team workspace features that are very useful. It is Microsoft’s intention to significantly enhance SharePoint in the upcoming releases.

3) Customers and ISVs that have applications using Public Folders should start rewriting those applications on the new architecture.

         CDOEx (CDO 3.0)In order to provide a robust platform for the richer set of Exchange Web Services, we need to sunset our current APIs. Customers have been looking for a richer set of APIs to get access to their messaging data. They will get this in Exchange Web Services. Exchange is replacing this API with a richer set of Web services APIs that will work from different servers, rather than having to run them on the Exchange server. Additionally, Exchange Web Services will provide better Outlook interoperability than previous APIs.

1)     With Exchange 2007 continue using CDOEx with the expectation that customers will migrate.

2)     An alternative would be to use MAPI as the API

3)     Components or applications can be rewritten to use Web Services.

         WebDAVEasy to use, remote API access to messaging data will be provided in Exchange Web Services. Additionally, Exchange Web Services will provide better Outlook interoperability than previous APIs.

1)     With Exchange 2007 continue using DAV with the expectation that customers will migrate.

2)     An alternative would be to use MAPI and CDO 1.21.

3)     Components or applications can be rewritten to use Web Services.

         ExOLEDBCustomers have been looking for a richer, remote-able set of APIs to get access to their messaging data. They will get this in Exchange Web Services.

1)     With Exchange 2007 continue using ExOLEDB with the expectation that customers will migrate.

2)     An alternative would be to use MAPI as the API.

3)     Components or applications can be rewritten to use Web Services.

         Store Events – Store events are supported in Exchange 2007 but are not planned for subsequent releases. A combination of Hub Transport agents and Web Services will replace this API.

1)     Synchronous Store events should be replaced by Hub Transport agents, which now have full access to either the MAPI or MIME content of a message. Transport Agents are designed to be run on a Hub Transport or Edge Transport server role.

2)     Asynchronous Store events may be able to be replaced by Web Services applications, which have the benefit of being able to be run on a machine separate from the Exchange Server.

         Streaming backup – VSS (Volume Shadow Copy) backup, which was introduced in Exchange 2003, is the preferred method of backup across Microsoft applications and provides faster recovery solutions than the Streaming backup APIs.

1)     Streaming backup APIs will be supported in Exchange 2007, but customers and ISVs should move to VSS backups to take advantage of high availability solutions.

 

Features discontinued from Exchange 2007

n  OWA access to Public Folders

n  IMAP access to Public Folders

n  NNTP access to Public Folders

n  Outlook Mobile Access (WAP – Wireless Application Protocol)

n  OWA rule creation and editing

n  S/MIME support in OWA

n  Cut for Exchange 2007 RTM

n  Expected later in an Exchange 2007 Service Pack

n  Co-existence with E5.5

n  GroupWise connector and migration tools

n  Admin Groups

n  Routing Groups

n  Active-Active Clustering

n  X.400

n  Transport Event Sinks

n  CDO 1.2

n  CDO for Workflow

n  CDOExm

n  Exchange WMI classes

n  IFS (M:)

n  Event Service

n  Exchange Web Forms

n  Workflow Designer

 

OWA access to Public Folders – Public Folder access via OWA is available only for customers with an Exchange 2003 public folder server. Our stated strategy has been to move all shared information and documents to WSS and SharePoint.

1)     Migrate shared document access to WSS. WSS offers a web UI for shared calendars, tasks, etc.

2)     If OWA access to public folder content is important, keep a replica of all folders on Exchange 2003 servers. Or, use 2003 public folder servers in conjunction with the E"12" Client Access Server Role and provide a link from E"12" OWA to the OWA 2003 Public Folder UI.

3)     OWA and WSS will provide a web UI for document and file share access from the internet in the E"12" timeframe

IMAP access to Public Folders – Public folder access via IMAP was generally used for access to news groups. With NNTP cut, this access is no necessary. Outlook should meet public folder access requirements.

NNTP access to Public Folders – Little used by Exchange customers today and difficult to support going forward. Look at 3rd part solutions.

Outlook Mobile Access (WAP) – Due to the high latency of cellular networks and limitations of browsers, few people want access to their email via a small browser experience. Our focus is to license Exchange Server ActiveSync to many device manufacturers, so people can have the great sync experience from any device. Use Windows Mobile or other Exchange Server ActiveSync-based devices from palmONE, Motorola, Nokia or Symbian.

S/MIME support in OWA – S/MIME as a strict requirement is used by few customers, mostly in a governments setting and was pulled from Exchange 2007 RTM for OWA. Use Outlook to access those messages.

1)     If S/MIME is a strict requirement for your installation, continue using Exchange Server 2003 until such time as we provide additional guidance on S/MIME for OWA and Sync.

2)    It is anticipated that S/MIME will be available with a future Exchange 2007 Service Pack. The Exchange service packs tend to be about a year out.

Co-existence with E5.5 – Exchange 2007 will not support coexistence with Exchange 5.5, as the capabilities of Exchange 2007 are dependent on Active Directory. Customers remaining on Exchange 5.5 have been encouraged to move to Exchange 2003. Exchange 5.5 can exist in a separate organization with no direct interoperability with Exchange 2007.

GroupWise connector and migration tools – Exchange 2007 uses standards-based SMTP and MIIS supported directory services for coexistence and interoperability. GroupWise supports SMTP as well, making it unnecessary to continue delivering separate proprietary connectors.

Use SMTP and MIIS for coexistence with GroupWise since both systems use these standards and tools.

Admin Groups – Exchange 2007 new administration model will no longer require Admin Groups. The new ESM in Exchange 2007 allows dynamic server set views to be managed. Use server level delegation of administration rights in combination with existing organization-wide (forest) delegation.

Routing Groups – A new routing topology has been architected for Exchange 2007. This is a change in architecture, not a loss of functionality. Move from Exchange 2003 to Exchange 2007 incrementally. Exchange 2003 routing compatibility will be maintained.

Active-Active Clustering – This has proven to be very difficult to use and support. Few, if any, customers end up implementing it. Use or convert to Active-Passive

X.400 – The use of X.400 is diminishing rapidly. Microsoft will continue to support and enhance the prevailing email transport standards around SMTP. If possible, migrate to SMTP and an alternative directory. If X.400 continues to be important, deploy Exchange 2003 running X.400 in the same Exchange organization as Exchange 2007

Transport Event Sinks – In E"12", MEX will replace the Server Event Object (Transport Event Sink Hook). Applications should be rewritten to use the new transport rules with the Edge Transport and Hub Transport agents.

CDO 1.2 – This is being replaced with Web services APIs that will work from different servers, not just Exchange. E"12" will no longer ship CDO 1.21 on the E"12" media, but CDO 1.21 will be available as a web download with the expectation that customers will migrate. The CDO 1.21 shipped in the web download will be supported to work with E"12" servers. Components or applications can be rewritten to use Exchange Web Services.CDO for Workflow – Windows Workflow Services is the new workflow platform. Based on BizTalk, it has workflow tools, from basic workflows managed in FrontPage to complex workflows managed through the Visual Studio 2005 shell. Use Windows Workflow Services.

CDOExmThis is being replaced wih Cmdlets which are .NET classes that can be called via managed code or through MONAD scripts. Customers and ISVs should rewrite their applications on the new architecture (MONAD, cmdlets, etc).

IFS (M:) – We are eliminating the ability for users to access the Exchange data store through the seldom-used Win32 layer. By limiting the way that users can access the Exchange data store we will increase the stability and reliability of Exchange. Use Web Services or MAPI to access store.

Event Service – This was de-emphasized in 2000 and 2003 (off by default). Customers should have been re-writing to Store events if required in 2000 and 2003 deployments. Use Windows Workflow Services.

Exchange Web Forms – To improve OWA, Microsoft has updated the architecture in a way that can no longer support Web Forms. Re-implement applications as possible using the new OWA customization points in Exchange 2007. Use ASP.Net Web forms and Exchange 2007 Web Services API for custom applications.

Workflow Designer – This development tool provided the ability to build event sinks with Exchange. As part of Office XP for developers, the tool hasn’t been updating in 3 years. Use Windows Workflow Services.