Why SkipRearm matters, even if you'll never touch it

Everyone in corporate IT management needs to read Brian Livingston's Windows Secrets article on how Windows Vista can be used for a year without being activated.

Everyone. With. Out. Exception.

Think it's not for you? Then skip over the technical stuff and down to the headline "Why does SkipRearm even exist in Vista?" That's where Livingston explains that this isn't a bug, it's a feature. And he means it. "The Vista development team apparently inserted the SkipRearm loophole to help major corporations work around Microsoft's new Volume Licensing Agreement," he writes, and he points to publicly available Microsoft documentation that spells it out.

Later, Livingston sums up the howcomeizzit: "Microsoft executives made Vista's activation overly complex and cumbersome. So the development team apparently invented a Registry key to lift the burden of Vista's activation deadline, for at least a year and probably more."

Still think this isn't for you? Forget about Microsoft for a moment -- this is about how IT is done. And it applies to just about all of us.

Look, when smart techies see users having a problem with technology, they look for a way to fix it. And that's good. That's what we want. That's IT serving the needs of the people who make the business run. That's what we preach.

Sometimes the problem is in an application. Sometimes it's in an operating procedure. Sometimes it's in the way permissions are set up. Almost always, the fix or workaround or backdoor is ginned up to help people do their jobs.

But what happens when the fix breaks a rule or violates a policy?

Maybe that rule or policy has to do with security. Or regulatory requirements. Or corporate strategy. Or something else that's outside the immediate scope of the fixer's work. The results of the fix could be a lot more significant than the fixer or user expect.

And if your support people have a reputation for being helpful and effective, there's a good chance they're doing rule-breaking fixes, at least now and then.

The solution? Cracking down isn't the answer; it'll just irritate both the techs and the users. Ignoring the problem is even worse -- eventually, some rule-breaking fix will turn out to be a major problem.

One first step is to make sure that every time a rule is bent, it's logged as a bent rule. And then make sure someone follows up on what was done.

That way, if there's a better way to solve a user's problem without violating policy, it can be found. If the policy should be changed because it's widely ignored as it stands, that can go on the table for consideration. If the user has to get the bad news that the fix just simply has to be undone, the news can be delivered by someone in authority -- not the lowly tech who's just trying to help everyone do their jobs.

Just don't imagine it's something you don't have to worry about. For Microsoft, a software design that violates a corporate goal exposes the vendor to embarrassment.

For corporate IT, rules getting bent could mean exposure to problems with security, Sarbanes-Oxley regulations or privacy laws.

And if it's happening even within Microsoft's much-vaunted new development process, it is happening in your shop.