You normally don't administer servers sitting in front of the physical box. This is both inconvenient and contradicts the basic principles of client-server architecture. The server, by definition, should devote its computing resources to serve client requests instead of attending to itself (or its operators).

It is a commonplace to manage a server and its applications remotely. This is especially true for (but definitely not limited to) a Server Core box.

Definition

There are generally many types of what can be classified as “Remote Management”. E.g. deploying software updates with ConfigMgr or monitoring server workload with OpsMgr is by all means “Management” and it obviously qualifies to be “Remote”. Connecting using some kind of KVM or BMC (e.g. iLO for HP servers or DRAC for Dell hardware) is another case. But for the context of this particular article three scenarios are particularly relevant.

1. Remote Desktop (aka Terminal Services) session.
2. Command-line session.
3. Application-specific. Usually this means all types of remote consoles (MMC-based or stand-alone).

Application-Specific Management

The above list is in the order from most common to most recommended. This means that the first try should be an application-specific remote management. Most decent server applications support some kind of remote management with or without a special admin application (usually called a console) that can be deployed to the management station. Recently a clientless management became popular with increasing role of web-based admin interfaces.

Usually this method generates the least overhead on the remote managed server and provides the richest functionality. It also minimizes the learning curve since you don't need to learn complex command-line syntax or scripting. Instead, you continue to use the tools everyone is familiar with (which you maybe used to run on the server itself).

The downside of remote consoles is that they sometimes require complex firewall setup (especially in case third-party firewall solutions are used — either host-based or somewhere in between the server and your management station). For example a lot of consoles rely on RPC/DCOM which requires a whole bunch of high ports (known as Dynamic Port Range) to be open (allowed to pass).

Remote Command Line

If the remote console is not an option (either due to networking restrictions or there's simply no console for this particular task) try remote command-line management. You can choose from a wide list of available options.

• Windows PowerShell Remoting — as native for Windows as Remote Desktop. Highly recommended.
  • One of the hidden traps of this method are legacy interactive command-line utilities like netsh or diskpart. Their interactive mode are not handled correctly by PowerShell Remoting. Fortunately, these limitations are not that hard to work around - one could just use non interactive modes for such applications. 
  • One of the advantages of Windows PowerShell Remoting is that it increasingly becomes a standard for Microsoft application-specific consoles (discussed in the previous section). E.g. if you enable Server Manager Remote Management this implies that now you can also connect with Windows PowerShell Remoting without any additional setup.
  • Second huge advantage of PowerShell remoting is that it encrypts the data sent between servers by default.
• WinRS - This utility uses same base protocol for remote connections as PowerShell Remoting - WinRM, but instead of PowerShell, it uses cmd.exe to execute commands on remote side.
• Telnet — legacy protocol used to be native for older versions of Windows and highly interoperable with 3^rd-party tools. The protocol is not secure and highly discouraged.
• PSExec — a Sysinternals tool mostly famous for its ease of use and wide list of systems supported. Problem that PSExec itself is not supported by Microsoft. It is also not secure which means it should never be used on untrusted networks. To execute remote commands PSExec uses simple agent that is automatically installed on remote computer.
• SSH — a 3^rd party protocol highly popular in non-Windows world. Can be useful in some special scenarios (e.g. interoperability is a top priority).

Note. The above list is not complete. It represents only the most popular options in order from most recommended to most niche. There are obviously other less common options. E.g. VBS (legacy scripting language) has its own built-in option to execute scripts remotely which is both little known and little used due its complexity.

Exception. If the command-line application runs locally on your management station and manages the remote system using the application-specific protocol or API this qualifies for the first option (application-specific management), not this one.

Exception from the exception. Windows PowerShell introduces additional complexity in the latter scenario. In some cases the same Windows PowerShell session can combine cmdlets running locally with a specific set of cmdlets that look also local but are directly executed on the remote system.

Remote Command-Line management is also the obvious choice for all the normal cases where you'd want to use scripting. E.g. automating some routine and repetitive or rare and complex tasks.

Remote Desktop

The last resort is Remote Desktop. It is nearly bullet-proof. It is much more close to local management than to anything else called “Remote”. There is a number of reasons why, comparing with all the abovementioned options, it is not recommended for day-to-day usage.

• In absolutely most cases it is an overkill and provides you with much more options than necessary. (Which, in turn, can multiply the probability of human error).
• It generates the most overhead on the remote managed system.
• It is hardly journaled (which means it's hard to audit, reproduce or simply analyze later).
• In case of Server Core it is nearly noting better than remote command-line interface (discussed above).

With that said, there is obviously an endless list of uncommon tasks that can be only done using the “Nearly local” session. Obviously, Remote Desktop has a number of strong advantages over two abovementioned methods.

• One Stop. There is hardly an application in your environment that is incompatible with Remote Desktop and cannot be managed with it. Rare examples of such apps are those with special software protection features implemented to prevent unauthorized multi-user scenarios on Remote Desktop Session Host (RDSH) servers. But they are highly uncommon for server deployments.
• Simplicity. There's a number of tasks that are theoretically scriptable but so uncommon that scripting seems impractical to them. On the flip side, full interactive GUI is a huge advantage of Windows Ecosystem that is unwise to left out. Such tasks mostly fall into one of the following two categories.
  • Initial server setup (for small-scale deployments).
  • Troubleshooting (for uncommon and complex issues).
• Firewall tolerance. Only one network port is required for Remote Desktop. Also it is customizable and can even be wrapped into the SSL layer that means nearly full firewall transparency (including Internet connectivity scenarios).