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:
- It’s not documented or wasn’t designed to be used that way. We document everything we intend to support. If there is no documentation to perform a certain task, or use a certain API, we don’t intend for you to use it, and therefore, we don’t support it. If it isn’t documented, how will you know how to use it? You probably don’t, and that’s probably why you’re having a problem.
- We didn’t test it. Either it was a scenario so rare that we never thought of it or we didn’t expect anyone to actually be in the scenario you’re in, it didn’t get tested. If we don’t test it, then we don’t know whether or not it works. It may work, it may not, but in either case, we aren’t going to support it because it wasn’t tested.
- It’s too problematic. A perfect example of this is doing complex calendaring with WebDAV. It’s not to say that it has never been done, or that it can’t be done. The reason we don’t support it is that it is so complicated and complex that it becomes far too easy to mess up. Another example of this is modifying security descriptors with WebDAV. A security descriptor is a very sensitive xml document that must be formatted exactly right in the exact order or you can cause irreversible problems in your Exchange environment. It’s too problematic, so we don’t support customers doing it.
- It has known problems. A perfect example of this one is using MAPI in process with managed code. MAPI manages its own memory, and so does .net. You get unpredictable behavior when you use them in process with one another because they can corrupt each other’s heaps. We KNOW this is a problem, so we don’t support it.
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.”