This is what MS seems to be telling its ISV partners these days, because it is exactly what is happening. But before getting into details let me tell you where I come from.

In 1996, as a fresh graduate, I joined GFI Fax & Voice (today GFI Software). In a matter of a few months I was assigned the Fax server connector for Exchange v4. Since then I never stopped programming MS Exchange add-ons.

I remember recoding the fax connector for Exchange 2000. Oh my! Microsoft had just released Active Directory and many things had to be recoded. Next I programmed the integration of a mail security solution. Then I started WinDeveloper Software where I developed more Exchange add-ons; WinDeveloper IMF Tune and WinDeveloper Message Recall. Ahh and of course I started ExchangeInbox and was an Exchange MVP for a few years too!

Why am I saying all this? It's another way to say that I have been programming for Exchange for almost 17 years. I followed closely the many integration opportunities Exchange has provided since Exchange was born.

Microsoft Exchange 2013 Transport Agents

Now that you know me better let's go back to Exchange 2013.

Over the years Exchange always offered many integration opportunities for ISVs. Partners might have not always been happy with the way Microsoft competed with them, but many will agree that from the programming side we always had great APIs to work with.

As in earlier versions the Exchange 2013 transport agent interface is one of the most powerful. Microsoft itself uses this to plug its own anti-malware and anti-spam functionality. There is just one problem. Microsoft is breaking this interface with every Cumulative Update release and they are promising a new CU quarterly.

So far we had three Exchange 2013 builds released; RTM, CU1 and CU2. This resulted in three incompatible transport agent interfaces. So ISVs have to distribute an update for every CU release.

Of course the MS agents don't break. The CU is a complete build. It includes the "new" transport agent interface and their updated agents in one package.

The absurd side of this story is that these CUs aren't delivering any real interface changes. There is no new functionality that would justify breaking an interface. Even if new functionality had to be introduced, there are ways of doing that without breaking the old interface.

Anyone having a basic programming understanding knows that interfaces are sacred. You don't just break them unless you really have to. But all of a sudden someone in Redmond got nostalgic of DLL hell apparently! Anyone remembers how .NET was the solution that would bring about the end of DLL hell?

Having been an Exchange guy for so many years I am sorry to have to write this article. But since Microsoft plans to release a CU quarterly someone had to do this. Just think what will happen when Exchange 2013 SP1 is out, and then CU1 for Exchange 2013 SP1!

Of course ISVs can code their add-ons to hide some of this mess, but Microsoft’s attitude is still questionable. MS has been aware of this problem for a long time. A similar problem existed in Exchange 2010. The problem gets much worse and they don’t even bother documenting it.

Is this another way to tell us to stop supporting on premise Exchange installations maybe?