Tag Archives: de-emphasized features

Migration: Exchange Public folders and its future


Public Folders are used in earlier versions of Microsoft Exchange Server to store free/busy data and files. From Microsoft Exchange Server 2007, free/busy data is no longer stored in public folders. It’s recommend that you do not store files in public folders in Exchange 2007. Instead, consider using Microsoft Office SharePoint, or Windows SharePoint Services. Public folders are included and supported in Exchange 2007 and 2010. However, future releases of Microsoft Exchange might not include public folders. You can visit http://blogs.technet.com/b/exchange/archive/2006/02/20/419994.aspx. Also, you can refer MS Exchange team blog have posted the updated public folder guidance for versions of Exchange past Exchange 2007.

So, what are my options?

If you’re building something new, you should look at the requirements and building on the SharePoint Technologies platform:

+ Starting with Exchange 2007, we recommend that applications use the Availability service to provide free/busy data for Exchange mailbox users. Windows SharePoint Services replaces the file sharing functionality that public folders provide. You must redesign applications that use public folders to use Exchange Web Services.
+ Also consider redesigning custom applications as early as possible as future versions of Microsoft Exchange may not contain public folders.
+ In addition to that you can refer the wonderful blogpost by Joel.

Part 1 : Developer Roadmap – Development Technologies for Exchange Server 2010


This two part article is targeted for the developer audience, if you’re the developer who want to create a develop custom application for Exchange Server 2010 or already has custom application designed for previous versions of Exchange Server 2010.

Some Exchange programming technologies that are available in versions of Exchange earlier than Microsoft Exchange Server 2010 are obsolete and have been replaced with other technologies. Per MSDN article, the programming technologies and APIs stated below have either been removed from Exchange 2010 or earlier versions of Exchange, are no longer supported for use with the current version of Exchange, or are no longer the recommended API to use to access Exchange.

Recommendation: We recommend that you use Exchange PowerShell commands to administer Exchange configuration data.

Recommendation: We recommend that you migrate your applications that use CDOEX to Exchange Web Services.

Recommendation: We recommend that you migrate your applications that use CDOEXM to use Exchange PowerShell commands.

Recommendation: We recommend that you migrate your applications that use CDOWF to use Windows Workflow Foundation Services.

Recommendation: Notification-based applications that work with Exchange 2010 should use transport agents.

Recommendation: We recommend that you migrate any CDO 1.2.1 applications to use Exchange Web Services.

Recommendation: To ensure continued future compatibility, we recommend that you consider migrating your ICS applications to use Exchange Web Services notifications.

Recommendation: We recommend that you migrate applications that use ExOLEDB to use Exchange Web Services.

  • Exchange Rules DLL is part of the sample code that shipped with the Exchange 5.5 and Exchange 2000 SDKs.

Recommendation: We recommend that you migrate applications that use the Exchange Rules DLL to use either MAPI or Exchange Web Services notifications.

Recommendation: Where possible, we recommend that applications that use Exchange Store Event sinks be migrated to use either transport agents or Exchange Web Services notifications.

Recommendation: We recommend that you migrate backup and restore applications that use streaming backup to use the Windows Volume Shadow Copy Service (VSS).

Recommendation: We recommend that you migrate applications that use Exchange WebDAV to use the Exchange Web Services.

Recommendation: We recommend that you migrate applications that use Exchange WebDAV notifications to use Exchange Web Services notifications.

Recommendation: We recommend that you migrate applications that use Exchange Web Forms to use either Windows SharePoint Services, or Active Server Pages.

Recommendation: We recommend that you use Exchange PowerShell commands to administer Exchange configuration data.

Recommendation: We recommend that you migrate applications that used WMI to use the Exchange PowerShell commands.

Happy Programming!!

Developer : Does Exchange Client Extension (ECE) deprecation matters me?


Per Randy’s blog post, Exchange Client Extension (ECEs) deprecation does (for Outlook 2010) matters the developers. For more information please refer the excerpts of the blog post:

“For most Outlook users, this announcement will not concern you. However, if you are a developer that uses Exchange Client Extension interfaces to build a solution in Outlook, then this deprecation is significant because you will have to redesign your solution for Microsoft Outlook 2010.

Exchange Client Extensions (ECEs) represent an extensibility feature introduced with the Microsoft Exchange client in 1995. The Exchange client was a 16-bit mail application running against the earliest versions of Exchange Server. ECEs must be written in native code, typically using C++ and relying heavily on the Messaging API (MAPI). When Outlook replaced the Exchange client, ECEs were used to extend Outlook 97-98 until COM Add-ins replaced ECEs in Outlook 2000 as the primary extensibility technology for Outlook.

ECEs will continue to operate as expected in Outlook 2007 and earlier. However, ECEs will not load in 32-bit and 64-bit versions of Outlook 2010. Outlook 2010 has converted its own ECEs such as Delegate Access, Deleted Items Recovery, Exchange Extensions commands, and Exchange Extensions property pages to native Outlook code.

To redesign your solution, you should consider the following options:

  • Rewrite your ECE as a COM Add-in using native or managed code. Unlike ECEs, an add-in represents a strategic extensibility technology that is fully supported in Outlook 2010. Using an Outlook add-in, you can build Outlook form regions and extend the Office Fluent User Interface. For additional information, please visit the Outlook Developer Portal on MSDN.
  • Rewrite your ECE as a Windows service application using native code and MAPI. If you are writing a Windows service application, you must use MAPI to access Outlook items rather than the Outlook object model. ”

Update : Technologies not available with Exchange 2010 & their migration reference(s)


Some development technologies that shipped/available in earlier versions of Exchange Server are not included in Exchange 2010.

The following technologies were removed from Exchange 2007:

  • Exchange providers for Windows Management Instrumentation (WMI)
  • Collaboration Data Objects for Exchange Management (CDOEXM)
  • Collaboration Data Objects for Exchange Workflow (CDOWF)
  • Exchange Web Forms
  • At Functions
  • DAPI.DLL

The following technologies were removed from Exchange 2010:

  • Exchange OLE DB Provider (ExOLEDB)
  • Exchange store Event Sinks
  • World Wide Web Distributed Authoring and Versioning (WebDAV)
  • CDO 3.0 (CDOEx)
  • Item-level permissions
  • Exchange Store custom item types

These technologies are not documented in the Exchange 2010 Web Services SDK. Any references to these technologies in the documentation are in error.

For migration information, you can refer the Guide to Exchange Server 2010 Development Technologies.

CDONTS, CDOSYS, System.Web.Mail & System.Net.Mail


Microsoft Windows Server 2003 does not install Collaboration Data Objects (CDO) for NTS (CDONTS). Therefore, applications that use CDONTS do not function on a Windows Server 2003-based computer.

Windows Server 2003 provides improved alternatives to CDONTS. To make applications that use CDONTS function on a Windows Server 2003-based computer, update existing CDONTS applications to use one of the following technologies:

  • CDO for Windows 2000
    CDO for Windows 2000 provides a broader functionality set than CDONTS. This functionality includes the ability to send messages through a remote Simple Mail Transfer Protocol (SMTP) server. You can use CDO for Windows 2000 (CDOSYS) in applications that are not Microsoft .NET Framework-based.

    For example, Microsoft Visual Basic 6.0 and Microsoft ASP are not based in the .NET Framework. You can also use CDOSYS in .NET Framework applications.
  • System.Web.Mail
    The System.Web.Mail namespace provides a managed wrapper for CDOSYS. The System.Web.Mail namespace is only available in .NET Framework applications.
  • System.Net.Mail
    When we talk about .Net framework, we can use the System.Net.Mail namespace. It provides way to send electronic mail to a Simple Mail Transfer Protocol (SMTP) server for delivery.

FYI: System.Net.Mail Vs System.Web.Mail

In .NET 1.1, only the System.Web.Mail was available. This implementation needs to be done in quite different way. For example, attachment could only be added from files, not from Streams. So, this can be still used under .Net Framework 1.0 and 1.1, but going forward it’s “deprecated” or “Obsolete”; so it’s recommended that to make use of System.Net.Mail.

The .NET 2.0 implementation is System.Net.Mail and is much more flexible and has a richer feature set.

Migrating CDOEXM based custom applications


As you know Collaboration Data Objects for Exchange Management or CDOEXM is used to create applications that manage Exchange servers, databases, public folders, and user mailboxes. It provides the fundamental Component Object Model (COM) classes and interfaces that are used to manage the Exchange store.

From Exchange 2007 onwards…

From Exchange Server 2007 onwards you can’t use the CDOEXM functionalities, because Exchange Server 2007 doesn’t include CDOEXM i.e., CDOEXM does not ship in and is not supported by Microsoft Exchange Server 2007. CDOEXM that runs on Exchange 2000 Server or Exchange Server 2003 computers cannot be used to manage computers that are running Exchange 2007.

So what will happen to my existing application which uses CDOEXM…any replacement in Exchange Server 2007?

Well, in Exchange Server 2007 onwards you can use Microsoft Exchange Management Shell (EMS) commands that work with Exchange replace CDOEXM in Exchange 2007. It is easy to migrate applications that use CDOEXM to Windows PowerShell commands. The Windows PowerShell commands that control Exchange 2007 servers, storage groups, databases, and users are simpler to use than the corresponding CDOEXM APIs; but it won’t be a straight forward migration though…

You will have to redesign applications that were created by using CDOEXM to use Exchange Management Shell. Consider redesigning custom applications as early as possible, as starting from Exchange 2007 and its future versions of Microsoft Exchange not contain the CDOEXM API.

Troubleshooting: Exchange environment with Event viewer


There are quite number of tools available to find the issues with Exchange Server environment. Here we’re going to view about “Event Viewer”. Interestingly Event viewer is it’s not directly meant nor designed for Exchange server, its designed for Windows OS environment.

So what can we get in the Event viewer?

Using the event logs in Event Viewer, we can gather information about hardware, software, and system problems, and you can monitor Windows operating system security events. In Event Viewer, both the application log and the system log contain errors, warnings, and informational events that are related to the operation of Exchange Server, the SMTP service, and other applications.

What else we can get?

You can use Event Viewer to obtain information about service failures, replication errors in the Active Directory directory service, and warnings about system resources such as virtual memory and disk space. Use Event Viewer to view and manage event logs; obtain information about hardware, software, and system problems that must be resolved; and identify trends that require future action.

Event Viewer maintains logs about application, security, and system events on your computer. Both Microsoft Exchange Server and Microsoft Windows report warnings and error conditions to the event logs. Therefore, make sure that you review event logs daily.

How to identify the issues in Event Viewer?

To identify the cause of message flow issues, carefully review the data that is contained in the application log and system log. Use the following procedure to view errors, warnings, and informational events in the application log.

Types of Logs Found in Event Viewer

Microsoft Windows Server 2003, Windows XP, Windows 2000 Server, and Windows NT record events in three kinds of logs:

  • Application log   The Application log contains events logged by applications or programs. For example, a database program might record a file error in the Application log. The program developer decides which events to record.
  • System log   The System log contains events logged by the Windows operating system components. For example, the failure of a driver or other system component to load during startup is recorded in the System log. The event types logged by system components are predetermined by the Windows operating system.
  • Security log   The Security log can record security events such as valid and invalid logon attempts as well as events related to resource use, such as creating, opening, or deleting files. An administrator can specify what events are recorded in the Security log. For example, if you have enabled logon auditing, attempts to log on to the system are recorded in the Security log.

Servers running Windows Server 2003 and Windows 2000 Server that are domain controllers might have the following additional logs in Event Viewer:

  • Directory Service log   Windows Server 2003 and Windows 2000 Server directory service logs events in the Directory Service log. This includes any information regarding the Active Directory® directory service and Active Directory database maintenance.
  • File Replication Service log   File Replication Service (FRS) logs its events in this log. This service is used for replication of files, such as domain policies, between domain controllers.
  • DNS Server service log   This log includes events related to the Domain Name System (DNS) Server service running on Windows Server 2003 and Windows 2000 Server. This will show only on DNS servers running Windows Server 2003 and Windows 2000 Server.

Types of Events Logged

The icon on the left side of the Event Viewer screen describes the classification of the event by the Windows operating system. Event Viewer displays these types of events:

  • Error   A significant problem, such as loss of data or loss of functionality. For example, if a service fails to load during startup, an error will be logged.
  • Warning   An event that is not necessarily significant, but may indicate a possible future problem. For example, when disk space is low, a warning will be logged.
  • Information   An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, an information event will be logged.
  • Success Audit   An audited security access attempt that succeeds. For example, a user’s successful attempt to log on to the system will be logged as a Success Audit event.
  • Failure Audit   An audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt will be logged as a Failure Audit event.

What are the main event components of the Event viewer?

The main event components are as follows:

  • Source   The software that logged the event, which can be either an application name, such as Microsoft SQL Server™, or a component of the system or of a large application, such as MSExchangeIS, which is the Microsoft Exchange Information Store service.
  • Category   A classification of the event by the event source. For example, the security categories include Logon and Logoff, Policy Change, Privilege Use, System Event, Object Access, Detailed Tracking, and Account Management.
  • Event ID   A unique number for each source to identify the event.
  • User   The user name for the user who was logged on and working when the event occurred. N/A indicates that the entry did not specify a user.
  • Computer   The computer name for the computer where the event occurred.
  • Description   This field provides the actual text of the event, or how the application that logged the event explains what has happened.
  • Data   Displays binary data generated by the event in hexadecimal (bytes) or DWORDS (words) format. Not all events generate binary data. Programmers and support professionals familiar with source application can interpret this information.

Couple of samples available in the event viewer (exchange specific):

How to view the application log in the event viewer?

  1. Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.

  2. In the console tree, click Application Log.

  3. To sort the log alphabetically and quickly locate an entry for an Exchange service, in the details pane, click Source.

  4. Double-click a log entry to open an event’s properties page.

  5. To filter the log to list entries for a specific type of Exchange-related event, from the View menu, click Filter.

  6. In Application Log Properties, use the Event source list to select an Exchange-related event source. For example:

    • MSExchangeTransport   Events that are recorded when SMTP is used to route messages.
    • IMAP4Svc   Events that are related to the service that allows users to access mailboxes and public folders through IMAP4.
    • MSExchangeAL   Events that are related to the service that addresses e-mail messages through address lists.
    • MSExchangeIS   Events that are related to the service that allows access to the Exchange Information Store service.
    • MSExchangeMTA   Events that are related to the service that allows X.400 connectors to use the message transfer agent (MTA).
    • MSExchangeMU   Events that are related to the metabase update service, a component that reads information from Active Directory and transposes it to the local IIS metabase.
    • MSExchangeSA   Events that are recorded when Exchange uses Active Directory to store and share directory information.
    • MSExchangeSRS   Events that are recorded when Site Replication Service (SRS) is used to replicate computers running Exchange 2003 with computers running Exchange 5.5.
    • POP3Svc   Events that are recorded whenever Post Office Protocol version 3 (POP3) is used to access e-mail.
  7. In the Category list, select a specific set of events or, to view all events for that event source, leave the default setting at All.

  8. Click OK.

How to view the System log in event viewer?

Use the following procedure to view errors, warnings, and informational events in the system log for SMTP service.

  1. Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.

  2. In the console tree, click System Log.

  3. To sort the log alphabetically and quickly locate an entry for an Exchange service, in the details pane, click Source.

  4. Double-click a log entry to open an event’s properties page.

  5. To filter the log to list entries for a specific type of SMTP service events, from the View menu, click Filter.

  6. In System Log Properties, in the Event source list, select SMTPSVC.

  7. In the Category list, select a specific set of events or, to view all events for the SMTP service, leave the default setting at All.

  8. Click OK.

Troubleshooting with Event viewer and Exchange Server:

Within each Event Viewer log, Exchange Server records informational, warning, and error events. Monitor these logs closely to track the types of transactions being conducted on your Exchange servers. You should periodically archive the logs or use automatic rollover to avoid running out of space. Because log files can occupy a finite amount of space, increase the log size (for example, to 50 MB) and set it to overwrite, so that Exchange Server can continue to write new events.

You can also automate event log administration by using tools and technologies such as the following:

  • Event Comb   The Event Comb tool lets you gathers specific events from the event logs of several computers to one central location. It also lets you report on only the event IDs or event sources you specify. For more information about Event Comb, see the Account Lockout and Management Tools Web site.
  • Eventtriggers   You can also use command-line tools to create and query event logs and associate programs with particular logged events. By using Eventtriggers.exe, you can create event triggers that will run programs when specific events occur. For more information about Eventtriggers, see the Windows Server 2003 topic New command-line tools and the Windows XP topic Managing event logs from the Command Line.
  • Microsoft Operations Manager   You can use Microsoft Operations Manager (MOM) to monitor the health and use of Exchange servers. Exchange 2007 Management Pack extends Microsoft Operations Manager by providing specialized monitoring for servers that are running Exchange 2007. This management pack includes a definition of health for an Exchange 2007 server and will raise an alert message to the administrator if it detects a state that requires intervention. For more information about Exchange 2007 Management Pack, see the Microsoft Operations Manager Web site.

Reference MSDN articles:

http://technet.microsoft.com/en-us/library/aa996117(EXCHG.65).aspx
http://technet.microsoft.com/en-us/library/aa996634(EXCHG.65).aspx
http://technet.microsoft.com/en-us/library/aa996105(EXCHG.65).aspx
http://technet.microsoft.com/en-us/library/bb232137(EXCHG.80).aspx

Public folder support for Exchange Server 2007 till 2016 ?


I went through the following Technet article which talks about one such a interesting question of my favortie “What is happening with public folders ?”


Please find the excerpts “…Exchange 2007 de-emphasizes public folders. Public folders may not be included in future releases, but support for public folders will be maintained through at least 2016. Current Microsoft Exchange customers should plan to migrate to Outlook 2007 and Exchange 2007. We recommend that you investigate integrating Microsoft Windows SharePoint Services with Exchange Server 2007 if you must have an application that supports sharing documents, calendar items, contacts, and tasks and archiving distribution lists. For other customized applications that are being developed, you should use Microsoft .NET ..”


For more information, you can have a look at this Technet article.

Discontinued Features and De-Emphasized Functionality – Exchange Server 2007


Discontinued Features and De-emphasized functionality – Exchange Server 2007 



  • Do you know what’re discontinued Features and De-Emphasized Functionality in Exchange Server 2007 ?. Then this article will be for you.

  • This article give details about the components, features, or functionality that has been removed, discontinued, or replaced in Microsoft Exchange Server 2007.

  • Please find this article

Note: Some of the features and components that are listed as discontinued or de-emphasized in this topic were added to Exchange Server 2007 in Service Pack 1 (SP1). Please find this article.