From the MVPs: Windows Server 2012’s human-friendly core

Here’s the 19th post in our series of guest posts by Microsoft Most Valued Professionals (MVPs). (Click the “MVPs” tag in the right column to see the rest.) Since the early 1990s, Microsoft has recognized technology champions around the world with the MVP Award. MVPs freely share their knowledge, real-world experience, and impartial and objective feedback to help people enhance the way they use technology. Of the millions of individuals who participate in technology communities, around 4,000 are recognized as Microsoft MVPs. You can read more original MVP-authored content on the Microsoft MVP Award Program Blog.

This post is by Michal Gajda, a Microsoft PowerShell MVP .

Michal here! Windows Server 2012, especially in Server Core version, gives us much more powerful system management. Previous versions of Windows Server in text mode could scare administrators a little bit, mainly because the first release did not support PowerShell (mainly due to the inability to use .NET in Server Core version). This problem was solved in the second release of the system, but PowerShell console (in version 2.0) wasn’t available after installation by default. Adding it required knowledge from administrators about basic command-line tools. Also, PowerShell included a small number of extensions, which mainly focused on the use of individual roles rather than on managing the entire system.

Windows Server 2012 in this regard makes a huge step forward. We have the third edition of PowerShell immediately after installation. On board it has several modules to manage even the basic elements of the system. We can see the biggest difference in the network configuration. We have here several independent PowerShell modules. We can say goodbye to netsh.

Scenario 1 – Network adapter management

First we can test management of network adapters. As the name suggests, we have available cmdlets from NetAdapter module. Let's see what we can do:

Get-Command -Module NetAdapter

One of the first elements we should check are adapters available in the system. For this we use this cmdlet:

Get-NetAdapter

A basic call of this cmdlet will return a list of available adapters and a small piece of data about them. But it isn’t all what we can get:

Get-NetAdapter | Format-List

And now we can see more interesting information. Besides the connection name, mac address, or interface status, we can see what kind of media type is used by connection, what link speeds are available, or, if we go deeper into the network adapter object, we can find information about drivers that are used by specific connection.

Making advanced operations in configuration of the network interface is simplified. We just need to type one cmdlet with specific parameters. For example, in the past, if we wanted to disable TCP Offload options, we had to go to the registry and change there some values. Now we can call

Set-NetAdapterAdvancedProperty -Name Ethernet -DisplayName "TCP Checksum Offload (IPv4)" -DisplayValue "Disabled"

And as we can see the value has been changed in transparent way for administrator.

Another interesting feature of this module is, for example, Disable-NetAdapter or, analogously, Enable-NetAdapter to turn off or turn on a specific network adapter:

Disable-NetAdapter -InterfaceAlias Ethernet

Enable-NetAdapter -InterfaceAlias Ethernet

Or, when we want to perform a quick restart of a specific adapter, we can use:

Restart-NetAdapter -Name Ethernet

If necessary, we can modify the name of the interface:

Rename-NetAdapter -Name Ethernet -NewName Eth0

It is very useful when we have a server with multiple adapters. It allows you to organize your work.

Scenario 2 – TCPIP management

In a second scenario, I will try to present the TCPIP configuration for a specific network interface. For that we will use PowerShell modules named NetTCPIP and DNSClient.

First let's check configuration on interfaces. For that we have cmdlet Get-NetIPConfiguration especially with the parameter Detailed:

Get-NetIPConfiguration –Detailed

As we can see, we have two interfaces, but only one of them is configured with a static IP address. Before we configure the second interface we have to be familiar with two concepts. The first one is to set up new configuration, namely the creation of a new instance of the configuration: for example, assign IP address. The second one is to change the configuration of existing instance.

If we want assign new or next IP address to adapter, we use cmdlet New-NetIPAddress. But if we want to change it only—for example, change the subnet prefix—we must use Set-NetIPAddress. In PowerShell it makes a difference, unlike netsh commands.

So let's try to set up next interface with an address from a different subnet. For that we use New-NetIPAddress. The human-friendly solution here is the ability to use connection name or interface index according to our convenience. Personally I prefer interface index because it speeds up operations.

New-NetIPAddress -InterfaceIndex 16 -IPAddress 10.10.12.4

“oops we forgot to change the subnet mask” – default prefix is 32. Then we use:

Set-NetIPAddress -IPAddress 10.10.12.4 -PrefixLength 24

If we have the static tcp ip configuration, we can't forget about dns settings. This case is quite simple. We are using Set-DnsClientServerAddress with defining the interface, which we want to use. The last parameters, which we have to configure, are addresses of DNS servers.

Set-DnsClientServerAddress -InterfaceIndex 16 -ServerAddresses 10.10.12.2

But let's get back to the NetTCPIP module. This module not only offers you the change of the TCPIP configuration but also allows users to replace several other tools, such as old route or netstat.

First let's look at routing configuration. To show current routing table, we use:

Get-NetRoute -InterfaceIndex 12

Of course, we can also change it. For example, let's change current settings of default gateway for adapter called “Ethernet” to second adapter “Ethernet 2”. The first step is to remove old configuration about default gateway:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0

And the next step is to create a new instance of default gateway:

New-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 10.10.12.254 -InterfaceIndex 16

The last thing I want to show in this scenario is how to check the status of our connections. For that we use the cmdlet:

Get-NetTCPConnection

Using this command allows you to easily filter data by choosing parameters with specified criteria. For example, this command checks all active connections for RDP service:

Get-NetTCPConnection -State Established -LocalPort 3389

Scenario 3 – Firewall configuration

In the last scenario I will just bring the issues of configuring the Windows firewall service. It is a large case, so I will focus here only on a few simple examples. To manage the firewall service. we can use PowerShell with dedicated NetSecurity module for it.

Basic management tasks of that service is the configuration of firewall profiles. To show current profiles settings, we can use cmdlet:

Get-NetFirewallProfile

Similarly, to change the profile settings, we use Set-NetFirewallProfile. Here’s an example. We need to block default action for inbound connection, and we need to allow all outbound action on public profile.

Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow -Profile Public

For most standard operations we can use built-in firewall rules—for example:

Get-NetFirewallRule | Select DisplayGroup, Enabled -unique

But to manage them we can use a pair of cmdlets: Enable-NetFirewallRule and, similarly, Disable-NetFirewallRule. For example, to get access to Remote Desktop service, we use:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

In more advanced tasks, for example, if we need open specific port, we have to create a new custom rule. Suppose that we want to allow inbound access to TCP port 80:

New-NetFirewallRule -DisplayName "Allow TCP 80" -Direction Inbound –LocalPort 80 -Protocol TCP -Action Allow

Or if we need access to specific application:

New-NetFirewallRule -DisplayName "Allow msg" -Program "msg.exe" -Action Allow

Conclusion

The idea of working on a core version of Windows Server is nothing new. Even before core versions of systems, the command-line tools allowed automation of many administrative tasks. Unfortunately, many of these tools are very different from each other. For example, sometimes syntax of one tool is completely different than that in another one. However, if we have a tool such as PowerShell 3.0 installed by default, Windows Server 2012 Core is more human-friendly. And even when we have to perform some basic operations such as network configuration, we get a set of predefined modules that we can use in the same unified PowerShell way.

I hope that my brief presentation of system capabilities will convince you to use Windows Server 2012 in text mode.