Windows Server 2012 Direct Access Part 2–How to Build a Test Lab

Here is the second part of Windows Server 2012 Direct Access blog series.


In the first post we discussed what’s new and what are the design differences between new and previous version of Direct Access feature.

In this blog post, we’ll discuss about our Lab configuration that will lead us for the next parts and help us to design and test Direct Access feature within virtual environment.

To build a reliable Direct Access Lab, Microsoft provides Base and Test Lab guide documentations.

Base Lab:

Test Lab:

Regarding base lab guide, you can build a base lab that includes Infrastructure servers (DNS, Active Directory), Application Server (Intranet IIS Site), Simulated Internet (DNS Server) and single Direct Access Server.

After you build base virtual machines, then you should follow Test Lab guide and configure&test Direct Access feature.

Let’s look at the lab details and introduce virtual machines & roles.


– First of all you must build a Domain Controller as an intranet domain controller, DNS Server and DHCP server. This server will be responsible for authentication purposes and will act as main identity store for the Lab environment. Also a DNS server is a must to built a healthy Active Directory environment. DHCP is another role that you have to install. It will be used to configure Client1’s ip address automatically. Since you will change Client1 subnet frequently during test processes, providing ip addresses automatically will help us.

– One intranet member server running Windows Server 2012 named APP1. It will be configured as a general application and web server. When a client resides on internet network and successfully connects intranet network through IPSEC tunnel (Direct Access Server), to test Direct Access client side functionalities, being able to access real intranet resources will be more helpful test. On application server, a file share and an intranet IIS web site will be created.

– One member client computer running Windows 8 Consumer Preview named Clinet1. You will use that client machine for testing purposes. I recommend that put three network interface to try for internet, intranet and behind NAT communications.

– One intranet member server running Windows Server 2012 named EDGE1. That will be our Direct Access Server. Most important point is that it should have two different network cards to access both intranet and internet networks. This server also will act as a DNS64. That means it will get DNS ipv6 requests from Windows 8 clients that resided in Internet and make ipv4 DNS requests to the intranet DNS server on behalf of DA clients.

– And the last required server for base lab is INET1. It’s required to simulate internet network. You will have to create DNS zones to answer DNS queries from internet clients.

I’m sure if you want to build that lab, you will download base and test lab and follow the steps. So I will only highlight for the important steps that is also covered basically within documents.

– Since this is a limited Lab environment, you can minimize hardware requirements. 1024Gb ram will be enough for each VM.

– Unlike previous Windows 7 Direct Access Test lab guide, this guide includes PowerShell script for each step. You do not have to follow 15-20 steps one by one. Just copy PowerShell script provided and run within elevated PowerShell console.


After you complete Base Lab Guide and before to start Test Lab Guide, if you want to test Direct Access functionality behind a NAT device, you also have to build following HomeNet Lab.

Optional mini-module- Homenet subnet

It’s an optional step and will help you to fire up one another Windows 8 virtual machine that will act as a NAT device.

Before you start to install Direct Access Feature and test connectivity, you must have following environment:


I know it seems a little bit crowded, but once you build that kind of virtual lab, you can also use it to test other new Windows Server 8 features.

Next part we will assume that you have a working Lab environment and will start to install and configure Direct Access feature.

Windows Server 2012 Direct Access Part 1 What’s New

Direct Access feature was introduced with Windows Server 2008 R2 and Windows 7 Client computers. Direct Access overcomes the limitations of VPNs by automatically establishing a bi-directional connection from client computers to the corporate network so users never have to think about connecting to the enterprise network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.

In this blog post series I’ll cover Direct Access Feature in Windows Server 2012 and design a complex Windows Server 2012 lab to implement Direct Access feature. In my next post I will outline the lab requirements and design considerations. With 3rd post we will be able to install direct access feature and then cover details and troubleshooting steps.

In this first post, let’s look at the Direct Access feature on Windows 7 /2008 R2 and compare with Windows Server 2012.

Direct Access feature in Windows Server 2008 R2 had following goals for organizations;

  • Direct Access enhances the productivity of mobile workers by connecting their computers automatically and seamlessly to their intranet any time Internet access is available
  • With Direct Access, IT staff can manage mobile computers by updating Group Policy settings and distributing software updates any time the mobile computer has Internet connectivity
  • Direct Access separates intranet from Internet traffic.
  • When an application on a Direct Access client attempts to resolve a name, it first compares the name with the rules in the NRPT (Name Resolution Policy Table )      If there are no matches, the Direct Access client uses Internet DNS servers to resolve the name

From connectivity perspective;

Direct Access clients create two tunnels to the Direct Access server. The first tunnel, the infrastructure tunnel, provides access to intranet Domain Name System (DNS) servers, Active Directory Domain Services (AD DS) domain controllers, and other infrastructure and management servers. The second tunnel, the intranet tunnel, provides access to intranet resources such as Web sites, file shares, and other application servers.

Direct Access feature relies on IPv6 network infrastructure. For those who have not a native IPv6 network infrastructure, ISATAP can be used to make intranet servers and applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Computers running Windows 7 or Windows Server 2008 R2 support ISATAP host functionality.

To configure ISATAP you have to put ISATAP host ( A ) record in your DNS and all machines can then resolve this name to configure their ISATAP adapters.

By default, Windows 2003 SP2 and above DNS servers do not answer queries for the names WPAD and ISATAP. That means you will need to enable queries for the ISATAP name on these servers.

Here is a simple diagram that shows how direct access feature works on Windows Server 2008 R2;


Notice that the Direct Access client establishes two IPsec tunnels:
IPsec Encapsulating Security Payload (ESP) tunnel with IP-TLS (Transport Layer Security) encryption using the machine certificate. This tunnel provides access to the DNS server and domain controller, allowing the computer to download Group Policy objects and to request authentication on the user’s behalf.
IPsec ESP tunnel with IP-TLS encryption using both the machine certificate and user credentials. This tunnel authenticates the user and provides access to internal resources and application servers. For example, this tunnel would need to be established before Microsoft Outlook could download e-mail from the internal Microsoft Exchange Server.

Also Direct Access servers running Windows Server 2008 R2 requires two network adapters, one that is connected directly to the Internet and one that is connected to the intranet. Also this server should have two consecutive and public IPv4 addresses.

One another major challenges for IT administrators to deploy Direct Access in Windows Server 2008 R2 was the need of a PKI environment to issue computer certificates.

And if you have not Forefront UAG, an optional NAT64 device is a requirement to provide access to IPv4-only resources for Direct Access clients.


As you noticed with above complex requirements, implementing Direct Access feature was not a easy task for IT Departments.

Direct Access feature has been designed again with Windows Server 2012 and now  addresses better connectivity with better manageability.

In brief, Windows Server 2012 includes following improvements over Windows Server 2008 Direct Access and RRAS features;

  • Direct Access and RRAS coexistence

In Windows Server 2008 R2, combining RRAS and Direct Access might cause some conflicts for the remote client connectivity. Since Direct Access relies on IPv6 and RRAS implements IKEv2 IPSEC, this results in Direct Access traffic being blocked if RRAS is installed and VPN access is deployed with IKEv2. Now in Window Server 2012, Direct Access and RRAS are combined within a new unified server role.

  • Simplified Direct Access management for small and medium organization administrators

One of the most important simplicity in Windows Server 2012 is removal of the need for a full PKI deployment. As you know that one major deployment blocker for Windows 7 Direct Access is the requirement of a Public Key Infrastructure (PKI) for server and client certificate-based authentication. Now in Windows Server 2012, client authentication requests are sent to a Kerberos proxy service running on the DA server. Then Kerberos proxy sends requests to domain controllers on behalf of the client.

And also new getting started wizard which will be covered on next posts allows for an automated setup in a few simple steps.

  • Built-in NAT64 and DNS64 support for accessing IPv4-only resources

In Windows Server 2008 R2, UAG might be used for NAT64 and DNS64 translations;


Now Windows Server 2012 Direct Access server includes native support for NAT64 and DNS64 translations that convert IPv6 communication from the client to IPv4 internal resources.

  • Support for Direct Access server behind a NAT device

The Teredo IPv6 transition technology is used typically when the client system is assigned a private IP address (and for modern Windows clients, will be used when the client is assigned a public IP address and 6to4 isn’t available). A Windows Serv

er 2008 R2 Direct Access server requires two network interfaces with two consecutive public IPv4 addresses assigned to the external interface. This is required so that it can act as a Teredo server.

Now in Windows Server 2012 direct access server can be deployed behind a NAT device with support for only one single network interface and removes the public IPv4 address prerequisite.

  • Load balancing support

One of the most important  enhancement is the chance to design a fully high available direct access solution. Now in Windows Server 2012, Direct Access has  built-in Windows Network Load Balancing support to achieve high availability and scalability. And this configuration can be configured within new deployment wizard interface with a couple of clicks.

  • Support for multiple domains

Now you can configure Direct access server to allow remote clients located in different domains.

  • Support for OTP (token based authentication)

For organizations that needs a security level with OTP vendor solutions such as RSA SecurID, Windows Server 2012 supports two factor authentication with smart cards or OTP token based solutions.

  • Automated support for force tunneling


By default only specific network traffic (defined by DNS records) will go through direct access tunnel. But if you want to route all traffic from client computer to the intranet resources over Direct Access tunnel, you can configure it with Force Tunneling.

Force tunneling is a feature in Windows Server 2008 R2 that forces all network traffic to be routed over Direct Access IPSEC tunnel. But it requires manual steps to enable via group policy. In Windows Server 2012, direct access has integrated force tunneling with the setup wizard.

  • Multisite support

Now in Windows Server 2012, you can configure multiple Direct Access  entry points across remote locations. This makes sure the client locates the closest IP-HTTPS server, Teredo Server, DNS Server etc. regardless of their physical location.

  • Windows PowerShell support

Direct Access in Windows Server 2008 R2 lacks a complete scripting and command line interface for configuration options. Windows Server 2012 provides full Windows PowerShell support for the setup, configuration, management, monitoring and troubleshooting of the Remote Access Server Role.

  • User and server health monitoring

The Monitoring Dashboard shows a summary of remote client connectivity status for the following items. The information is generated from the relevant Performance Monitor counters and accounting data.

  • Total number of active remote clients connected – includes both Direct Access and VPN remote clients
  • Total number of active Direct Access clients connected – only the total number of clients connected using Direct Access
  • Total number of active VPN clients connected – only the total number of clients connected using VPN
  • Total unique users connected – includes both Direct Access and VPN users, based on the active connections
  • Total number of cumulative sessions – the total number of connections serviced by the Remote Access Server since the last server restart
  • Maximum number of remote clients connected – the maximum concurrent remote users connected to the Remote Access Server since the last server restart
  • Total data transferred – the total inbound and outbound traffic from the Remote Access Server for both Direct Access and VPN since the last server restart

With the above enhancements, it’s now much easier to implement this great remote access feature in your organization.

In second blog post of this series, I will discuss to design a Windows Server 2012 Direct Access lab that will guide us for next posts.

PowerShell 3.0 – Shell from Future

PowerShell 3.0 is shipped with Windows 8. We are still experiencing some of the great features of Windows Server 8, but PowerShell 3.0 also brings many new features. Thanks to PowerShell Product Team for such a great innovation.

In this blog post, I will discuss about some of simplified syntaxes.

PowerShell Integrated Script Environment has an improved UI design and features.


This is new designed PowerShell ISE console.

Right pane you’ll notice Commands section.


As you know, in PowerShell V2 you have to query available commands or syntax with get-help or Tab button.

In PowerShell 3.0 you can search any kind of command within Commands pane. I searched for commands that includes “printer” and it outputs all available commands.

And also it provides me all required or optional parameters for selected command.

Now i can select Get-Printer cmdlet and fill up mandatory or optional params.


Now just click copy and paste into script pane.


This is a great feature especially for those who don’t like much writing or remembering script syntax.

Another great feature is improved Tab button Smile Now it completes automatically for all kind of parameter, argument etc. within a window.

In below example, I just write Get-Pro and press tab. It brings all available commands that start with Get-Pro


It also brings parameters and arguments.


And finally it gets to you all available processes on your system lively !


Another example of argument auto completion:


Auto completion also works for .Net. If you call [System.Net.DNS] it will bring you all available methods.


Error notification is also available lively.


I think one of the greatest features of PowerShell 3.0 is statement help.

If you press CTRL + J, it will bring you all statements with their usage and examples.


But this is not enough.

Just click one of the statements and then it will paste a template usage example into your Script Pane.


This is a great feature cause I believe many system administrators don’t want to remember usage of each statement. They don’t need any more.

With PowerShell 3.0, you don’t need special $_. Character to filter script outputs.

Below is a simple example in PowerShell 2.0 to get a process that has a name “IDLE”. For complex scripts it is open for mistakes.


In PowerShell 3.0 just put a pipe and write only column name with no special character. It works and looks great.


It’s same for foreach too.


This is a brief post about PowerShell 3.0 features. There are bunch of great features and we will figure out them in our next blogs.