Windows Insider

Wagging the Finger

Admins need to wean themselves from the GUI and embrace the command line.

• By Greg Shields
• 05/01/2008

If you're an IT administrator still primarily using the GUI for completing tasks on your servers and workstations, there's a reason why you're overworked. Though many GUI tools are available to assist with common management tasks, you're still manually completing them rather than truly automating. And if you're an IT manager with a team of admins doing the same, then you're not getting the best efficiencies out of your team's time.

In either case, my wagging finger says that neither group gets the privilege of complaining until either learns more repeatable and scriptable ways to get the job done.

The Proactive Paradox
You may think this is a pretty bold statement, but let me explain my reasoning. It seems lately I've been having a long string of conversations with IT administrators in every industry complaining about their level of work. These admins yearn for the day when they can move out of their reactive environment of daily firefighting to one of proactive and predictable change.

What's interesting about these conversations is that they all seem to go something like this:

Administrator: "Greg, I'm tired of the firefighting and cleaning up problems in my network after they happen. What can my IT team do to be more proactive with our systems management?"

Greg: "Have you tried implementing a systems-management toolset like [insert toolset name here]?"

Administrator: "Absolutely! We bought [toolset] a year ago, installed it, and haven't touched it since. It sucks. It's hard to use and once in a while we think it crashes computers."

Greg: "In my experience, I've found that the fault usually isn't with [toolset], but actually in how you use it. First, try weaning yourself from using the Windows GUI for common tasks. By doing so, you're forced to use command-line tools, application packaging rather than manual installations, and scripting tools like VBScript and PowerShell whenever possible. In the end, you'll learn how best to use [toolset]."

Administrator: "Ahh, then we'll just have to get rid of [toolset], because with all the firefighting we just don't have time to learn those skills."

So how does this all relate to getting inside Windows? There's a paradox associated with any move from reactive mode to proactive mode. Specifically, there's a bit of short-term extra effort required to learn new techniques in addition to new technology. Only after you've spent that extra effort does everything get easier in the end.

Management toolsets available today from companies like Microsoft, Kaseya, Kace, Enteo, Altiris and LANDesk all enable savvy administrators to accomplish miraculous wonders without ever leaving their desk. Rapid deployment of software and patches, reporting and inventory on software and hardware characteristics, and even full OS installation with user personality migration are all capabilities of these management toolsets. But rare is the toolset that can do its magic without requiring additional skills like scripting, application packaging and a comfort level with directly modifying the Windows registry.

Easy Activities Made Hard
Let's look at a task that in the reactive environment is often painful and time-consuming: upgrading third-party software. Let's say, as an example, you have a reactive environment with 100 workstations, 60 of which require a software upgrade. In this case the upgrade could take days spent scouting to locate which systems need the software and coordinating with users for a time to complete the install -- all on top of the actual installation process itself.

Even if the install itself only takes 10 minutes to complete, this extra coordination and project planning can increase the total time per installation to an hour or more. This additional 60 hours of work can be a primary cause of IT overtime. Moving the project to an evening or weekend when users aren't around reduces that overall quantity of time, but also keeps admins at work when they should be home with their families. In this example, the lack of automation itself is directly responsible for the organization's reactive-mode IT.

The tools and techniques with today's systems-management toolsets are both mature and stable. With the right skills in place, the process of packaging that software update can often require less than a day of work to complete and test. Configuring and scheduling the package's delivery take only a few minutes. Installations can occur overnight while users and admins alike are away from the office. Most toolsets provide rich reporting mechanisms to help admins locate which installations completed successfully and which did not.

The same benefits hold true for setting desktop configurations. With any of today's systems-management toolsets, any command run at a desktop's command prompt can be delivered as a "software deployment." The process to run a command's .EXE file is the functional equivalent of running software's setup.exe installation routine.

As an example, consider the situation where a reconfiguration of a DHCP server requires the immediate need to release and renew addresses on each client. With reactive IT, this need forces teams to "sweep the floor" and run the action individually on each desktop. The team's processing of help desk tickets stops until the immediate need is completed, and typically, firefighting ensues.

With a systems-management toolset in place, the process is as simple as creating a software "package" that deploys the command ipconfig.exe -renew.

So you can see my frustration. The tools and techniques are all available to make the process of managing today's Windows networks easy. The hard part is in moving from GUI to the command line. All you need to do is take the time to learn.