Windows Server 2019 – Remotely managing a server

Install PHP on CentOS 8

Now that we have worked a little bit in the local instance of PowerShell, and have explored a couple of methods that can be used to start creating scripts, it is time to take a closer look at how PowerShell fits into your centralized administration needs. If you start using PowerShell for server administration, but are still RDPing into the servers and then opening PowerShell from there, you’re doing it wrong. We already know that you can tap remote servers into Server Manager so that they can be managed centrally, and we also know that the tools inside Server Manager are, for the most part, just issuing a series of PowerShell cmdlets when you click on the buttons. Combine those two pieces of information, and you can surmise that PowerShell commands and cmdlets can be easily run against remote systems, including ones that you are not currently logged into.

Taking this idea and running with it, we are going to look over the criteria necessary to make this happen in our own environment. We are going to make sure that one of our servers is ready to accept remote PowerShell connections, and then use a PowerShell prompt on a different machine in order to pull information from and make changes to that remote server.

Preparing the remote server

There are just a couple of items that need to be running and enabled on your remote servers in order for you to tap PowerShell into them from a different machine. If all of your servers are Windows Server 2019 (in fact, if they are all Windows Server 2012 or higher), then PowerShell remoting is enabled by default, and you may be able to skip the next couple of sections. However, if you try to use PowerShell remoting and it’s not working for you, it is important that you understand how it works under the hood. This way, you can troubleshoot it and manually establish remote capabilities in the event that you run into problems, or are running some older operating systems where these steps may be necessary. It is also possible that you have pre-existing security policies that are disabling components used by the remote connection capabilities of PowerShell, so if you find your remote access to be blocked, these are the items to look into on those systems.

The WinRM service

One piece of the remote-management puzzle is the WinRM service. Simply make sure that this service is running. If you have stopped it as some sort of hardening or security benefit, you will need to reverse that change and get the service back up and running in order to use PowerShell remoting.

You can check the status of the WinRM service from services.msc, of course, or since we are using PowerShell in this chapter, you could check it with the following command:

Get-Service WinRM  


Typically, the only other thing that needs to be accomplished on your remote server is to run a single, simple cmdlet. Well, it needs to have network access, of course, or you won’t be able to see it on the network at all. But other than making sure network connectivity and flow are working directly from the console of your new server, you are then ready to issue the PowerShell command that enables this server to be able to accept incoming, remote PowerShell connections:

Enable-PSRemoting -Force

Using -Force at the end of the Enable-PSRemoting command causes the command to roll without asking you for confirmations. There are a few different things that Enable-PSRemoting is doing in the background here. First, it is attempting to start the WinRM service. Why did I already specify that you should check it manually? Because if you have it disabled as part of a lockdown strategy, you will interfere with this process. Checking WinRM before using Enable-PSRemoting increases your chances of success when running the Enable-PSRemoting cmdlet. There are two other things that this command is doing: starting the listener for remote connections and creating a firewall rule on the system to allow this traffic to pass successfully.

If you intend to use PowerShell remoting on a large scale, it is daunting to think about logging into every single server and running this command. Thankfully, you don’t have to! As with most functions in the Windows world, we can use Group Policy to make this change for us automatically. Create a new GPO, link and filter it appropriately so that it only applies to those servers that you want to be centrally managed, and then configure this setting: Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service.

Set Allow remote server management through WinRM to Enabled, as follows:

Allowing machines from other domains or workgroups

If you are working with servers that are all part of the same corporate domain, which will most often be the case, then authentication between machines is easy to accomplish. They automatically trust each other at this level. However, on the server you are prepping to accept remote connections, if you expect those computers will be members of a different domain that is not trusted  or even members of a workgroup  then you will have to issue a command to manually trust the individual computers that are going to be connecting in. For example, if I am planning to manage all of my servers from a client computer called Win10Client that is not trusted by the servers, I would need to run the following command on these servers:

Set-Item wsman:\localhost\client\trustedhosts Win10Client

If you wanted to allow any machine to connect remotely, you could replace the individual computer name with a *, but in general, this wouldn’t be a good practice, as you may be inviting trouble by allowing any machine to connect to your server in this way.

Connecting to the remote server

I typically see administrators utilize remote PowerShelling in two different ways. You can perform some commands against remote systems on an ad hoc basis while your PowerShell prompt is still local, or you can launch a full-blown remote PowerShell session in order to make your PowerShell prompt behave as if it is running directly on that remote system. Let’s take a look at both options.

Using -ComputerName

Many of the cmdlets available in PowerShell, particularly ones that begin with Get-, are able to be used with the -ComputerName parameter. This specifies that the command you are about to run needs to execute against the remote system that you specify in the -ComputerName section. For our remote PowerShell examples, I will be using a PowerShell prompt on my Windows 10 client computer to access information on some of my servers in the network. I want to query the WinRM service, to make sure that it is up and running. For the sake of proving to you that I am remotely communicating with WEB3, you will see in the output that I have first queried my local WinRM service, which I happened to disable on my Win10 workstation.

You see that my local WinRM service shows as Stopped, but when I issue the same command specifying to query ComputerName of WEB3, it reaches out and reports back to me that the WinRM service is indeed Running successfully on the WEB3 server:

Get-Service WinRM  
Get-Service WinRM -ComputerName WEB3

Alternatively, perhaps I want to query the new Server Core instance we set up a little while ago, and check which roles are currently installed on WEB4:

Get-WindowsFeature -ComputerName WEB4 | Where Installed  

The -ComputerName parameter can even accept multiple server names at the same time. If I wanted to check the status of the WinRM service on a few of my servers, by using a single command, I could do something such as this:

    Get-Service WinRM -ComputerName WEB1,WEB2,DC1

Using Enter-PSSession

On the other hand, sometimes you have many different cmdlets that you want to run against a particular server. In this case, it makes more sense to invoke the fully-capable, fully-remote PowerShell instance to that remote server. If you open up PowerShell on your local system and utilize the Enter-PSSession cmdlet, your PowerShell prompt will be a full remote representation of PowerShell on that remote server. You are then able to issue commands in that prompt, and they will execute as if you were sitting at a PowerShell prompt from the console of that server. Once again, I am logged in to my Windows 10 client computer, and have opened up PowerShell. I then use the following command to remotely connect to my WEB4 server:

Enter-PSSession -ComputerName WEB4  

You will see the prompt change, indicating that I am now working in the context of the WEB4 server.

If your user account does not have access to the server, you can specify alternative credentials to be used when creating this remote connection. Simply append your Enter-PSSession cmdlet with -Credential USERNAME in order to specify a different user account.

Commands that I issue from this point forward will be executed against WEB4. Let’s verify this. If I check a simple $env:computername, you can see that it presents me with the WEB4 hostname:

And to further verify this, if I check the installed Windows roles and features, you can see that I have the Web Server role installed, as we accomplished when we initially configured this Server Core to be a web server. Clearly, I do not have the Web Server role installed onto my Windows 10 workstation; PowerShell is pulling this data from the WEB4 server.

Get-WindowsFeature | Where Installed  

This is pretty powerful stuff. We are sitting at our local desktop computer, have a remote PowerShell session running to the WEB4 server, and are now able to pull all kinds of information from WEB4 because it is as if we are working from PowerShell right on that server. Let’s take it one step further, and try to make a configuration change on WEB4, just to verify that we can. Maybe we can install a new feature onto this server. I use Telnet Client quite a bit for network connectivity testing, but can see that it is currently not installed on WEB4.

Get-WindowsFeature -Name *telnet*  

By using the Add-WindowsFeature cmdlet, I should be able to make quick work of installing that feature:

Add-WindowsFeature Telnet-Client 

This remote PowerShell capability is powerful stuff, not only for your servers that are running the full-blown Desktop Experience graphical interface, but also for interacting with your security-focused Server Core deployments. Becoming familiar with working in remote PowerShell sessions will be essential to a successful deployment of Server Core in your infrastructure.

Comments are closed.