Every now and then the question comes back in the limelight: “Why some hotfixes are publicly available to download, but most of the times I have to call CSS to get one?” and “Wouldn’t be easier if we could just download the fix ourselves? At least we would save time, since we’ll get it anyway from CSS” and again “Who decides if a fix has to be public or private? How?” etc…, feel free to add more if you have (and I’m sure some of you do! 😉).
I discussed this topic internally with my colleagues (both Support Engineers and Escalation Engineers) in CSS EMEA and of course there are some different views on it, but there is also a common understanding about some of the principles behind the policy Microsoft adopted. Those “private” fixes do not undergo the same amount of tests that Service Packs or “public” fixes have to pass, and this is the main reason (basically: costs); one of the parameters the Product Team(s) takes into account when producing a fix is the business impact that issue is having (or potentially will have) on customer’s applications, but also the risk of introducing regression bugs, the amount of code to change, severity of the problem etc…, and then someone in the management chain has to decide which kind of fix to produce. Basically the process outlined here for Sql fixes, also applies for DevTools products (and for any other products in Microsoft, I guess).
The logic behind the policy we nowadays have, is that a customer can make a research and find the KB article which points to a specific fix and call CSS to get it; nevertheless sometime is hard to understand why the KB article is publicly available, but the hotfix is not. A solution to this would be to keep also those articles private, so that we at CSS can find the fix anyway, but this should clear the situation on customer’s perspective: public articles refers only to public fixes, available for download.
Correct? Well, sort of… 🤔
Because sometimes (also in my experience) the requested fix does not fits customer’s needs, either because it refers to a different product (previous version), or because the customer already has it maybe installed with a Service Pack or with a Roll-up package: what if a customer finds an article which describes a symptom he’s getting, but due to a different cause? Of course that fix will not work for him, and he’ll have to call CSS anyway…
Keeping some hotfixes private is necessary for three reasons:
- Not all fixes have been extensively tested
- We would end up having customer who, by default, would install every fix we release even if they don’t need it, and this is not good (see the previous point, and imagine all the implications)
- We need to know which customers have installed a private fix: as per point 1, if we discover a problem in one of those fixes we are then able to find out who and when has installed it, and we can contact them to take appropriate actions if needed
In my experience, when we get an incorrect fix request from a customer we of course don’t send the file (which will be useless anyway), but try to help the customer with a reasonable commercial effort (as the policy tells 🤓), keeping in mind that this kind of Support Calls are free of charge; so if we can’t find a solution quickly, we’ll have to open a “standard” (either incident or payment) call to work on the problem.
Of course we could improve the technical accuracy of our fix articles in order to increase customer’s ability to correctly identify his problem and the relevant hotfix (if that’s the case, and if available); but sometimes the articles are technically correct, but could happen that the “human factor” generates errors and misunderstandings (and I’m not sure if this can be controlled…). Then those private fixes are already available for Premier customers through a restricted web site they can access; maybe would be possible to apply that kind of initiative to a larger portion of customers, but still we should be able to know who and when downloaded it (for the reason at point 3 above).
Nevertheless the pilot I blogged about a while ago is still progressing, so maybe something is moving in the direction of the feedbacks we got from you, after all…
Of course any comments on this is welcome! 😉
Carlo