Windows Server 2019 – Why move to PowerShell?

How to Change the server name on Windows Server 2019

I don’t think there is any question in people’s minds that PowerShell is indeed the evolution of Command Prompt, but the reason that many of us still default to the old interface is that it still has all of the capabilities to accomplish what we need to do on our servers. What Command Prompt really contains is the ability to do the same things that we have always done from Command Prompt, and nothing else. Without realizing it, there are a lot of functions that you use the GUI to accomplish that cannot be done well from within a Command Prompt window.

The limitations within Command Prompt that force you into using your mouse to interface with the GUI do not exist with PowerShell. It is fully comprehensive and capable of modifying almost any aspect of the Windows operating system. How did PowerShell become so much more powerful than Command Prompt? It differs from any classic I/O shell in that it is built on top of .NET, and runs much more like a programming language than simple input and output commands.


Most of the functionality that a traditional server admin will use comes in the form of cmdlets (pronounced command-lets). These are commands that you run from within the PowerShell prompt, but you can think of them as tools rather than simple commands. Cmdlets can be used to both get information from a server and to set information and parameters on a server. Many cmdlets have intuitive names that begin with get or set, and similar to the way that most command-line interfaces work, each cmdlet has various switches or variables that can be configured and flagged at the end of the cmdlet, in order to make it do special things. It is helpful to understand that cmdlets are always built in a verb-noun syntax. You specify the action you want to accomplish, such as get or set, and then your noun is the piece inside Windows that you are trying to manipulate. Here are a few simple examples of cmdlets in PowerShell to give you an idea of what they look like, and how they are named in a fairly simple way:

  • Get-NetIPAddress: With this cmdlet, we can see the IP addresses on our system.
  • Set-NetIPAddress: We can use this guy to modify an existing IP address.
  • New-NetIPAddress: This cmdlet allows us to create a new IP address on the computer.
  • Rename-Computer: As we saw earlier in the book, Rename-Computer is a quick and easy way to set the computer hostname of a system.

If you’re ever struggling to come up with the name or syntax of a particular command, Microsoft’s online Docs website (formerly and sometimes still called TechNet) has a full page of information dedicated to each cmdlet inside PowerShell. That can be incredibly useful, but sometimes you don’t want to take the time to pop onto the internet just to find the name of a command that you are simply failing to remember at the moment. One of the most useful cmdlets in PowerShell shows you a list of all the available cmdlets. Make sure to check out Get-Command:

Whoa, there are pages and pages and pages of cmdlets! Rather than scrolling through the entire list in order to find the one you are looking for, it is easy to filter this list down based on any criteria that you would like. If we were interested in seeing only the commands that deal with IP addressing, we could give this a try:

Get-Command -Name *IPAddress*

The Get-Command cmdlet combined with the -Name parameter allows you to selectively search for useful items in PowerShell that relate to any name or portion of a name:

PowerShell is the backbone

As you will discover in this chapter, interfacing with PowerShell puts all kinds of power at your fingertips. What we sometimes find, though, is that admins don’t fully trust PowerShell, because they are used to taking these actions and making these changes from a graphical interface. After running a single PowerShell cmdlet to set a configuration that would have taken you a dozen different mouse clicks to accomplish the same thing, it is easy to think that it must not have actually done anything. That was too easy, and it processed my command way too quickly, right? I’d better go into that graphical interface anyway, just to double-check that PowerShell actually did the job.

When I started using PowerShell, I was tempted to do exactly that, all the time. But the more I used it and the more I started digging into those graphical interfaces themselves, the more I realized that I’m not the only one using PowerShell. A lot of the Administrative Tool GUIs use PowerShell too! Without even realizing it, you use PowerShell for quite a few tasks inside the Windows Server operating system. When you open up that management console for whatever you happen to be changing on the server, make your configurations, and then click on the Go or Finish button, how does that graphical console put your configuration into place? PowerShell. Under the hood, in the background, the console is taking the information that you input, plugging that information into PowerShell cmdlets, and running them in order to do the actual configuration work. Many of the Administrative Tools that we run from inside Server Manager take this approach, accepting changes and configurations from you and then formulating those settings into PowerShell commands that run in the background in order to push the changes into action.

So, if you’re hesitant to start using PowerShell because it just feels different, or you don’t trust the process to be uniform to the way that it would have worked in the GUI, forget all of that. Because often when you are using mouse clicks to change settings on your server, you are actually invoking PowerShell cmdlets.


The more you use PowerShell, the more powerful it becomes. In addition to running ad hoc, single commands and cmdlets, you have the ability to build extensive scripts that can accomplish all sorts of different things. I mentioned that PowerShell has similarities to a regular programming language, and scripting is where we start to navigate into that territory. PowerShell provides the ability to create script files, which we will do for ourselves coming up shortly, saving scripts for easy running of those same scripts time and time again. Variables can also be used, like in other forms of coding, so that you can provide variable input and objects that can be used by the scripts, in order to make them more flexible and squeeze even more functionality out of them.

Server Core

If there were any one area where I think we as server admins could do a better job of using the technology at our disposal, it is using PowerShell to fulfill the Microsoft model of centralized management. When we have a task that needs to be accomplished on a server, it is our default tendency to log into that server (usually via RDP), then use our mouse to start clicking around and doing the work. Logging into the server is becoming more and more unnecessary, and we could save a lot of time by using the central management tools that are available to us. PowerShell is one of these tools. Rather than RDPing into that server, simply use the PowerShell prompt on your local machine in order to reach out and change that setting on the remote server.

This kind of remote management becomes not only efficient but necessary, as we start dealing more with headless servers. I hope to see increased utilization of Server Core in our organizations over the next few years, and interacting with these servers is going to require a shift in your administrative mindset. By becoming familiar with accomplishing daily tasks from inside PowerShell now, you will better equip yourself for future administration of these headless machines, which are going to require you to interface with them differently than you are comfortable doing today.

Comments are closed.