Nmedia - Fotolia
As the server landscape diversifies and open source systems intermingle with Windows, the assortment of server management tools available to administrators also expands.
The modern administrator can have a mix of server operating systems with a wide range of scenarios they can administer with a diverse suite of server management tools. Knowing which application works best in different scenarios requires a deep understanding of the capabilities of each.
Data center evolution complicates management decisions
At one time, life was relatively simple for a Windows Server administrator. Microsoft released a new version of the server operating system every three to five years. Unless the organization was a fanatical early adopter, it would be at least another year before the IT department needed to worry about an upgrade. Even then, IT workers used the same tools to administer those new servers.
For many in IT, that's no longer the case. Windows shops that once had one or two versions of Windows Server might now have to deal with:
Multiple Windows Server versions. Microsoft currently supports Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016. An organization might have a combination of all these systems.
Semi-Annual Channel releases. Microsoft issues a new Windows Server release with feature updates every six months in its Semi-Annual Channel (SAC) -- the first, Windows Server version 1709, came out in September 2017 -- with a supported lifecycle of 18 months
Linux servers. To accommodate its customers, Microsoft shifted its stance to embrace choice at the operating system level and developed management tools for Windows and Linux systems.
And this is just what's potentially in the data center. Add cloud services from providers such as Microsoft, Amazon Web Services and Google and the administrative complexity grows.
The choice of server management tools flourishes
At one time, most administrators used the standard GUI tools, usually based on the Microsoft Management Console. IT workers who felt brave -- or came across an oddity not covered by traditional utilities -- used a command-line tool to address the issue. It was rare to find an administrator who dabbled in VBScript -- and possibly Windows Management Instrumentation (WMI) -- to manage servers.
Now, there is a much wider range of server management tools, including:
Traditional GUI tools, such as the Remote Server Administration Tools.
Command-line tools based on both Windows and Linux. The Windows Subsystem for Linux on Windows 10 and the Windows Server SAC versions work with Bash and Linux tools natively.
Windows PowerShell, which works on Windows Server, although the same version is not available on all server versions. Administrators can investigate PowerShell Core for use on later Windows versions, Linux and macOS systems.
Cloud-based tools, such as Operations Management Suite, to connect to on-premises servers.
There are also third-party management tools; but in my experience, I find most organizations don't use them.
PowerShell enhancements increase acceptance
Microsoft released PowerShell 1.0 in 2006, but its adoption as a mainstream administration technology did not pick up until the last several years. The biggest boost to PowerShell was likely attributable to the huge increase in cmdlet coverage in late 2012 with the release of Windows 8 and PowerShell v3. Administrators could perform many more tasks with a single cmdlet rather than lengthy script, which made life easier for the IT worker trying to learn PowerShell.
When I started as a server administrator in 1990, most of us were responsible for a handful of servers. Now, administrators manage hundreds or thousands of servers. When there are only a few servers to control, it's possible to manage each locally. This includes the use of remote desktop protocol to create a remote connection into the machine.
All administration activities start with a single task on a single server. This scenario expands to perform that one task on multiple servers. This is doable, but you'll reach a scale where you can't type or click fast enough to get the job done in a sensible time frame. For large quantities of systems, administrators must use remote management and automation.
When you must perform multiple tasks on multiple servers, you might miss a step for one or more servers. This could cause problems later. In these situations, I assume the machines belong to a single domain. Once you go beyond a single domain, the issues proliferate.
Remote administration of one or more non-domain joined systems is a common administration situation. The machines can be web servers in the demilitarized zone or stand-alone servers that the organization cannot join to a domain.
These scenarios further complicate the decision on how best to administer these machines when you must factor in network access, firewall settings and permissions to the system. Management of cross-domain servers is similar but slightly different because, usually, there is no need to cross firewalls and the permissions can be easier to handle.
The final scenario to consider is the administration of Windows machines from a Linux system or the opposite. Either setting could come about when the organization works with a majority of one type of machine but introduces another type to support a new application.