What’s New in Windows Server 2012 Remote Access (Part 2)

by [Published on 4 Oct. 2012 / Last Updated on 4 Oct. 2012]

This article completes the discussion we started in Part 1, and then talks about the implications of the new features.

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the first part in this article series please go to What’s New in Windows Server 2012 Remote Access (Part 1).

Introduction

With the recent announcement about the discontinuation of the TMG firewall, the topic of Windows Server 2012 networking has become even more interesting to TMG firewall admins and Windows Network admins of all stripes. For a long time, the TMG firewall (like ISA Server before it) was a cornerstone of Windows Networking and provided the security and the flexibility you needed to make sure your remote access solution worked securely and reliably. Now that we know the TMG firewall will eventually be relegated to the dustbin of history (after extended support ends in 2020), it’s time to start thinking more about what the Windows platform itself has to offer you when it comes to remote access.

As you saw in Part 1 of this article series, the focus for remote access in the Windows Server 2012 era is the new unified remote access solution, which includes support for remote access VPN client connections, site to site VPN connections and DirectAccess. Let’ complete the discussion we started in Part 1, and then talk about the implications of the new features.

Multisite support

If you worked with the UAG DirectAccess solution, you know that one of the most difficult scenarios is the one that involves multiple sites. Standing up a single UAG DirectAccess server is relatively easy if you have all the pieces in place in advance to make sure that when you do set up the UAG DirectAccess server or array it will be able to consume all the supporting services. The problems start when you try to set up two or more arrays at different sites. There are a number of reasons for this: problems with group policy configuration, DNS issues, and IPv6 problems. Tom put together a solution that would enable you to stand up a two-site UAG DirectAccess solution a couple of years ago and was in the process of completing a proof of concept setup, but he was moved to another team within Microsoft and never was able to finish that work. However, Microsoft realized that enabling multi-site connectivity for DirectAccess was a key enterprise requirement, so in Windows Server 2012, there is now full support for multi-site DirectAccess deployments.

In Windows Server 2012, you can configure DirectAccess so that Windows 8 clients will be able to discover the closest DirectAccess server or array and connect to that. Or, you can configure the clients to use a preferred DirectAccess server or array or you can let your users choose which DirectAccess server or array to use. For Windows 7 clients, you don’t have this level of automation or flexibility, but users can still benefit from many of the same connectivity advantages if you choose to deploy an external Global Server Load Balancing Solution. However, this is something you will need to configure outside of Windows, since Windows Server 2012 itself doesn’t provide this feature.

Support for Server Core

If you’ve worked with server core in the Windows Server 2008 R2 era, you probably think that you'd prefer almost any onerous task to working with a Server Core deployment. It was clear that Microsoft had not fully worked out the configuration issues when working with Server Core in the past, but it looks as if, with Windows Server 2012, the Server Core deployment is now actually manageable from a remote management workstation. The new RSAT tools and the Server Manager application that comes with Windows Server 2012 make it possible to relatively easily manage machines that are running services on a Server Core installation of Windows Server 2012.

There are a lot of advantages to running your DirectAccess servers using Server Core. The attack surface is much lower and you don’t need to update the servers nearly as often. These are both great advantages when you need to provide a highly available service, such as the DirectAccess remote access solution. You can manage DirectAccess using remote PowerShell commands or you can use the new and improved Server Manager. Another nice thing about using a Server Core installation is that you can have more confidence in putting the Windows Server 2012 DirectAccess server at the edge of the network, even if you no longer have to do that as you did with the UAG DirectAccess solution.

Windows PowerShell support

Love it or hate it, PowerShell is here to stay. There are a number of reasons that Microsoft is making such a large investment in PowerShell and so if you want to continue being a Microsoft administrator, you’ll probably have to learn at least some PowerShell eventually. Thus, the new DirectAccess solution in Windows Server 2012 includes full support for PowerShell, so that you will be able to do whatever it is that people do with PowerShell :).

User monitoring

All remote access solutions must support robust monitoring of who is connecting to the network and what they’re doing while they’re there. While the Windows Server 2012 iteration of DirectAccess doesn’t provide nearly the level of detail you are able to get with the TMG firewall, it does have a much better level of monitoring than you could get with the UAG DirectAccess solution.

In Windows Server 2012, there is a new monitoring console that provides you with a great deal of useful information about the users who are connecting through the DirectAccess connection. The following is a list of what is exposed in the monitoring console, which is information that is obtained from Performance Monitor counters:

  • Total number of active remote clients connected: this includes both DirectAccess and VPN remote clients. It lets you know how many concurrent connections there are for both DirectAccess and VPN connections, which is helpful in determining what your max is going to be, given your level of hardware.
  • Total number of active DirectAccess clients connected: this shows only the total number of clients connected using DirectAccess. This is good if you want to know only who’s connected via DirectAccess.
  • Total number of active VPN clients connected: This shows only the total number of clients connected using a VPN. As with the previous counter, this is good if you want to know only the VPN connections.
  • Total unique users connected: This includes both DirectAccess and VPN users, based on the active connections. I'm not sure how this is different from the total number of remote access clients connected. Maybe a single user who has more than one connection is not considered unique.
  • Total number of cumulative connections: This shows the total number of connections that have been serviced by the Remote Access Server since the last server restart. This might be useful for reporting purposes or maybe for MCSE cocktail parties, when you want to brag about how many connections you supported before having to restart :).
  • Maximum number of remote clients connected: This shows the maximum number of concurrent remote users connected to the Remote Access Server since the last server restart. This is useful information for determining whether you can increase the number by adding more clients to the server or array in an attempt to make it topple over.
  • Total data transferred: This is the total amount of inbound and outbound traffic passing through the Remote Access Server for both DirectAccess and VPN since the last server restart. It's interesting information, especially if you have a metered bandwidth service and need to figure out trends in usage so that you can plan for upgrading your ISP service.
  1. Inbound traffic – Total bytes/traffic into the remote access server/gateway
  2. Outbound traffic – Total bytes/traffic out of the remote access server/gateway

You can find information on individual users and discover what resources they’re trying to connect to on the internal network. You can also filter the list of connected users so that you can easily find the one(s) that you’re interested in. In addition, you can filter on one more of the following fields:

Field Name

Value

Username

The user name or alias of the remote user. Wildcards may be used to specify a group of users.

Hostname

The computer account name of the remote user. An IPv4 or IPv6 address can be specified as well.

Type

Either DirectAccess or VPN. If DirectAccess is selected, then all remote users connecting using DirectAccess are listed. If VPN is selected, then all remote users connecting using VPN are listed.

ISP address

The IPv4 or IPv6 address of the remote user

IPv4 address

The inner IPv4 address of the tunnel connecting the remote user to the corporate network

IPv6 address

The inner IPv6 address of the tunnel connecting the remote user to the corporate network

Protocol/Tunnel

The IPv6 transition technology used by the remote client, i.e., Teredo, 6to4 or IP-HTTPS in case of DirectAccess users, and PPTP, L2TP, SSTP or IKEv2 in case of VPN users

Resource Accessed

All users accessing a particular corporate resource or an endpoint. The value corresponding to this field is the hostname/IP address of the server/endpoint

Server

The Remote Access server to which clients are connected. This is relevant only for cluster and multisite deployments.

Table 1

Server monitoring

If you’ve worked with DirectAccess in the past, you know that there are a number of services and technologies that comprise the entire working solution. You also know that it’s hard to keep track of all of them! In Windows Server 2012, there is a server and service monitor console that helps you figure out whether everything is as it should be, and if it’s not, it tries to tell you what is wrong.

In Windows Server 2012, there are status monitors for the following services:

  • 6to4
  • DNS
  • DNS64
  • Domain controller
  • IP-HTTPS
  • IPsec
  • ISATAP
  • Kerberos
  • Management Servers
  • NAT64
  • Network Adapters
  • Network Location Server
  • Network Security (IPsec DoSP)
  • Services
  • Teredo
  • Load Balancing
  • VPN addressing
  • VPN connectivity

Diagnostics

Troubleshooting DirectAccess has always been both an art and a science. The art came from needing the experience with DirectAccess in order to really understand where to start when it came to troubleshooting. Now with Windows Server 2012, we have new capabilities that will make troubleshooting easier. These include:

  • Detailed event logging for DirectAccess
  • Improved tracing and packet capture using a single click
  • Log correlation, which makes it easier to interpret events in the trace file
  • Flexible viewing options for logs

Site-to-site IKEv2 IPsec tunnel mode VPN

Support for IKEv2 on site to site VPNs is now available. This was available for remote access VPN client connections in the past and has now been extended to site to site VPN connectivity.

Summary

Windows Server 2012 includes a number of new improvements to the routing and remote access service that will make DirectAccess easier than ever to deploy and make it easy to integrate DirectAccess and traditional VPN connectivity so that both modern and legacy Windows and non-Windows clients can connect to the corporate network. In a future article, we’ll do some cool step by step Test Lab Guide configurations to show you how you can get your new remote access configurations working! See you then –Deb.

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the first part in this article series please go to What’s New in Windows Server 2012 Remote Access (Part 1).

Featured Links