Tuesday, June 30, 2015

Windows Server 2012 R2 - Aspects of Remote Management - Down-level Servers

In my last blog post, I examined aspects of remote management with Windows 2012 R2 where the server to be managed (the target server) was running Windows 2012 R2. In this blog post, I'll take a look at managing "down-level" servers, in particular Windows 2008 R2, with Server Manager.

Concerning remote management, Windows 2012 R2 is different compared to previous server versions in two ways:
  • Unlike Windows 2008/R2 (but like Windows 2012), WinRM and remote PowerShell are enabled by default. Of course, the administrator must still authenticate to the remote server before executing commands.
  • The execution policy for PowerShell scripts is set to RemoteSigned (by default) in Windows 2012 R2. The default setting for all other recent Windows operating systems, including Windows 8.1, 8.0, 7, and even 2012 (server), is Restricted.

In the lines that follow, I'll demonstrate how we can add down-level servers to Server Manager, some the the problems we may encounter, and some troubleshooting.

First of all, we should be aware of some pre-requisites:

If we want to manage Windows 2008/R2 servers  from Windows 2012 R2, the down-level servers should have these pre-requisites installed:
  • .NET Framework 4.5
  • Windows Management Framework (WMF) 4.0

If we are using Windows 2012, we would install these versions on the down-level servers:
  • .NET Framework 4.0
  • Windows Management Framework (WMF) 3.0

If we want to use WinRM to manage the remote servers, we have to execute the following command on those servers:

winrm qc

or...

winrm quickconfig

I'll dissect what this command accomplishes by attempting to add a Windows 2008 R2 server to Server Manager without running it first.

In this test lab, we have:

  • DC10: the remote server running Windows 2008 R2
  • SVR1: the Windows 2012 R2 server with Server Manager.


It seems that we can add DC10 to Server Manager without a problem:






However, we have an error.



Let's troubleshoot this.

1. Server Manager uses WinRM. Is the WinRM service started?

PS C:\> get-service winrm | fl name,status

Name   : winrm
Status : Running



2. What about firewall rules?

WinRM access is governed by the "Windows Remote Management" rule. Get-NetFirewallRule does not seem to work with Windows 2008 R2 even though I have installed PowerShell version 4:

PS C:\> Get-NetFirewallRule
Get-NetFirewallRule : The term 'Get-NetFirewallRule' is not recognized as the name of a cmdlet, function, script file, or operable program.

PS C:\> $psversiontable

Name          Value
----          -----
PSVersion     4.0
[...]

So let's use the venerable NETSH command (click to enlarge):



No, the rule is not enabled.

We can enable the rule in the Windows Firewall console or with NETSH:

PS C:\> netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes

Updated 2 rule(s).
Ok.



Can we connect to DC10 now? No, the error persists:





3. Has a WinRM listener been configured?

Apparently not:

PS C:\> winrm enumerate winrm/config/listener
PS C:\>

Running the command "winrm qc" will configure all that needs to be configured for remote access. It would make sense to run it from the start. It is only to demonstrate with it accomplishes (and how we might troubleshoot) that I did not run it immediately in this example. Moreover, running the command summarizes what it does:

PS C:\> winrm qc

WinRM service is already running on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.

Make these changes [y/n]? y

WinRM has been updated for remote management.

Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.

Now if we run the same command as above, we see that a listener has been enabled:

PS C:\> winrm enumerate winrm/config/listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 172.16.0.10, ::1 [...]


Once we have completed all the steps above, we can manage the down-level target server with Server Manager.


Thursday, June 11, 2015

Windows Server 2012 R2 - Aspects of Remote Management - Windows Firewall

There are multiple methods to manage a remote server. Concerning Windows 2012 R2, I have enumerated the following (third party tools not included):

Command Line

  • WinRM (Windows Remote Management). This uses the winrs command on the client side.
  • PowerShell - Invoke-Command
  • Powershell - Enter-PSSession.


Graphic Interface (GUI)

  • MMC (Microsoft management console). This includes consoles available by default such as services.msc and eventvwr.msc as well as consoles available when we add a specfic server role, domain.msc or dsa.msc for Active Directory on a domain controller for example. Note: when we install these roles, the appropriate ports are opened for remote management. On the other hand, we must open ports manually for the MMCs like services.msc and eventvwr.msc.
  • Server Manager
  • Remote Desktop (RDP)

Concerning the MMC and server roles (DNS, DHCP, AD DS), we have to install RSAT on a workstation running what I will call the "client equivalent" of the server OS (or above), for example:
  • Windows Server 2012 R2 -> Windows 8.1
  • Windows Server 2012 -> Windows 8.0
  • Windows Server 2008 R2 -> Windows 7


In other words, we could not manage a Windows 2012 R2 server with Windows 7 RSAT (or with Windows 8.0).


On the other hand, we can connect to the Services or Event Viewer console of a Windows 2012 R2 server from a Windows 7 client.



Important distinction!

  • With the Microsoft management consoles (MMC), we use DCOM.
  • With Powershell and Server Manager, we use WinRM.

DCOM and WinRM require different ports to be opened on the Windows firewall.

On Windows Server 2012 R2, the WinRM ports are open by default, On the other hand, the DCOM ports are closed. However, as mentioned above, the installation of a specific server role may open certain ports.

Remote Desktop (RDP) requires both an open port in the Windows Firewall and a registry modification.

For reference, here are the ports associated with each of these options:

  • WinRM - 5985
  • DCOM - 135
  • RDP - 3389

Note: these are the basic default port assignments. Other ports may be opened dynamically as needed.


***


In the following lines, I'll attempt to manage a Windows 2012 R2 server from Windows 7 client machine.

  • SVR1 - the name of the Windows 2012 R2 server
  • PC1 - the name of the Windows client


Some notes:
  • All the commands function even though I am running an older version of PS on the Windows 7 client. Apparently, it is not necessary to have the same version.
  • We cannot manage Windows Server 2012 R2 from a Windows 7 client with RSAT or Server Manager. Therefore, these tools will not be presented. Why not use Windows 8.1? Many (most?) organizations have no plans to deploy Windows 8.x and will continue to use Windows 7 until they upgrade to Windows 10.
  • Both client and server are domain members. I am logged on with a domain administrator account.
  • Unless otherwise indicated, no changes have been made to the Windows firewall on either machine.


WinRM

By default, WinRM is enabled on Windows Server 2012 R2. I will illustrate this by executing a command on a fresh install of Windows 2012 R2 (SVR1) from the Windows 7 client (PC1):

PS C:\>hostname
PC1
PS C:\> winrs -r:SVR1 hostname
SVR1

Notice the syntax for winrs. After "winrs" itself, we designate the remote host (SVR1) and then the command we want to execute on the remote host (hostname).

If we look at the Windows Firewall (with Advanced Features) settings, we see that Windows Remote Management (WinRM) is enabled by default (click to enlarge):



At the command line, we can type:

PS C:\> Get-NetFirewallRule WINRM-HTTP-In-TCP* | fl Name,DisplayName,Enabled

Name        : WINRM-HTTP-In-TCP
DisplayName : Windows Remote Management (HTTP-In)
Enabled     : True

Name        : WINRM-HTTP-In-TCP-PUBLIC
DisplayName : Windows Remote Management (HTTP-In)
Enabled     : True

Note: the first rule is for the domain (and private) firewall profile and the second for the public profile.


So we do not need to run any of the following to enable winrm on Windows Server 2012 R2:

  • winrm quickconfig
  • winrm qc (abbreviated version of same command)

On the other hand, these commands could be useful on previous versions of Windows Server such as 2008 R2.


WinRM has one significant shortcoming. It will not execute PowerShell cmdlets. For example:

PS C:\> winrs -r:SVR1 Get-Service
'Get-Service' is not recognized as an internal or external command, operable program or batch file.'

So, if we want to run commands like hostname, ipconfig or netstat, we can use WinRM. If we want to execute Powershell cmdlets on a remote machine, we have two options: the Invoke-Command cmdlet and the Enter-PSSession cmdlet.



Invoke-Command

If we want to execute a single cmdlet on a remote machine (or a small number of cmdlets) we can use this combination:

PS C:\> hostname
PC1
PS C:\> Invoke-Command SVR1 -ScriptBlock {Get-Service | select -first 2 Name,Status}

Name               : AeLookupSvc
Status             : Stopped
PSComputerName     : svr1
RunspaceId         : 7f537985-3255-46b2-bc00-e119f89635e0
PSShowComputerName : True

Name               : ALG
Status             : Stopped
PSComputerName     : svr1
RunspaceId         : 7f537985-3255-46b2-bc00-e119f89635e0
PSShowComputerName : True


"hostname" shows that we are at the Windows 7 client (PC1) and "PSComputerName" (in the output) shows that the command executes remotely, on the Windows 2012 server (SVR1).

Note: the short version (alias) of Invoke-Command is icm.



Enter-PSSession

If we have many cmdlets to execute, it is more efficient to create a remote PowerShell session with the remote machine. Once this is established, we can execute cmdlets one after the other as if we were seated at the remote machine. I'll simply execute one cmdlet to illustrate:


PS C:\> hostname
PC1
PS C:\> Enter-PSSession SVR1
[svr1]: PS C:\Users\Admin\Documents> Test-WSMan

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0



Note: simply enter "exit" to quit the remote session.


MMC (Microsoft Management Consoles)

At this point, if we were proficient enough with PowerShell, we could manage the server at the command line. However, many if not most administrators will prefer to use the GUI at least some of the time.

We can manage a remote Windows 2012 R2 server with the usual .msc consoles. However, unlike PowerShell, which uses WinRM for remote management (and which is enabled by default on Windows 2012/R2), the MSCs use DCOM and this remote access for DCOM-based tools is not enabled by default.

For example, if we attempt to view Event Viewer on a remote server (in this example "HV1"), this is what happens:







We could enable appropriate settings at the console of the target machine in Server Manager.

But... if we have PowerShell access to the remote machine, can we enable remote administration remotely?

Yes we can!

In fact, we have at least two options.

We can enable "Windows Remote Firewall Management" so we can at least manage the Windows Firewall remotely (with the GUI), and then enable other MMCs or we can enable specific MMCs directly from the command line.

First, I would like to underline that by default, we cannot manage the Windows Firewall GUI remotely. We would have an error similar to the one with the Event Viewer console above:






Indeed, the rule for remote management of the Windows Firewall is not enabled (click to view larger image):



Note: this is a screenshot taken at the target server. At this point, precisely, I cannot yet see this screen from the Windows 7 client machine.

We could execute this command from the Windows 7 machine to view the current rule settings:

[SVR1]: PS C:\> Get-NetFirewallRule -Displaygroup "windows firewall remote management" | Select name,display*,enabled | fl

Name               : RemoteFwAdmin-In-TCP
DisplayName   : Windows Firewall Remote Management (RPC)
DisplayGroup  : Windows Firewall Remote Management
Enabled           : False

Name                : RemoteFwAdmin-RPCSS-In-TCP
DisplayName    : Windows Firewall Remote Management (RPC-EPMAP)
DisplayGroup   : Windows Firewall Remote Management
Enabled             : False


Note: in this case, I had created a remote Powershell session to execute the command. I could have also used the Invoke-Command option.

So, how can we enable the Windows Firewall Remote Management rule(s) remotely?

With the following PowerShell cmdlet:

[SVR1]: PS C:\> Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management"


We can verify the results at the command line...

[SVR1]: PS C:\> Get-NetFirewallRule -Displaygroup "windows firewall remote management" | Select name,display*,enabled | fl

Name               : RemoteFwAdmin-In-TCP
DisplayName   : Windows Firewall Remote Management (RPC)
DisplayGroup  : Windows Firewall Remote Management
Enabled           : True

Name                : RemoteFwAdmin-RPCSS-In-TCP
DisplayName    : Windows Firewall Remote Management (RPC-EPMAP)
DisplayGroup   : Windows Firewall Remote Management
Enabled             : True



Now, if we prefer, we can manage the Windows Firewall from the user-friendly GUI.

On the other hand, if we prefer the command line, we can enable firewall rules for specific elements, the Event Viewer console for example:

[SVR1]: PS C:\> Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management"

With the following results:

[SVR1]: PS C:\> Get-NetFirewallRule -Displaygroup "remote event log management" | Select name,display*,enabled | fl

Name         : RemoteEventLogSvc-In-TCP
DisplayName  : Remote Event Log Management (RPC)
DisplayGroup : Remote Event Log Management
Enabled      : True

Name         : RemoteEventLogSvc-NP-In-TCP
DisplayName  : Remote Event Log Management (NP-In)
DisplayGroup : Remote Event Log Management
Enabled      : True

Name         : RemoteEventLogSvc-RPCSS-In-TCP
DisplayName  : Remote Event Log Management (RPC-EPMAP)
DisplayGroup : Remote Event Log Management
Enabled      : True


There is supposedly a command that will enable all remote management options but it seems deprecated in Windows Server 2012 R2:

[SVR1]: PS C:\> Enable-NetFirewallRule -DisplayGroup "Remote Adminstration"
Enable-NetFirewallRule : No MSFT_NetFirewallRule objects found with property 'DisplayGroup' equal to 'Remote Adminstration'.  Verify the value of the property and retry.

The legacy command line tool for Windows Firewall, NETSH, did not succeed either:

[SVR1]: PS C:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

No rules match the specified criteria.


In the screenshot below, you can see for yourself:




***

At this point, we can manage the remote server with the management consoles (Services, Event Viewer, etc.).

If we were using Windows 8.1, we could install RSAT and manage roles such as Active Directory Domain Services (ADDS), DNS, DHCP and more. However, we cannot manage Windows Server 2012 R2 with the Windows 7 RSAT.

If we were at another server, we could add the target server to Server Manager and manage it remotely using this tool. 



Remote Desktop (RDP)

This is the last option I will examine. It is notable in that enabling the appropriate firewall rule(s) does not suffice.

We enable the Remote Desktop firewall rule like this:

[SVR1]: PS C:\> Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

We confirm that the rule has been enabled (in fact, there are several related rules):

[SVR1]: PS C:\> Get-NetFirewallRule -Displaygroup "Remote Desktop" | select name,display*,enabled | fl

Name         : RemoteDesktop-UserMode-In-TCP
DisplayName  : Remote Desktop - User Mode (TCP-In)
DisplayGroup : Remote Desktop
Enabled      : True

Name         : RemoteDesktop-UserMode-In-UDP
DisplayName  : Remote Desktop - User Mode (UDP-In)
DisplayGroup : Remote Desktop
Enabled      : True

Name         : RemoteDesktop-Shadow-In-TCP
DisplayName  : Remote Desktop - Shadow (TCP-In)
DisplayGroup : Remote Desktop
Enabled      : True


However, when we attempt to connect, the connection fails:




We need to consult the following registry key:

[SVR1]: PS C:\> Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server" -name "fDenyTSConnections" | fl fDeny*

fDenyTSConnections : 1


Currently "TSConnections" (Terminal Service connections - the former name for Remote Desktop) are denied.

So we must adjust the value to "0" (zero):

[SVR1]: PS C:\> Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server" -name "fDenyTSConnections" -value 0


Now we should be able to connect with Remote Desktop.