kentoh - Fotolia
CLI vs. GUI: Find the right admin tool for various scenarios
Standard Windows and Linux command-line utilities oftentimes have niche, yet important functionality not available in GUI tools that require IT workers to make custom workflows.
Server management is all about getting the job done -- preferably with minimal effort by the administrator. Whether to use the standard GUI or command-line tools depends on the circumstances.
Just as Linux is no longer an unwelcome presence in Windows shops, it's no longer a CLI vs. GUI world. More administrators will encounter some variation of the open source server OS, which behooves them to learn how to manage these systems.
In today's heterogeneous data centers, it's not too far-fetched for an IT worker to administer Windows Server from a Linux machine. Microsoft put a Bash shell on Windows with its Windows Subsystem for Linux, a great tool for Linux administrators who need to perform tasks on both systems. Microsoft ported the Linux tools curl and bsdtar to Windows 10 starting with build 17063 released in December. Expect this number to keep growing.
In the first article of this server management tools series, I covered the types of utilities available and the particular scenarios that suit each. Let's take a closer look at the standard Windows and Linux tools and how they fit with typical management situations.
CLI vs. GUI tools -- the pros and cons of each
The standard Windows and Linux tool set breaks down into two groups -- the graphical -- GUI -- tools and the command-line tools. This article excludes PowerShell, which I will cover in the next installment of this server management series.
Most Windows administrators learned with GUI tools. When Microsoft introduced Windows 2000, the company made a large effort to introduce command-line tools and scripting with VBScript. These Windows GUI tools are mainly based on the Microsoft Management Console (MMC), which enables admins to create their own tools.
For example, the admin can load the Active Directory Users and Computers tool into the MMC together with ADSI Edit and the domain name system console for a single console that executes many of an IT worker's day-to-day tasks. This is a great option, but most people prefer to use the individual tools.
The advantage of the GUI tools -- especially in Windows -- is they have a similar look and feel. If you learn one tool, it's not difficult to learn the others. They are also very good for infrequent jobs, such as creating a cluster. The GUI tools offer reminders when the admin must perform a series of steps to complete a task.'
GUI tools have a major disadvantage when it comes to speed. Swapping between the mouse for navigation and the keyboard for data entry is a slow process.
When I handled an Exchange migration for a 12,000-seat organization, I had to discover how many users had Outlook on the web enabled, and then make some changes to their configuration. Clicking through that many users with the GUI tools is a time-consuming task few people would want to undertake.
Command-line tools, especially in Windows, tend to fall into two categories. First, there are the tools that everyone knows and uses, such as ipconfig or ping. These tools don't have a GUI equivalent, and they have been around for so long that admins accept and use them automatically. The second group contains tools that are either unknown to many administrators or are used in rare circumstances, such as chkntfs or wmic.
There are two main problems with command-line tools. First, the syntax can be arcane; there may be little or no consistency between commands. Administrators must spend a lot of time to learn each command or constantly look up syntax. Many Windows administrators tend to give up and revert to the GUI tools, which require less effort to use.
The second, and probably more important point, is command-line tools supply text-based output to the screen -- they weren't designed to work together. Admins can develop workflows that involve a number of command-line tools interacting -- usually by piping the text output from one tool into the next command in the pipeline.
This management approach might be novel to some Windows admins, but it's a staple of Linux administration.
Using Ubuntu and Bash in
Windows 10
To implement it on the Windows side, there are a couple of issues to solve. You have to parse the text from one tool in a way that the second tool understands, which can involve some horrendous string manipulation by diving into the depths of regular expressions.
Next, there is no guarantee the text output of a particular command will remain the same across different versions of the operating system. As soon as the text changes, the workflow breaks.
CLI vs. GUI scenarios that lean toward GUI use
Scenarios in which the standard tools are the right answer include:
- You have a single server to administer. In this case, it probably doesn't matter which tools you use.
- The task is a one-off on a single server.
- There isn't another tool to handle the task.
- The job is infrequent, and the GUI tool guides the admin to completion.
- A single tool can perform the task.
The usefulness of the standard tools breaks down as the number of servers on which the tasks are performed increases. Logging into a server, firing up a tool and executing the action takes time, most of which is spent waiting for connectivity and for the application to start. These waiting periods reduce overall productivity.
When performing multiple actions on multiple servers -- especially if the actions depend on the type of server -- these standard tools lose their effectiveness. The choices are to access each server in sequence and perform the actions or, even worse, have the admin connect to each server multiple times to complete one set of actions before beginning the second set. This becomes an error-prone, time-consuming effort.
Ideally, this is where the CLI vs. GUI tool pendulum swings in the command-line tool's favor, and the admin finds a way to automate these tasks through scripting.
