Export (0) Print
Expand All
2 out of 2 rated this helpful - Rate this topic

Remote Access (DirectAccess) Unsupported Configurations

Updated: September 9, 2013

Applies To: Windows Server 2012 R2

Review the following list of unsupported DirectAccess configurations before you start your deployment to avoid having to start your deployment again.

Network Access Protection (NAP) is used to determine whether remote client computers meet IT policies before they are granted access to the corporate network. NAP was deprecated in Windows Server 2012 R2. This means that NAP may not be supported in future versions of Windows. For this reason, starting a new deployment of DirectAccess with NAP is not recommended. A different method of end point control for the security of DirectAccess clients is recommended.

When DirectAccess is configured in a multisite deployment, Windows 8 and Windows 8.1 clients have the capability of connecting to the nearest site. Windows 7 client computers do not have the same capability. Site selection for Windows 7 clients is set to a particular site at the time of policy configuration, and these clients will always connect to that designated site, regardless of their location.

DirectAccess policies are computer based, not user based. Specifying DirectAccess user policies to control access to the corporate network is not supported.

DirectAccess can be configured by using the DirectAccess Setup Wizard, the Remote Access Management console, or the Remote Access Windows PowerShell cmdlets. Using any means other than the DirectAccess Setup Wizard to configure DirectAccess, such as modifying DirectAccess Group Policy Objects directly or manually modifying the default policy settings on the server or client, is not supported. These modifications may result in an unusable configuration.

When a DirectAccess server is configured with the Getting Started Wizard, the server uses KerbProxy authentication for computer and user authentication. As such, the Getting Started Wizard should be used only for single-site deployments that run only Windows 8 or Windows 8.1 clients. Consider the following issues when you are planning to configure DirectAccess:

The following features should not be used with KerbProxy authentication:

  • Load balancing (by using an external load balancer or Windows Load Balancer)

  • Two-factor authentication where smart cards or a one-time password are needed in the deployment

The following deployment plans are not supported if you configure KerbProxy authentication:

  • Multisite

  • Force tunneling

  • DirectAccess support for Windows 7 clients

For the previous deployments, you should use the Advanced Configuration Wizard, which uses a two-tunnel configuration with a certificate-based computer and user authentication. For more information, see Deploy a Single Remote Access Server with Advanced Settings.

ISATAP is a transition technology that provides IPv6 connectivity in IPv4-only corporate networks. It is limited to small- and medium-sized organizations with a single DirectAccess server deployment, and it allows remote management of DirectAccess clients. If ISATAP is deployedin a multisite, load balancing, or multidomain environment, you must remove it or move it to a native IPv6 deployment before you configure DirectAccess.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2014 Microsoft. All rights reserved.