How Your Political Issues Are Killing Your IT

Here's a true story: I was once teaching a VBScript class (this was, obviously, years ago) when a student asked if there was a way to write a script that would enforce the membership of computers' local Administrators group. I smiled, knowing that I was about to make this person very happy. "You don't have to write a script," I said. "You can just use the Restricted Groups settings in a Group Policy object." The person shook their head. "We can't. Our Active Directory administrator doesn't like Group Policy, so we can't use it."

I was floored. I literally did not know what to say. I'm pretty sure I stood there with my mouth hanging open for a full minute, shook my head vigorously, and went on teaching as if nothing had happened. What else could I have done?

In the years since, I've run across a metric butt-tonne of similar situations, where folks couldn't do the right thing due to some political reason -- often a misinformed political reason. The most recent: "We can't use PowerShell remoting to remotely administer computers because our security policy won't let us open the necessary port." At the same time, these folks are allowed to use Remote Desktop, which imposes a massively greater performance burden on their servers. They are allowed to use technologies like Windows Management Instrumentation, which uses a much wider range of TCP ports and is somewhat less controllable than PowerShell Remoting. In other words, Remoting is verboten simply because it's new, and the organization's security officer or policymakers won't take the time to understand it.

Folks, this is ridiculous. If you're an IT decision maker in your environment, your main job should be to fight this kind of -- well, let's just call it BS, because that's what it is. This attitude is like saying, "we bought this new car, but we can't use it because we don't really like the idea of gasoline."

Products are built the way they are for a reason. Over time, those reasons will change and evolve, and the products will change and evolve to suit. You can't "just decide" to not use a product the way it was intended because you don't find that way aesthetically pleasing, or because you "don't like it," or because you haven't taken the time to understand it. I can accept, "we're not using it yet, because it's under review." In fact, that statement shows a level of maturity I applaud. You know a feature exists, you're not familiar with it yet, but you're taking the time to become familiar.

From now on, when people ask me how to do something, I'm going to tell them the right way (or ways, if there are choices). But I find myself increasingly unwilling to engage in elaborate hacks and manual workarounds just to accommodate ill-advised, uninformed policies. Use the products the way they're meant to be used, or stop using them and buy something that works the way you want.

Now, that's distinct from instances where there's a compelling, business-related reason. For example, if you told me, "we can't use Group Policy because we're in a highly distributed environment, and our tests show that replicating GPOs puts too great a strain on our WAN bandwidth," then fine. That's a legitimate reason and we can start looking for a workaround. That's a bad example, of course, because GPOs don't do any such thing...but you get my point. A well-informed, business reason to not use a product in a specific way is just fine.

What about you? What goofy policies do you have to deal with that just don't make any technical sense -- or even any common sense? Let me know in the comment section below.

Posted by Don Jones on 05/02/2011 at 1:14 PM