Exporteren (0) Afdrukken
Alles uitvouwen
Deze inhoud is niet beschikbaar in uw taal, maar wel in het Engels.
30 van 48 hebben dit beoordeeld als nuttig - Dit onderwerp beoordelen

Remote Access (DirectAccess, Routing and Remote Access) Overview

Published: February 29, 2012

Updated: March 1, 2012

Applies To: Windows Server 2012, Windows Server 2012 R2

This topic contains an overview of the Remote Access technology in Windows Server 2012, its new and changed functionality, and links to additional resources.

Home RA Map

Remote Access combines two networking services into one unified server role in Windows Server 2012.

Windows Server 2008 R2 introduced DirectAccess, a new remote access feature that allows connectivity to corporate network resources without the need for traditional Virtual Private Network (VPN) connections. DirectAccess provides support only for domain-joined Windows 7 Enterprise and Ultimate edition clients. The Windows Routing and Remote Access Server (RRAS) provides traditional VPN connectivity for legacy clients, non-domain joined clients, and third party VPN clients. RRAS also provides site-to-site connections between servers. RRAS in Windows Server 2008 R2 cannot coexist on the same edge server with DirectAccess, and must be deployed and managed separately from DirectAccess.

In Windows Server 2012 the DirectAccess feature and the RRAS role service were combined into a new unified server role. This new Remote Access server role allows for centralized administration, configuration, and monitoring of both DirectAccess and VPN-based remote access services. Additionally, Windows Server 2012 DirectAccess provided multiple updates and improvements to address deployment blockers and provide simplified management.

DirectAccess is also available in Windows Server 2012 Essentials, and likewise enables seamless connectivity to your organization’s network from any Internet-equipped remote location without having to establish a virtual private network (VPN) connection.

To learn more about DirectAccess in Windows Server 2012 Essentials, see Configure DirectAccess in Windows Server 2012 Essentials.

The unified server role for DirectAccess and RRAS provides a single point of configuration and management for remote access server deployment. Windows Server 2012 and Windows Server 2012 R2 includes the following improvements over Windows 7 DirectAccess and RRAS.

  • DirectAccess and RRAS coexistence

  • Simplified DirectAccess Deployment

  • Removal of public key infrastructure (PKI) deployment as a DirectAccess prerequisite

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

  • Support for DirectAccess server behind a NAT device

  • Simplified network security policy

  • Load balancing support

  • Support for multiple domains

  • Support for OTP (token based authentication)

  • Automated support for force tunneling

  • IP-HTTPS interoperability and performance improvements

  • DirectAccess manage-out to clients support

  • Multisite support

  • Support for Server Core

  • Windows PowerShell support

  • User monitoring

  • Server operations status

  • Diagnostics

  • Accounting and reporting

  • Site-to-site IKEv2 IPsec tunnel mode VPN

Both DirectAccess and RRAS implement security features to protect the server from hostile inbound traffic. Previously these security feature settings conflicted with each other if both services attempt to run on the same server, preventing either DirectAccess or RRAS from functioning as expected.

DirectAccess relies on Internet Protocol version six (IPv6) transition technologies to establish client connections. RRAS implements Internet Key Exchange version 2 (IKEv2) Internet Protocol security (IPsec), and configures incoming and outgoing packet filters to drop all packets using transition technologies. This results in DirectAccess traffic being blocked if RRAS is installed and VPN access is deployed with IKEv2.

DirectAccess implements IPsec Denial of Service Protection (DoSP) to protect resources on the corporate network. DoSP drops all IPv4 traffic, and all IPv6 traffic that is not protected by IPsec, except ICMPv6 packets. This results in all IPv4 packets and non-IPsec-protected IPv6 packets forwarded by RRAS being blocked if DirectAccess is installed.

Windows Server 2012DirectAccess and RRAS unified server role solves these problems by modifying IKEv2 policies to allow IPv6 transition technology traffic, and by modifying IPsec DoSP to allow VPN traffic. These changes allow both DirectAccess and RRAS to coexist on the same server.

Windows Server 2012 includes features to facilitate deployment, particularly for small and medium size organizations. These new features include a simplified prerequisite list, removal of the need for a full PKI deployment, integrated certificate provisioning, and removal of the requirement for two consecutive public IPv4 addresses. Each of these features is discussed in more detail in the following sections.

Administrators can now deploy DirectAccess using a new Getting Started Wizard, which presents a greatly simplified configuration experience. The Getting Started Wizard masks the complexity of DirectAccess, and allows for an automated setup in a few simple steps. The administrator no longer requires an understanding of the technical details of IPv6 transition technologies and Network Location Server (NLS) deployment.

One major deployment blocker for Windows 7 DirectAccess is the requirement of a PKI for server and client certificate-based authentication. DirectAccess relies on IPsec AuthIP policies for authenticating and securing traffic from Internet-connected clients. In order to authenticate to domain resources using Kerberos, the client must first establish connectivity to DNS servers and Domain Controllers (DCs).

Windows 7 DirectAccess enables this connectivity by implementing two authentication methods in the AuthIP policies. The infrastructure IPsec tunnel is established using computer certificate as the first authentication method and user NTLM as the second method. Once this tunnel is established and a DC is available, the client can obtain a Kerberos token and establish the intranet IPsec tunnel using computer certificate and user Kerberos as the first and second authentication methods.

This implementation requires that the DirectAccess server and all clients be provisioned with computer certificates for mutual authentication. Managing an internal PKI is considered difficult by many small and medium organizations. Windows Server 2012 DirectAccess makes PKI deployment optional to simplify configuration and management.

This functionality is achieved by implementing an HTTPS based Kerberos proxy. Client authentication requests are sent to a Kerberos proxy service running on the DirectAccess server. The Kerberos proxy then sends Kerberos requests to Domain Controllers on behalf of the client.

The new Getting Started wizard provides a seamless experience for the administrator by configuring this solution automatically. In this simplified DirectAccess deployment, user level configuration options such as force tunneling, Network Access Protection (NAP) integration, and two-factor authentication are not available. This deployment requires only one IPsec tunnel to be established, and has the following requirements:

  • The DirectAccess server must have TCP port 443 open on its firewall

  • The DirectAccess server should have a server authentication certificate for TLS issued by a Certification Authority (CA) that is trusted by the DirectAccess clients. This can be a public CA and does not require an internal PKI deployment. If no certificate is available, the DirectAccess server setup process will configure the necessary IP-HTTPS and KDC proxy certificate automatically as a self-signed certificate.

To allow access to internal IPv4-only resources, Windows Server 2012 and Windows Server 2012 R2 DirectAccess includes native support for a protocol translation (NAT64) and name resolution (DNS64) gateway to convert the IPv6 communication from a DirectAccess client to IPv4 for the internal servers. IPv4-only intranet computers cannot initiate connections to DirectAccess clients for remote management because the translation done with NAT64 is unidirectional (for traffic initiated by the DirectAccess client).

There are three primary instances where IPv6-only DirectAccess does not allow full access to corporate intranet resources.

  • Intranet servers that are not fully IPv6 capable and support only IPv4, such as Windows Server 2003 file servers

  • Environments where IPv6 has been administratively disabled on the network

  • Applications running on IPv6 capable servers (such as Windows Server 2008) which are not IPv6 capable themselves (such as applications that are not able to listen and respond to traffic on the IPv6 interface)

To access these resources over DirectAccess, protocol translation must be done between the DirectAccess server and the internal IPv4-only resources, with subsequent translation back to IPv6 for responses sent to DirectAccess clients. NAT64 receives IPv6 traffic from the client and converts it into IPv4 traffic to the intranet. NAT64 is used in combination with DNS64. DNS64 intercepts DNS queries from clients, and sends responses after converting IPv4 answers into associated IPv6 mappings on the NAT64.

Prior to Windows Server 2012 DirectAccess, the only method available to provide protocol translation for DirectAccess is through deployment of Microsoft Forefront Unified Access Gateway DirectAccess.

The DirectAccess setup wizard will seamlessly configure protocol translation components as a background operation, without any need for administrative interaction. There are no configuration options exposed to the administrator. The setup wizard will automatically enable NAT64 and DNS64 if the internal interface of the DirectAccess server has an IPv4 address assigned. To support this functionality, the setup wizard will configure an IPv6 network prefix for NAT64. The wizard assigns the NAT64 prefix automatically, and applies it to all IPv4 ranges in the enterprise.

A Windows Server 2008 R2 DirectAccess 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. In order for clients behind a NAT to determine the Teredo server and the type of NAT device, the Teredo server requires two consecutive IPv4 addresses.

This requirement presents difficulty for small and medium organizations that do not have access to consecutive, public IPv4 addresses. In the future this has the potential to become a deployment blocker as the available IPv4 address space is exhausted. Windows Server 2012 and Windows Server 2012 R2 DirectAccess provides the ability to deploy the DirectAccess server behind a NAT device, with support for a single network interface or multiple interfaces, and removes the public IPv4 address prerequisite.

When the Remote Access Services setup Getting Started Wizard or Remote Access Setup Wizard is run, it will check the status of network interfaces on the server to determine if the DirectAccess server is located behind a NAT device. In this configuration, only IP over HTTPS (IP-HTTPS) will be deployed. The IP-HTTPS protocol is an IPv6 transition technology that allows for a secure IP tunnel to be established using a secure HTTP connection.

Windows Server 2008 R2 DirectAccess uses two IPsec tunnels to establish connectivity to the corporate network. The DirectAccess client requires the infrastructure tunnel to access infrastructure resources such as DNS, DC, and Management servers. These infrastructure servers are all listed as endpoints in the infrastructure tunnel IPsec policy. Then the intranet tunnel provides access to all other corporate intranet resources.

The endpoints listed in the infrastructure tunnel policy require periodic updates as the infrastructure changes, such as when DNS servers or Domain Controllers are added to or removed from the production network. Clients can lose connectivity to the domain when their IPsec policies are not updated to reflect the current infrastructure server endpoints, and this loss of connectivity will prevent them from receiving group policy updates to correct the failure.

In Windows Server 2012 and Windows Server 2012 R2, the Simplified DirectAccess model provides a way to deploy DirectAccess over a single IPsec tunnel, which eliminates this problem. However, Simplified DirectAccess does not support certain capabilities, which rely on certificate-based authentication. Examples are two-factor authentication with smart cards, multi-site, and NAP integration. Enterprises requiring a full featured DirectAccess experience will still need to deploy the two-tunnel model.

If the two-tunnel model is required for full functionality, there is additional functionality available to enable administrators to refresh the list of servers that are made accessible via the infrastructure tunnel. New domain controllers and System Center Configuration Manager servers are discovered and added to the list. Servers that no longer exist are removed from the list, and entries for servers whose IP addresses have changed are updated.

Windows Server 2008 R2 DirectAccess does not provide a full high availability solution, and is limited to single-server deployments. To provide limited hardware redundancy, DirectAccess can be configured inside a Hyper-V Failover cluster configured for Hyper-V Live Migration. However, only one server node may be online at any time.

DirectAccess deployments have quickly grown beyond the point where a single server can provide adequate processing power. Enterprises need the flexibility to deploy additional servers quickly and transparently to meet changing load requirements. Additionally, the Network Location Server used for inside/outside detection must be highly available to prevent major outages for DirectAccess clients connected to the intranet.

Windows Server 2012 and Windows Server 2012 R2 DirectAccess address these issues through built-in support for Windows Network Load Balancing (NLB) to achieve high availability and scalability for both DirectAccess and RRAS VPN. The NLB configuration is simple to setup and automate through the new deployment wizard interface. The setup process also provides integrated support for third party external hardware-based load balancer solutions.

Windows Server 2012 and Windows Server 2012 R2 DirectAccess provides a basic failover solution using Network Load Balancing for up to eight nodes. Although server load will be shared across all NLB nodes, existing connections will not automatically be transferred to other servers when one server becomes unavailable.

The DirectAccess setup wizard in Windows Server 2008 R2 can be used to configure DirectAccess for a single domain only. This means that remote clients from a different domain from the DirectAccess server will not be able to use DirectAccess. In addition, if application servers are in a different domain, remote clients will not be able to access them remotely via DirectAccess.

Although administrators can manually configure multiple domain support in Windows Server 2008 R2, the deployment requires manual edit of the DirectAccess policies after setup is completed. Windows Server 2012 and Windows Server 2012 R2 DirectAccess provides integrated multiple domain support to allow remote client access to enterprise resources located in different domains.

To increase login security, many organizations have deployed One-Time Password (OTP) two-factor authentication, and mandate its use for remote access connections. Windows Server 2008 R2 DirectAccess provided support for two-factor authentication with Smart Cards, but was not capable of integrating with OTP vendor solutions, such as RSA SecurID. This prevented DirectAccess deployment in organizations that require this level of security.

Windows Server 2012 and Windows Server 2012 R2 DirectAccess supports two-factor authentication with Smart Cards or OTP token based solutions. This feature requires a PKI deployment, so if the option is selected in the DirectAccess Setup Wizard, the Use computer certificates option is automatically selected and enforced.

In addition to support for standard smart card authentication, DirectAccess can use the Trusted Platform Module (TPM)-based virtual smart card capabilities available in Windows Server 2012 and Windows Server 2012 R2. The TPM of client computers can act as a virtual smart card for two-factor authentication, thus removing the overhead and costs incurred in smart card deployment.

By default, DirectAccess clients are able to access the Internet, the corporate intranet, and local LAN resources simultaneously. Since only connections made to the corporate intranet are sent over the DirectAccess IPsec tunnels, this is known as a split-tunnel configuration. Split tunneling provides an optimal user experience when accessing resources on the Internet, while still providing strong security for traffic intended for the intranet.

Although split tunneling is not a security risk, some organizations have a requirement to force all traffic through a corporate proxy so that it can be inspected by their IDS. With legacy VPN connections, the potential exists for users to bridge traffic between networks, such as a home network and the corporate network, effectively making the client operate as a router. For this reason, it is common practice for administrators to disable split tunneling for VPN connections, forcing all network traffic to be routed through the VPN connection. This results in decreased performance when accessing Internet resources, since all traffic must traverse the VPN tunnel and then be proxied out to the Internet. It also consumes significant additional bandwidth on the corporate network.

The perceived security risk of split tunneling is not valid in a DirectAccess scenario, since the IPsec rules that enable DirectAccess require authentication by the client endpoint. If another endpoint attempts to route through the DirectAccess client, it will not be an authenticated source, and IPsec will prevent the connection. However, since some organizations have a requirement to force all traffic through the corporate proxy server so that it can be inspected, the DirectAccess Force Tunneling option provides this ability.

The Force Tunneling option was provided in Windows Server 2008 R2 DirectAccess, but required manual steps to enable it via group policy setting. Windows Server 2012and Windows Server 2012 R2 DirectAccess integrate the Force Tunneling option with the Setup Wizard and management UI to automate the required settings. Enabling the Force Tunneling option limits the DirectAccess client to using only the IP-HTTPS protocol for connectivity, and by default uses the DirectAccess server as the NAT64/DNS64 server to translate IPv6 resources to send to the IPv4 proxy server.

On certain networks, Internet firewall settings may prevent successful client connections using the 6to4 or Teredo IPv6 transition technologies. IP-HTTPS is an IPv6 transition technology introduced in Windows 7 to ensure that DirectAccess clients can connect to the corporate network even when all other IPv6 transition technologies fail. IP-HTTPS assigns a unique, globally routable IPv6 address to an IPv4 host, encapsulates the IPv6 packets within IPv4 for transmission over an HTTPS tunnel, and routes IPv6 traffic between the host and other globally routable IPv6 nodes.

Windows Server 2012 and Windows Server 2012 R2 provide several improvements to the implementation of IP-HTTPS. Changes to the technology allow IP-HTTPS clients to obtain proxy configuration information, and authenticate to an HTTP proxy if authentication is required. The Windows 7 requirement to deploy client certificates to each IP-HTTPS client has been removed.

IP-HTTPS works by creating an SSL/TLS connection between the client and server, then passing IP traffic across the connection. This data is encrypted by IPsec, which means that the data is encrypted twice, first by IPsec, and again by SSL. The result is poor performance and a negative user experience compared to the other IPv6 transition technologies 6to4 and Teredo, and limits the scalability of the DirectAccess server.

Windows Server 2012 and Windows Server 2012 R2 DirectAccess include several performance improvements for IP-HTTPS to increase scalability and reduce the overhead associated with this connectivity method. These optimizations include changes to batched send behavior and receive buffers, reduced lock contention, and the option to implement SSL with NULL encryption.

IP-HTTPS runs in a system context rather than a user context. This context can cause connection issues. For example, if a DirectAccess client computer is located in the network of a partner company that uses a proxy for Internet access, and WPAD auto detection is not used, the user must manually configure proxy settings in order to access the Internet. These settings are configured in Internet Explorer on a per user basis, and cannot be retrieved in an intuitive way on behalf of IP-HTTPS. In addition, if the proxy requires authentication, the client provides credentials for Internet access, but IP-HTTPS will not provide the credentials required to authenticate to DirectAccess. In Windows Server 2012, a new feature solves these issues. Specifically, the user can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD and IP-HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and relay it to the DirectAccess server.

When configuring IP-HTTPS in DirectAccess on the server, you can use a certificate issued by a certification authority (CA), or you can specify that DirectAccess should automatically generate a self-signed certificate.

DirectAccess clients establish connectivity to the corporate intranet whenever an Internet connection is available, even if there is no user logged in. This allows IT administrators to manage remote machines for patching and compliance enforcement even when they are not in the office. Some customers see this as the primary benefit to DirectAccess, and choose to keep their existing remote access solution in place for user connectivity, while using DirectAccess just for remote management.

Windows Server 2008 R2 DirectAccess does not provide an automated method to limit the deployment to manage-out only, and administrators must manually edit the policies created by the setup wizard. Windows Server 2012 and Windows Server 2012 R2 DirectAccess provide support for a manage-out only configuration through a deployment wizard option that limits the creation of policies to only those needed for remote management of client computers. In this deployment, user level configuration options such as force tunneling, NAP integration, and two-factor authentication are not available.

Manage-out support requires ISATAP deployment or management servers with v6 addresses.

DirectAccess servers can be deployed in multiple sites to increase capacity and provide more efficient access to the nearest entry point for intranet resources. This works well if clients remain in their respective sites and do not need to travel to different sites within the enterprise. However, setting up multisite DirectAccess requires careful planning and design if clients will roam between sites, to ensure that they connect through DirectAccess servers via the most efficient route.

There are many challenges to consider in a multisite environment, such as making sure the client locates the closest IP-HTTPS server, Teredo server, DNS server, and Domain Controller. Windows Server 2012 and Windows Server 2012 R2 DirectAccess provide a solution that allows for deployment of multiple DirectAccess entry points across geographic locations, and allows clients regardless of their physical location to access resources within corpnet in an efficient manner.

Windows Server 2012 and Windows Server 2012 R2 DirectAccess servers can be configured in a multisite deployment that allows remote users in dispersed geographical locations to connect to the multisite entry point closest to them. For client computers running Windows 8, entry points can be assigned automatically, or selected manually by the client. For Windows 7 client computers, entry points can be allocated statically. Traffic across the multisite deployment can be distributed and balanced with external traffic across the multisite deployment, all of which can be distributed and balanced with an external global load balancer.

Server Core is a minimal server installation option designed to reduce disk space, servicing, and management requirements, and decrease the operating system attack surface. The Server Core system does not support a Graphical User Interface, and administrators must use command line or remote management tools to accomplish all necessary configuration tasks.

A Server Core installation supports only a limited subset of the features available on a full installation of Windows Server, and currently does not include support for the DirectAccess feature or the Remote Access server role. A Windows Server 2012 or Windows Server 2012 R2 Server Core installation includes support for the unified server role for both DirectAccess and RRAS.

The new Remote Access server role has complete Windows PowerShell support in Windows Server 2012 and Windows Server 2012 R2 that may be used for installation, configuration and monitoring. The Remote Access server role can also be configured through remote server management.

DirectAccess 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.

Monitoring and diagnostics capabilities for both RRAS server and DirectAccess are limited in Windows Server 2008 R2. For DirectAccess, the monitoring capabilities only include basic health monitoring of DirectAccess and its components. The monitoring data and statistics available are of little significance or relevance to administrators.

User and server health monitoring introduced in Windows Server 2012 allows the administrator to understand the behavior of the DirectAccess clients and connections. The monitoring console is used to keep track of the load on the DirectAccess server, user activity, and current resource usage. The administrator uses this information to identify potentially undesirable or inappropriate usage activities. Diagnostic tracing can be enabled from the monitoring console as well.

User Monitoring

Administrators of remote access solutions require the ability to monitor not only which users are connected, but also which resources they are accessing. If users complain that a particular server or file share is inaccessible while remote, the administrator currently has no way to determine if other users are successfully accessing the resource from the remote access console. Multiple tools and applications are typically needed to troubleshoot issues such as particular users consuming excessive bandwidth.

The Dashboard is accessed from the new Remote Access server management console by selecting the Dashboard tab in the navigation pane. The dashboard displays overall operational status and remote client activity and status. The administrator can also view quick reports directly from the dashboard.

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 DirectAccess and VPN remote clients

  • Total number of active DirectAccess clients connected – only the total number of clients connected using DirectAccess

  • Total number of active VPN clients connected – only the total number of clients connected using VPN

  • Total unique users connected – includes both DirectAccess and VPN users, based on the active connections

  • Total number of cumulative connections – 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 DirectAccess and VPN since the last server restart

    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

In a cluster deployment, the Remote Client Activity and Status summary on the Remote Access Dashboard displays total values for all of the cluster nodes.

Administrators can see a list of all remote users currently connected, and can display a listing of all resources being accessed by clicking on a particular remote user. Administrators can display remote user statistics by selecting the Remote Client Status link in the Remote Access Management Console. The user statistics can be filtered based on criteria selections using the following fields:


Field Name



The user name or alias of the remote user. Wildcards may be used to select a group of users, such as contoso\* or *\administrator. If Comment [A5]: Move this table to the monitoring scenario doc no domain is specified, then *\username is assumed.


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


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


The transitioning technology used by the remote client – 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


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

This feature allows administrators to manage and monitor the status of remote access deployments from a centralized monitoring console. The feature shows alerts to administrators whenever an issue requiring attention is detected. The interface displays detailed diagnostic information with steps to provide resolution.

The Dashboard node of the console tree shows the status of the Remote Access Server, including the status of remote access infrastructure and related components, as well as whether the configuration is properly distributed across entry points.

The Server Operations Status node of the console tree shows the status of the Remote Access Server, including the status of remote access infrastructure and related components. By clicking on a particular component, administrators can see the state, change history, and monitoring details for that component.

If remote access servers are deployed in a cluster or multisite deployment, all servers in the cluster or multisite deployment are evaluated asynchronously, and are listed with their overall status. Administrators can scroll through the list of servers and expand or collapse the view to display DirectAccess and VPN server components.

The Remote Access components with status monitors displayed in the Server Operations Status pane are listed below.

  • 6to4

  • DNS

  • DNS64

  • Domain controller


  • IPsec


  • Kerberos

  • Management Servers

  • NAT64

  • Network Adapters

  • Network Location Server

  • Network Security (IPsec DoSP)

  • Services

  • Teredo

  • Load Balancing

  • VPN addressing

  • VPN connectivity

Troubleshooting remote access connectivity failures for both RRAS and DirectAccess can be very complex due to the limited logging capabilities currently provided. Administrators typically require Network Monitor captures and RRAS tracing for troubleshooting, since Event Viewer logs are not very useful or prescriptive.

Windows Server 2012 and Windows Server 2012 R2 provide the following diagnostic feature improvements for remote access troubleshooting.

  • Detailed event logging for DirectAccess

    Administrators can use improved event logging to identify problems and perform capacity and performance analysis. The event logs are standardized to ensure a consistent experience with other networking components.

  • Tracing and Packet Capture

    Integrated tracing makes it easy for administrators to gather trace logs and network packet captures with a single click. Both tracing with packet capture and log correlation are done as part of a single process when the administrator clicks the Start tracing task in the Tasks pane.

  • Log Correlation

    This feature provides automated collection and correlation of logs for different DirectAccess components with a single click, leveraging the Unified Tracing feature of Windows. The events gathered from different components are consolidated into a single file through correlation of Activity IDs. Activity IDs are GUIDs that identify a particular task or action. When a component logs an event, it associates an Activity ID with the event. The component then passes either this ID or a transfer event mapped to the ID to the component that performs the next task in the scenario, which associates its activity ID to log events. When analyzing the resulting trace file, the relationship between the various components relevant to a scenario can be reconstructed.

  • Enabling/Viewing Logs

    Tracing can be enabled from the Tasks pane of the Monitoring Dashboard, or from the command line, which also controls logging levels, keywords and filters. The resultant Unified Tracing ETL files generated can be read and viewed using Network Monitor.

A Windows Server 2012and Windows Server 2012 R2 Remote Access servers can leverage an existing RADIUS server deployment or Windows Internal Database (WID) for accounting purposes. Information and historical data for load and server status are available through system Performance Monitor counters, and are stored in the WID accounting store. Whenever any connection is received or disconnected on the remote access server, all the remote user statistics (including the endpoints accessed) is saved in the accounting store as one session. This allows session details to later be accessed for reporting and auditing purposes.

The accounting and reporting functionality provided in the Remote Access Server Role includes the ability to measure specific metrics. Available metrics include the number of users connected to a particular DirectAccess server, and total bytes transferred. Administrators can create custom reports to identify traffic and usage patterns, including a history of these patterns.

DirectAccess and RRAS reporting capabilities enable administrators to generate rich usage reports on various statistics such as remote user statistics, server availability and load. The inbox accounting store is leveraged to generate the usage report. Inbox accounting to a local WID database must be enabled in order to generate usage reports. NPS/RADIUS accounting cannot be used for generating reports.

The usage report provides a display of usage history including which users established remote connections, what resources they accessed, the total number of unique users, and maximum server load generated. The administrator can select a specific timeframe from which to generate the data.

Cross Premise Connectivity is a Windows Server 2012 and Windows Server 2012 R2 feature that provides the network connectivity to enable service hosting providers to migrate their applications and infrastructure to the cloud. This feature includes a site-to site Internet Key Exchange version 2 (IKEv2) tunnel mode VPN connectivity solution and management interface. Windows Server 2008 R2 introduced IKEv2 support in RRAS for VPN connections. An IKEv2 VPN provides resilience to the VPN client when the client moves from one network to another or when it switches from a wireless to a wired connection. The use of IKEv2 and IPsec allows support for strong authentication and encryption methods. Windows Server 2012 and Windows Server 2012 R2 RRAS provides added feature enhancements to enable IKEv2 for site-to-site VPN connections.

Vindt u dit nuttig?
(1500 tekens resterend)
Bedankt voor uw feedback


© 2014 Microsoft. Alle rechten voorbehouden.