Best Practices – What is supported and not.

The issue of supportability comes up a lot.  I would like cover it in this blog post. When we get cases from customers we look at the servers, software and APIs involved.  In addition, the development scenarios and configurations are taken into considerations.

A lot of customers run outdated versions of Exchange and Outlook - such as RTM Exchange even though they would need to be at SP3 to be supported... I guess they don't care about the many years of fixes and improvements which MS did for Exchange 2010 and would rather troubleshoot issues which might have had fixes released years ago. Some want to test with the oldest versions of things their code runs against but don't understand that they should also test with the latest bits if they run into an issue and end up fighting an issue which has already been fixed and end up opening a support case when patching to the latest updates (even ones years old) might have resolved the issue.

I sometimes even see customers doing things which they should not - such as using Extended MAPI under .NET, changing traffic to Exchange using an ISAPI component running in an Exchange worker process and have seen  some go much further and inject their code into Exchanges processes in order to alter its behavior.  When we run into issues such as these there is nothing we really can do other then explain that the code needs to be changed to use a supported API or method. In some cases products are built and deployed for many years without an issue... then it happens.... MS releases fixes or changes and their application breaks... so, they troubleshoot and open a support case for help.  The problem is that in many/most cases there is nothing we can really help with as they were relying on something which should never have built an application to use.  Some ISVs end up in a very bad place having built apps which they had been selling to find out that their code won't work any more and there is no way to get it to work since they had chosen to take a risk in writing code in a way which MS would not provide support. When I talk to customers who do this they knew they were taking a risk from the start.  

For customer's with a Premier software agreement we have a path to request functionality be added in so that customer software can be written against it and be supported - this is called a Design Change Request (DCR). With a DCR there is a shot on getting the interfaces or changes they want.  However, such things need to be filed early on since such changes usually take a lot of time since planning and  development for MS products can be a very long process. The bar for accepting a change request is usually pretty high. 

There are a lot of things which MS documents to an extreme. However, not everything is documented publically... yeah proprietary stuff. Well, most all software companies do. Some developers decide to take it upon themselves to reverse engineer code they don't own and then don't resist the temptation to hook into an app in a way it was never intended to, was never deigned to and never tested  for.  So, when their application has issues they get pretty excited though they had made the choice to go down that path themselves.

Lets define what unsupported means:

What Does "Unsupported" Mean?

Microsoft Support Lifecycle:

Microsoft Support Lifecycle Policy FAQ

Windows lifecycle fact sheet

Microsoft Support Lifecycle

Microsoft Support Lifecycle Database:

Microsoft Support Lifecycle - Exchange

Microsoft Support Lifecycle - Outlook 

Microsoft Support Lifecycle - Internet Explorer

Microsoft Support Lifecycle - .NET

Microsoft Support Lifecycle - Visual Studio

Support policies - software:

Support policy for Microsoft software that runs on non-Microsoft hardware virtualization software

Stay up-to-date with Internet Explorer

Support policies - Development:

Developer support limitations for public protocols

"Enhancing Exchange" via unsupported methods. 

OWA Single-sign-on support

Using ISAPI Extensions to change-out OWA Credential is not supported

Microsoft does not support using ISAPI extensions or filters to modify Outlook Web Access credentials on a server that is running Exchange Server

Microsoft support policy for the customization of Outlook Web Access for Exchange

Building VCALENDAR content without an Microsoft API is not supported by MS.

HOWTO: Read unmounted Exchange EDB files.

What's not supported with WebDAV?

Drag and Drop with Outlook

FYI: Why are MAPI and CDO 1.21 not supported in managed (.NET) code?

Save The Date - End of Exchange 2010, Windows 7 and 2008 Mainstream Support – T Minus 6 Months

Support Ending for the .NET Framework 4, 4.5 and 4.5.1

.NET Framework Versions and Dependencies

Please Note:

Microsoft Developer Support does not write or maintain customer production code.

Also see:

About: Messaging APIs 


Comments (0)

Skip to main content