Companies beyond a certain size all follow the same basic pattern. Where possible, everything gets centralized in the global office- email, web servers, Active Directory, etc. They dictate policy and then leave it to the extremeties to solve their own problems within the corporate boundaries. Al worked at a factory, supporting their production management and chemicals management software- things that couldn’t be centralized.

Each day, when Al logged in, his computer greeted him with the standard warning message. “This computer is private property, and its use is subject to our IT policies (123.6, 216.2, and 551.A), and if you’re caught using it for porn or pirated software we will fire you so fast the unemployment line will be blueshifted.” Each time, he ignored it and clicked “OK”.

Al wasn’t the only one in the company that simply ignored the message. Back at the Great Glass Citadel, where the corporate heads dictated policy, the CFO also ignored it. The CFO also ignored common sense and good taste, and violated the IT policies and the sexual harrassment policies. This caused a panic, since a “C-level” executive couldn’t just be fired. After some careful discussions, the CFO had this excuse: “I didn’t understand that I was agreeing to the policy. ‘OK’ doesn’t give me any way to reject the policy, this is unfair and will lead to confusion.”

“Our CFO was a victim of poor IT policy,” the CTO said. “I play golf with him all the time, and I know he wouldn’t have done things like that if he understood the policy. So we need to change the ‘OK’ button to ‘Accept/Reject’.”

Corporate IT implemented this change. Their solution was a simple tool called LOGON.EXE.

When a user finished logging in, a domain login script ran. This script downloaded LOGON.EXE and all of its dependencies from a file share. It launched the application, which opened a full-screen window, disabled as many keyboard shortcuts as it could, and did its best from preventing the task manager from executing. It did nothing more than display the policy message and two buttons. If the user clicked “Accept”, the program quit. If the user clicked “Reject”, the program also quit- after sending a shutdown /r /t 0 to the command line, forcing the computer to reboot.

Corporate IT tested it on corporate machines. Satisfied, they enabled the login script across the entire domain at 6PM on Friday night. They left for congratulatory drinks to celebrate a job well done.

Then the second-shift at Al’s factory came on. By 6:15, Al was back at the factory, trying to figure out why most of their plant management software ceased working.

It was obvious to Al LOGON.EXE was the culprit. Several of the libraries it depended on were at fault; LOGON.EXE and all of its DLLs were deployed directly into SYSTEM32. Each time a user logged on, the DLLs were replaced. The plant management software depended on some of those DLLs- but expected a newer version than the versions corporate IT was deploying with each login.

Al called the service-desk, demanding the script be deactivated.

“No can do,” the analyst replied. “We don’t have permission to change domain policies.”

“Then call someone who does,” Al said.

There was a long pause while the analyst checked the list of people on call for Friday night. “No can do,” he said, “there’s nobody on the standby list that has permission either. You’ll need to wait till Monday. In the meantime, have you tried rebooting the computer?”

The factory’s plant manager started screaming her way up the managment tree to find someone who could fix this. While she did that, Al looked for a technical fix.

He made an assumption: that if any step of the script failed, for any reason, the error would be ignored. To test that theory, he modified his hosts file to point the file server’s network name back to good ol’ 127.0.0.1 . He logged in, and as he expected, the script failed with a dialog box, but did not copy down fresh DLLs. Al still had a dozen computers that had been corrupted by LOGON.EXE, but by pushing out the new hosts file to every computer, he could at least keep the damage from spreading.

It only took a few hours, but eventually a highly inebriated domain admin logged in from home and disabled the login script for the weekend. On Monday, Al returned to find a memo from the CTO, which CCed his boss, cautioning them that, “Disabling our security policy warnings is a violation of IT policy. We understand that in some cases exceptions must be made, but in the future, you must use proper channels to resolve IT outages.”

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!