This falls in line with a previous post about common sense in IT.
I was having lunch with a co-worker, whom I will call Marcus, to protect the guilty (he's not). Marcus in an IT director for a medical services provider. About two weeks ago the vendor of the application they use to store and keep up with their patient files provided a major update to the application. Since it's a cloud-based solution, Marcus didn't have the option of playing the "wait-and-see" game that we often play for software we install on our own systems. As a result, he suffered through a major update fraught with many issues combined with a vendor's clueless customer support.
When I hear something like that, my next question is, "How clueless?" This is a medical services provider so doing things like dropping your corporate firewall is not an option. It's crazy to even think about as a non-medical organization. However, as my friend Marcus' shop was dealing with the issues, that's exactly what was suggested by the vendor. Marcus just mentioned firewall but the way he said it made me think he meant more than the PC's personal firewall. So I asked. Yes, indeed, they wanted the corporate firewall down.
Marcus immediately said, "No." Actually, knowing Marcus, it may have been more colorful than that. In Marcus' view, that immediately failed the common sense test. The vendor was pressing his team to make this change and Marcus wouldn't budge. Something about not wanting to break the law and all.
The initial request didn't come to Marcus. It came to someone working for Marcus who was pretty new to IT. However, when the vendor said that, it didn't seem right. His common sense was telling him that this is something you ought not do. So he immediately called Marcus, his boss. Marcus confirmed to him that his instincts were correct. They wouldn't be dropping the firewall. Marcus then told him to escalate the issue to someone on the vendor's end who knew better.
Why do I point this out? When it comes to applying common sense in IT, sometimes you have a feeling that what you've been asked to do doesn't make sense. There's no shame in calling someone who should know. For instance, on Twitter there's no shame in using #sqlhelp if you don't have someone in your organization or list of professional contacts to go to. It's better to ask then get something major wrong because you were too proud to do so. That's what Marcus' employee did. Now Marcus' employee didn't have the rights to go bring down the firewall, so that wasn't going to happen. However, when he called Marcus he didn't say, "Hey, boss. We need to bring down the firewall." What he said was more like, "Boss, this vendor is recommending we bring down the firewall. That didn't sound right to me. What should I tell them?" Remember, Marcus' employee is a relative newbie to IT. He knew he didn't know for sure if that was a good solution. He knew it didn't feel right. He knew he didn't have enough experience to make the call. So he called Marcus.
How This Applies to SQL Server
I cannot tell you how many times I've had a vendor ask for something that was utterly ridiculous with respect to SQL Server. I can think of a case where a well-known security company demanded the install of their AV product use the sa login. It was hard-coded, after all. We fought that one. We lost, only because we needed to upgrade. However, we made a lot of noise, submitted tickets to get it fixed, etc., and was a general nuisance until it got the visibilty of the right people. That requirement was gone in the next version.
If you're dealing with another IT pro, whether part of your organization or outside of it, and that person is telling you to do something you know is madness, don't disconnect your common sense. Challenge it. Make sure it *has* to be that way. Sometimes you can't win. Sometimes you have to accept the inevitable. In those cases you document the issue, writing up the exception and putting together the information that shows you were left with no choice. That way you don't go down in flames. Make sure your manager is fully briefed so if it gets escalated, he or she isn't blindsided.
If you're not sure, phone a friend. Ask another co-worker who could or should know. If you don't have such a co-worker, reaching out to your professional network. Failing that, hit the forums or twitter (did I mention #sqlhelp) and provide the basic details without revealing too much sensitive info about your organization. Don't disconnect your common sense. Instead, channel it to make the best decision for you and your organization.