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."
Are your DST woes over?
Are you sure?
Many of the problems that several of our customers experienced due to the change in daylight savings dates this past spring could have been either prevented or worked around easily if some testing had been done earlier. Admittedly, even some of our products at Microsoft had some issues we didn't catch in our testing, such as the SentOn date in CDOSys. During the weeks leading up to the new start of DST, our support-call volume increased by several orders of magnitude. It seems everyone was feeling the pain and needed our help to iron out their problems. Many of the cases we worked during those weeks could have been worked in December or January after we released our patches for Windows and could have avoided the "CRITSIT" status many of them took on.
Several customers decided a change to their code was necessary to accommodate a flexible DST time. Some customers decided that they just needed to run a batch job to fix some data. Some decided both were necessary. Still some others were simply waiting on tools or updates from Microsoft on our APIs on which their application depended. Surprisingly, the first week of DST settled down a bit. The next few weeks after that revealed only some straggling one-off issues related to DST. Now, 2 months later and almost 2 months since the previous DST start date has past, it would seem our DST days are behind us…but I fear they are not.
There is another "window" coming up in November. Remember that DST was extended into March AND into November. If your application relies on dates or time calculations, you should be testing your application now for the November DST window. Make sure the changes you made still work. We don't want to go through that again, and I'm confident you don't either. No one could have predicted Congress would spend their time changing DST dates instead of working on problems of our day, but they did give us plenty of warning (almost 2 years). We all need to do our due-diligence and ensure that November doesn't become the new March.
Matt Stehle had a great post on building foreign connectors, the gateway connectors replacement for Exchange 2007.
Check it out.