One of the more frequent frustrations we have as Support Professionals is delivering the message that what a customer is doing is "unsupported." The reason this is frustrating is that there is not a good definition out there anywhere which explains what is meant when a Microsoft Support Professional says that something is "unsupported." I think when many customers hear us say that, they hear "copout." I can assure you, that this is not the case. Microsoft technicians are some of the most passionate people in the world about technology. When a customer phones in for support and describes their problems, we are just as interested as you to discover what is causing the problem. We love figuring out issues, debugging, troubleshooting issues, etc. Believe me, we're not being lazy.
There are several reasons Microsoft can decide something is going to be not supported:
I'm sure there are other reasons we don't support something, but these are probably the most common.
So what does "unsupported" mean? I've already discussed why something is unsupported, but what does being unsupported mean from a consequence point-of-view? It means that we should not and cannot assist our customers in resolving their issues until we can get into a supportable configuration. If you are using MAPI in .NET, then you have to either not use MAPI (if you insist on .NET) or switch to unmanaged C++ (if you insist on MAPI). If we can find a way to reproduce your problem in a supportable configuration, we can continue investigating and proceed with filing a bug if necessary.
If you are in an unsupported configuration, we can't really know if we are solving your problem or not, because the state of your application or environment is in an unknown state. Consider this analogy - It's raining outside and your head is getting wet even though you have an umbrella. You are walking with the umbrella pointed straight out instead of holding it over your head. You call the umbrella manufacturer and complain that your head is getting wet. Later, the manufacturer discovers that you haven't been using the umbrella correctly and says that you need to hold the umbrella upright if it is to work as designed. At this point, there is no reason for the manufacturer to start an investigation into the umbrella and hunt down the fabric manufacturer and combing through the architecture of the umbrella. Let's say you decide to comply and you hold the umbrella upright; however, your head is still getting wet. After some troubleshooting, it is determined there's a hole in the umbrella, and the manufacturer then is able to repair the hole and your problem is resolved. Even if the umbrella manufacturer had discovered the hole without you holding the umbrella upright, it would have been pointless to fix it since using the umbrella incorrectly also causes your head to get wet. There's no way to know whether the suggested fix resolves your issue or not if you are in an unsupported configuration. I know that was an overly complicated analogy, but it illustrates why being in a supported configuration is so important.
One of the biggest problems with having an unsupported configuration is that we have no way to escalate your issue or get a bug/hotfix filed to get your problem resolved if you are doing something that's unsupported. Our development teams will just say "no." So since there is no way to fix your issue when you're unsupported, we just try to help you get back to a supportable configuration before proceeding with your problem.
I hope this helps some of you understand the concept of "unsupported" and why it is important to be "supported."
Pcreehan had a great blog post recently on what the phrase "its not supported" really means. http://blogs.msdn.com/pcreehan/archive/2007/05/04/what-does-unsupported-mean.asp
The issue of using MAPI or (most commonly) CDO 1.21 in managed (.NET) code is one that comes back to