Beginning with Windows Server 2012, the core installation mode is now the default and preferred installation mode. For workloads that are supported on Windows Server core, which includes the remote access role and DirectAccess, server core should be used to provide the highest levels of security and availability.

When installing Windows Server 2012/R2 core, the operating system defaults to using the old DOS command prompt. I find this particularly annoying since the majority of administration I do on a server core installation is in PowerShell. Also, most DOS commands can be run from the PowerShell console anyway, so why not have PowerShell as the default shell? Well, that’s easy enough to fix. To begin, at the command prompt enter start powershell.

Are you interested in learning about Microsoft DirectAccess, the always-on, seamless and transparent remote access feature in Windows Server 2012? Then join me on Thursday, October 3, 2013 for a webinar where I’ll describe in detail what DirectAccess is, how it functions, what the benefits are for deploying DirectAccess in terms of security and ease of use, and much more. I’ll also provide you with information about how Iron Networks can assist you with deploying DirectAccess quickly and effectively by leveraging our advanced hardware appliance platform and professional services. You can register for the webinar here.

Nothing! That’s right, there are no new features or functionality included with DirectAccess in Windows Server 2012 R2. Just a few bug fixes and some small cosmetic changes in the management console. Carry on! 😉

From a client perspective, DirectAccess is an IPv6-only solution and requires IPv6 connectivity end to end. To enable the solution to work on IPv4-only networks, DirectAccess makes use of one of several IPv6 transition technologies – 6to4, Teredo, or IP-HTTPS. By leveraging these IPv6 transition technologies, a DirectAccess client can communicate with the DirectAccess server when they are both connected to the public IPv4 Internet, which is the most common deployment scenario today.

The first two IPv6 transition technologies, 6to4 and Teredo, both require that the DirectAccess server be directly connected to the public Internet. Beginning with Windows Server 2012, placing the DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is now supported. However, in this deployment model only the IP-HTTPS IPv6 transition protocol can be utilized. In this scenario, it is recommended to disable the unused IPv6 transition protocols to prevent potential connectivity issues. You can disable them on a per-host basis using PowerShell, which is fine for individual client testing purposes, or globally using Active Directory Group Policy Objects (GPOs), which is recommend for enterprise-wide production deployment.

To disable unused IPv6 transition protocols on a per-host basis on Windows 8 clients using PowerShell, open an elevated PowerShell prompt and execute the following commands:

To disable unused IPv6 transition protocols on a per-host basis on Windows 7 client using netsh, open an elevated command prompt and execute the following commands:

netsh interface 6to4 set state disabled
netsh interface teredo set state disabled
netsh interface isatap set state disabled

To disable unused IPv6 transition protocols using Active Directory GPO, open the Group Policy Management Console (GPMC) and create a new GPO. Edit the GPO by navigating to Computer Configuration / Policies / Administrative Templates / Network / TCP/IP Settings / IPv6 Transition. Double-click Set 6to4 State and enable the policy, then select Disabled State from the list of states. Repeat these steps for Teredo and ISATAP.

Change the security filtering for the GPO and specify the security group for your DirectAccess clients. Once complete, link the new GPO to the domain.

As a reminder, the steps above are for disabling unused IPv6 transition protocols in a deployment scenario where the DirectAccess server is running Windows Server 2012/R2 and is deployed behind a NAT device. If your DirectAccess server is connected directly to the public Internet, disabling these IPv6 transition protocols is not required.

With the August security update release cycle, Microsoft issued security bulletin MS13-064 to address a vulnerability in the Windows NAT driver that could result in a denial of service. The vulnerability could be exploited by an attacker who sends a specially crafted ICMP packet to the server running the Windows NAT Driver service. The vulnerability exists only on Windows Server 2012 and the affected driver, winnat.sys, is present when the DirectAccess role is installed. This vulnerability only affects only full installations of Windows Server 2012. Windows Server 2012 Core is not affected. If you are running DirectAccess on a full installation of Windows Server 2012, make sure you install this update as soon as possible to be protected from potential denial of service attacks. For more information about this update, click here. For a comprehensive list of updates that apply to DirectAccess on Windows Server 2012 as well as previous versions, please refer to Jason Jones’ DirectAccess hotfix summary page.

Microsoft recently announced the availability of Windows 8.1 Enterprise preview. If you’ve downloaded the software to evaluate DirectAccess, you may be wondering where the DirectAccess connection properties have gone. In Windows 8, the DirectAccess connection properties can be accessed by pressing Window Key + I, clicking the active network icon, and then right-clicking Workplace Connection.

DirectAccess requires computer certificates to be installed on the DirectAccess server and DirectAccess clients. These certificates are used for IPsec, which provides a secure, encrypted communication channel between the DirectAccess client and the DirectAccess server. IPsec ensures the necessary integrity, confidentiality, and non-repudiation required for secure remote access. When using a Public Key Infrastructure (PKI) to issue computer certificates to DirectAccess clients, it can be helpful to automate this process by configuring certificate auto-enrollment using Active Directory group policy.

To begin, open the Group Policy Management Console and expand Domains. Next, expand your domain, right-click Group Policy Objects and choose New. Enter a descriptive name for the new GPO and click Ok. Right-click the GPO you just created and choose Edit. Expand Computer Configuration, Windows Settings, Security Settings, and Public Key Policies. Highlight Public Key Policies, and then double-click Certificate Services Client – Auto-Enrollment. For the Configuration Model choose Enabled. It is recommended that you also choose to Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

Close out of the Group Policy Editor and then link this computer certificate auto-enrollment GPO to your domain. Target only DirectAccess client and server security groups with this GPO instead of all domain computers by configuring Security Filtering to apply this GPO only to DirectAccess client and server machines.

Finally, on your certificate server, right-click the DirectAccess certificate template, choose Properties, and then choose Security. Make certain the Enroll and Autoenroll permissions are set to Allow for all DirectAccess client and server security groups.

After configuring a Windows Server 2012 DirectAccess server to use an intranet-based Network Location Server (NLS), you may notice that the operations status in the remote access management console indicates a critical problem with NLS, when in fact you can browse the NLS server from the DirectAccess server.

The issue here is that the DirectAccess server, in addition to being able to successfully connect to the NLS using an HTTP GET, must also be able to ping the NLS server. However, inbound ICMP is often blocked on web servers which results in the DirectAccess server marking the service as failed. The issue can be quickly resolved by modifying the host firewall policy to allow inbound ICMPv4 echo requests. For example, in my test lab I’m using a Microsoft Windows Server 2012 server with Internet Information Services (IIS) installed. A new access rule can be added to the Windows Firewall with Advanced Security (WFAS) by executing the following PowerShell command:

Note that my lab server is domain joined, so I’ve specified the WFAS profile to be the Domain profile. In addition I’ve included the IPv4 addresses assigned to the internal network interfaces of my two DirectAccess servers. You’ll need change the command as required to work in your environment.