Windows Server 2019 – Interfacing with Server Core

How to build a Docker Compose YAML files

After running through your first installation of Server Core, you will be presented with the following lock screen:

Is that really a Command Prompt window that says Press Ctrl-Alt-Del to unlock? Yes, yes it is. This usually gets a few chuckles when an admin sees it for the first time. I know it did for me, anyway. It reminded me a little of when we used to code if/then games on our TI-83 calculators during high school math class. Press Ctrl + Alt + Del, and you will be prompted to change your administrator password for the first time, which is the same task that must always be performed first inside GUI versions of Windows Server. Except, of course, that you do it all from within the Command Prompt window using only your keyboard. Once you are officially logged into the server, you will find yourself sitting at a traditional C:\Windows\system32\cmd.exe prompt, with a flashing cursor awaiting instructions:

Interestingly, the Command Prompt window isn’t consuming the full screen; it is clear that there is a black background that cmd.exe is riding on top of. I only find this interesting because you can tell that the Core operating system itself is something other than Command Prompt, and that cmd.exe is just an application that autolaunches upon login. You can even utilize the mouse here and resize or move that Command Prompt window around. I do wonder if and when this will be replaced with a PowerShell prompt as the default interface.

Even more interesting and good to know is that you can launch some actual GUI-like applications from this prompt. For example, you can open up Notepad and utilize it with both keyboard and mouse, just like you would from any version of Windows. If you have Notepad open, create a note and then save it; you can see that there is in fact a real file structure and a set of relatively normal-looking system folders. So rather than some form of black magic, Server Core is actually the real Windows Server operating system, wrapped up in a smaller and more secure package:

PowerShell

So, as far as managing a Server Core, you can obviously work straight from the console and use Command Prompt, which appears to be the default interface presented by the OS. In reality though, the commands and functions available from inside Command Prompt are going to be limited. If you are working from the console of a Windows Server Core box, it makes much more sense to use Command Prompt for just one purpose: to invoke PowerShell, and then use it to accomplish whatever tasks you need to do on that server. The quickest way I know to move into PowerShell from the basic Command Prompt is to simply type the powershell and press Enter. This will bring the PowerShell capabilities right into your existing Command Prompt window, so that you can start interfacing with the PowerShell commands and cmdlets that you need in order to really manipulate this server:

What is the first thing we typically do on new servers? Give them IP addresses, of course. Without network connectivity, there isn’t much that we can do on this server. You can assign IP address information to NICs using PowerShell on any newer Windows Server, but most of us are not in the habit of doing so. Since we can’t just open up Control Panel and get into the Network and Sharing Center like we can from inside the Desktop Experience GUI of Windows Server, where do we begin with getting network connectivity on this new Server Core?

Using cmdlets to manage IP addresses

Here are cmdlets that you can use to view and manipulate IP address settings from within PowerShell. Again, these same cmdlets can be used in the full GUI version of Windows Server or from within Server Core.

Currently, working from Server Core where we only have command-line interfacing available to us, these cmdlets are essential to getting network connectivity flowing on our new server:

  • Get-NetIPConfiguration: This displays the current networking configuration.
  • Get-NetIPAddress: This displays the current IP addresses.
  • Get-NetIPInterface: This shows a list of NICs and their interface ID numbers. This number is going to be important when setting an IP address, because we want to make sure we tell PowerShell to configure the right IP onto the right NIC.
  • New-NetIPAddress: This is used to configure a new IP address.
  • Set-DNSClientServerAddress: This is used to configure DNS Server settings in the NIC properties.

Let’s quickly walk through the setup of a static IP address on a new Server Core instance to make sure this all makes sense. I want to assign the 10.10.10.12 IP address to this new server, but first we need to find out which NIC interface ID number it needs to be assigned to. The output of Get-NetIPInterface tells us that the ifIndex I am interested in is number 4:

Now that we know the interface number, let’s build the commands that are going to assign the new IP address settings to the NIC. I am going to use one command to assign the IP address, subnet mask prefix, and default gateway. I will use a second command to assign DNS server addresses:

New-NetIPAddress -InterfaceIndex 4 -IPAddress 10.10.10.12 -PrefixLength 24 -DefaultGateway 10.10.10.1

Set-DNSClientServerAddress -InterfaceIndex 4 -ServerAddresses 10.10.10.10,10.10.10.11

Hold the phone! How did I get two PowerShell prompts open at the same time within the Server Core interface? Make sure to read the Accidentally closing Command Prompt section later in this chapter to discover how you can launch multiple windows and tools inside the Server Core console.

Now all of these IP settings should be in place on the NIC. Let’s double-check that with a Get-NetIPConfiguration command, seen in the following screenshot. Alternatively, you could use good old ipconfig to check these settings, but where’s the fun in that?

Remember, you can always utilize DHCP Reservations to make this a little bit easier. If you were to run a simple ipconfig /all from your Server Core and jot down the MAC address of your NIC, you could use this address to create a reservation in DHCP and assign a specific IP address to the new server that way.

Setting the server hostname

Now that we have network connectivity, a good next step is setting the hostname of our server and joining it to the domain. First things first, let’s see what the current name of the server is, and change it to something that fits our standards. When you freshly install Windows, it self-assigns a random hostname to the server. You can view the current hostname by simply typing hostname and pressing Enter:

To change the hostname of your server, we need to use PowerShell. Bring yourself into a PowerShell prompt if not already there, and all we need to do is use the Rename-Computer cmdlet to set our new hostname. I have decided to name my new server WEB4, because later we will install the Web Services role onto it and host a website. Remember, after renaming your computer just like in the GUI version of Windows Server, a system restart is necessary to put that change into action. So following your Rename-Computer command, you can issue a Restart-Computer to reboot the box:

Rename-Computer WEB4

Restart-Computer

Joining your domain

The next logical step is, of course, joining your domain. These are the standard functions that we would perform on any new server in our environment, but done in a way that you may have never encountered before, since we are doing all of this strictly from the Command Prompt and PowerShell interfaces. To join a Server Core to your domain, head into PowerShell and then use the Add-Computer cmdlet. You will be asked to specify both the domain name and your credentials for joining the domain—the same information you would have to specify if you were joining a Windows Server 2019 in Desktop Experience mode to a domain. First, you must specify the credentials needed in order to do this domain join:

Then you tell it what domain you would like to join:

Alternatively, you could utilize the -DomainName parameter in combination with the original Add-Computer cmdlet in order to specify the name of the domain as part of the original command. And of course, after joining the domain, you need to Restart-Computer once again to finalize this change.

Remote PowerShell

Once the new server is IP-addressed, named, and domain-joined, we can start doing some real administration on this new Server Core instance. You could certainly continue to log in and interface directly with the console, but as with managing any other server in your environment, there must be ways to handle this remotely, right? One of the ways that you can manipulate Server Core without having to sit in front of it is by using a remote PowerShell connection.

We will cover the process for using remote PowerShell to manipulate servers (both GUI and headless) in more detail in Chapter 10, PowerShell, but here is a glimpse of the commands necessary and the capabilities present when you are able to achieve a remote session from a PowerShell prompt on a workstation inside a domain-joined environment.

Open up PowerShell from another system—it can be a server or even a client operating system. This PowerShell window is obviously open within the context of whatever machine you are currently logged into, and any commands you issue via PowerShell will illicit a response from the local system. In order to tap PowerShell into the WEB4 Server Core instance, I will issue the following command. After running this, I am prompted for a password corresponding to the administrator account, and will then be able to issue remote PowerShell commands against our Server Core:

Enter-PSSession -ComputerName WEB4 -Credential administrator

Now we are sitting at a PowerShell prompt, remotely connected to the WEB4 Server Core box. You can see this by (WEB4) being listed to the left of our prompt. Perhaps you don’t trust that little identifier, and want to make sure that this PowerShell window is now accessing and manipulating the remote WEB4 server? Let’s issue a couple of quick commands, such as hostname and ipconfig, to prove that the information being given to us in this PowerShell session is really coming from the new WEB4 server:

Now that we have a remote PowerShell connection to this new Server Core, we can do pretty much whatever we want to that server, right from this console.

Server Manager

While the initial configuration of your server will be somewhat handled from the command-line interfaces available at the console, once your server has been established on the network, it will likely be more advantageous for you to expand your horizons a little. You could probably find PowerShell cmdlets that allow you do manage and manipulate anything in your new server, but that is still a pretty new mentality for most of us—we are generally more accustomed to using graphical tools such as Server Manager. You already know that Server Manager can be used to manage multiple servers, local and remote, and is a piece of the Microsoft centralized management puzzle. This remote management capability in Server Manager that we explored earlier in the book allows you to tap into not only GUI-based Windows Servers, but Server Core instances as well.

I want to install a role onto my new WEB4 server. I could do that with PowerShell right on the server console, but instead let’s try adding WEB4 into Server Manager that is running on another one of my servers. I am going to log into WEB3, and use Server Manager from there. Just like we have already seen, I can add a new server into Server Manager using the Manage menu and choosing Add Servers:

Add the new WEB4 server into our list of managed machines, and it is now manageable from inside this instance of Server Manager. Getting back to what my original intentions were, I want to install the Web Server (IIS) role onto WEB4. If I use the Add roles and features function inside Server Manager, I can now choose to manipulate the WEB4 server:

Just like with any server running the full Desktop Experience version of Windows Server, we can now finish walking through the role installation wizard, and the Web Server role will be installed on WEB4.

Remote Server Administration Tools

Also true is the fact that you can manage Server Core instances with the Remote Server Administration Tools (RSAT) in Windows 10. RSAT is essentially just a copy of Server Manager that is designed to run on the client operating system. In our case, I already have a Windows 10 machine on which I installed RSAT earlier in the book, so I will test by logging into that guy and adding WEB4 into the interface. I just finished installing the IIS role on WEB4 in our previous task, so I should be able to see that listed inside RSAT when I connect it to WEB4.

If you haven’t used RSAT before and haven’t read over that section of our text, it is important to know that there is no application called Remote Server Administration Tools. Instead, after the RSAT installation has completed, take a look inside your Start Menu for the application called Server Manager. This is how you utilize a Windows 10 client to remotely manage Windows Server 2019 instances:

Exactly like you would do from a Server Manager interface of Windows Server 2019, go ahead and walk through the wizard to add other servers to manage. Once I have added WEB4 as a Managed Server in my Win10’s Server Manager, I can see IIS listed inside my Dashboard. This indicates that my IIS service running on WEB4 is visible, accessible, and configurable right from my Windows 10 desktop computer. For the majority of the tasks that I need to accomplish on WEB4, I will never have to worry about logging into the console of that server.

If I right-click on the WEB4 server name from within this RSAT console, you can see that I have many features available to me that I can use to manage this remote Server Core instance:

So you can see that there are ways to use the GUI tools in order to manage our GUI-less instances of Windows Server. It’s just a matter of putting your mind into a place where you are thinking of servers as headless, and that tools such as PowerShell or Server Manager really don’t care at all whether the server they are changing is local or remote. The processes and tools are the same either way. You can see in the previous screenshot that I could even click from here in order to launch a remote PowerShell connection to WEB4. Clicking on this button immediately launches a PowerShell prompt that is remotely tied to the WEB4 server, even though I am currently only logged into my Windows 10 workstation. This is even easier than issuing the Enter-PSSession cmdlet from inside PowerShell.

Accidentally closing Command Prompt

Let’s take a look at one more thing directly from the Server Core console; this is a common hurdle to overcome if you haven’t utilized Server Core much. It is our tendency to close windows and applications that are no longer being used, and so you might unconsciously close the Command Prompt window that is serving your entire administrative existence within a Server Core console session. Now you’re sitting at a large blank screen, with seemingly no interface and nowhere to go from here.

How do you get back to work on this server? Do we have to turn the server off and back on in order to reset it? That would interrupt any roles or traffic that this server might be serving up to users, so obviously it isn’t the ideal approach.

There is a simple way to get Command Prompt back, by using Task Manager to launch a new instance of Command Prompt. After mistakenly closing your current Command Prompt window, when sitting at the empty black screen of a Server Core console, you can press Ctrl + Alt + Del and you will be presented with the following options:

There are actually a few different functions you can perform here, which is pretty neat. But to get our Command Prompt window back, arrow-down to Task Manager and press Enter. This will launch the Task Manager application that we are all familiar with. Now click on More details in order to expand Task Manager’s screens. Drop down the File menu, and click on Run new task:

In the Create new task box, type cmd and then click on OK:

Alternatively, you could specify to launch any application directly from this Create new task prompt. If you were interested in moving straight into PowerShell, instead of typing cmd, you could instead simply type powershell into that prompt, and it would open directly:

Comments are closed.