By restarting CLIENT1 you are ensuring that the new DirectAccess group policies
are applied. Additionally, you may need to also run gpupdate.exe on the
DirectAccess server. Once you have ensured that the DirectAccess group policies
have been on all DirectAccess servers and clients you will need to restart the
IP Helper service on all internal servers (this includes DC, fileserver,
Webserver, and DA). To complete this task use the following commands:

net
stop iphlpsvc

net
start iphlpsvc

By restarting the IP Helper service, the systems will be able resolve the
isatap.example.local DNS entry created by the DirectAccess Setup Wizard and
will enable their ISATAP interfaces. Once the service has been restarted the
internal IPv6 network should be fully functional and all systems should be able
to reach each other using the IPv6 addresses as well as the IPv4 addresses.

The ping.exe tool can be used to verify that IPv6 is working. The -6
option forces ping to use

IPv6. The -4 option forces ping to use IPv4. The command to ping a
computer DC01 using IPv6 is ping DC01.example.local -6. The command to ping a
computer DC01 using IPv4 is ping DC01.example.local -4. Each computer should be successfully
pinged with both commands. This can be a very useful technique when
troubleshooting DirectAccess and IPv6.

Testing DirectAccess

The last task in the DirectAccess configuration is to test the
deployment and verify DirectAccess functionality. As mentioned previous the
DirectAccess functionality will be verified by trying to access

Fileserver and Webserver using the internal network (Test A) and the
public network (Test B).

Use the following steps to complete Test A:

1. While logged into CLIENT1 to the internal network.

2. Select Start, enter cmd, and press Enter.

3. At the command prompt, enter ipconfig and press Enter. Figure 13
shows that CLIENT1 has been assigned an IPv4 address (192.168.1.5) on the internal network
and that an ISATAP address has been automatically generated in the ISATAP
tunnel adapter.

FIGURE 13 Test A—Internal
Network.

4. Next, try to access a share on flsrv-iflex.example.local to demonstrate access.

5. Finally, open Internet Explorer and access http://nls.example.local
to demonstrate access. By completing Test A you should be able to demonstrate
that CLIENT1 is connected to the internal network and is able to access resources
and that the IPv6 transitional technologies are working internally,
specifically ISATAP.

For Test B, the connection to the public network, execute the following
steps:

1. Connect the DirectAccess client CLIENT1 to the public network.

2. Select Start, enter cmd, and press Enter.

3. At the command prompt, enter ipconfig and press Enter. Figure 14
shows that CLIENT1 has been assigned an IPv4 address (14.194.56.174) on the public network
and that a 6to4 address has been automatically generated with the 6to4 2001:
prefix in the 6to4 tunnel adapter.

FIGURE 14 Test B—Public Network.

4. Next, try to access a share on flsrv.example.local to demonstrate access.

By completing Test B you should be able to demonstrate that CLIENT01 is
connected to the public network, able to access internal resources and that the
IPv6 transitional technologies are working publicly, specifically 6to4.

6. To verify IP-HTTPS connectivity you will need to disable the Teredo
interface by executing the following command:

netsh
interface teredo set state disable

7. After disabling the Teredo interface execute the following command to
verify the IP-HTTP connection

Implementing Microsoft DirectAccess Step by Step: Part 6The DirectAccess server includes an excellent tool to monitor the
activity of the DirectAccess clients.

Shown in Figure 17, it provides an overall status of the DirectAccess
server, status and activity of the individual DirectAccess components, and
detailed statistics on the components. The figure shows that the Teredo
components are active, indicating that there are DirectAccess clients using
Teredo but none using IP-HTTPS.

FIGURE 17
DirectAccess Monitoring

The DirectAccess Monitoring tool provides information on the traffic
activity, data, and control traffic counters for the following components:

· Teredo Relay

· Teredo Server

· 6to4

· IPHTTPS

· ISATAP

· Network Security

· DNS Server

The status information in the tool is updated every 10 seconds and the
status indicators for the components will change depending on the health and
activity of the component. For example:

· Green indicates
current activity in the component.

· Orange indicates the
component is idle.

· Yellow indicates the
component is experiencing issues.

· Red indicates that
the component has failed.

To access the DirectAccess Monitoring tool use the following steps:

1. On DA, launch Server Manager.

2. Expand Features\DirectAccess and select Operations Status.

3. The details window will show the component status screen. As
connections are made, the status will update every 10 seconds to show the
activity.

4. To see the performance metrics for any given component, click on the
Details button to launch

Performance Monitor with the appropriate counters.

The DirectAccess Monitoring tool gives access to dozens of key
performance metrics in graphical or tabular format. These metrics are
invaluable for monitoring and troubleshooting the DirectAccess infrastructure.

Implementing Microsoft DirectAccess Step by Step: Part 5The next task in the DirectAccess deployment is to complete the
DirectAccess installation and Configuration. To start this process you will
first need to request a server authentication certificate that will be used for
IP-HTTPS. Use the following steps to complete this task:

4. In the console tree of the Certificates snap-in, expand Certificates
(Local Computer)\Personal.

5. Right-click Certificates, point to All Tasks, and then click Request
New Certificate.

6. Click Next twice.

7. On the Request Certificates page, click Web Server 2008, and then
click more information is required to enroll for this certificate.

8. On the Subject tab of the Certificate Properties dialog box, in
Subject name, for Type, select Common Name.

9. In Value, type directaccess.example.local, and then click Add.

10. In Alternative name, for Type, select DNS.

11. In Value, type directaccess.example.local, and then click Add.

12. Click OK, click Enroll, and then click Finish.

Note

Point 7 assumes that the Web
Server 2008 certificate template was created beforehand. For the purpose of
this scenario the Web Server 2008 template was a version 3 template that was
duplicated from the version 1 Web Server template. The permissions for the Web
Server 2008 certificate template were modified to allow Domain Computers to
enroll for certificates based on this template and the private key can be
exported. Lastly, the subject name and subject alternative name of a certificate
can be specified during the request.

13. In the details pane of the Certificates snap-in, verify that a new
certificate with the name

Directaccss.example.local was enrolled with Intended Purposes of Server
Authentication.

14. Right-click the certificate and select Properties.

15. In the Friendly Name field, type IP-HTTPS and click OK.

Once the IP-HTTPS certificate has been installed the next task is to
install the DirectAccess Management Console feature on DA01. Use the following
steps to complete this task:

1. On DA, launch Server Manager.

2. Right-click on Features and select Add Features.

3. On the Select Features page, select DirectAccess Management Console.

4. At the pop-up, click Add Required Features. This adds the Group
Policy Management feature.

5. Click Next.

6. Click Install.

7. Click Close to finish.

After the DireactAccess Management Console has been installed the next
task is to complete the

DirectAccess configuration using the DirectAccess Setup Wizard. To
complete this task use the following steps:

1. On DA, launch Server Manager.

2. Expand Features, DirectAccess, and select the Setup node. The screen
will show the DirectAccess Setup Wizard, as shown in Figure 8.

FIGURE 8 DirectAccess Setup Wizard.

3. In Step 1 Remote Clients, click Configure.

4. On the DirectAccess Client Setup page, click the
Add button.

5. In the Select Group dialog box, type DA_Client and
click OK. The screen will show the group, as shown in Figure 9.

FIGURE 9 DirectAccess Client Setup.

6. Click Finish.

7. In Step 2 DirectAccess Server, click Configure.

8. On the Connectivity page, for Interface Connected
to the Internet, ensure that the correct interface is selected. For Interface
Connected to the Internal Network, ensure that the correct interface is selected.
The wizard will attempt to select the best interfaces based on the IP address
ranges. In Figure 10, the public address has been assigned to the Internet
interface and the private address has been assigned to the internal interface.

FIGURE 10 DirectAccess Server Connectivity Setup.

The DirectAccess Setup Wizard has an informational note that it detected
that the internal network is IPv4-based and will enable IPv6 transition
technologies as part of the setup. The

DirectAccess server will be configured as the ISATAP server.

9. Click Next.

10. On the Certificate Components page, for select the Root Certificate
to Which Remote Client

Certificates Must Chain, click Browse. In the list of certificates,
select the appropriate Root CA certificate, and then click OK.

11. For Select the Certificate That Will Be Used to Secure Remote Client
Connectivity over HTTPS, click

Browse. In the list of certificates, click the certificate named
IP-HTTPS, and then click OK. The results are shown in Figure 11. Click Finish.

FIGURE 11 DirectAccess Server certificate
components.

12. In Step 3 Infrastructure Servers, click Configure.

13. On the Location page, click Network Location Server Is Run on a
Highly Available Server, type

https://nls.example.local ,click Validate, and then click Next. You
should get a green check mark with a Validation Successful message.

14. On the DNS and Domain Controller page (shown in Figure 12), note the
entry for the name example.local with the IPv6 address. This is the 6to4 IPv6
address for the DC01 domain controller. All

DirectAccess client requests to the domain example.local will be
forwarded to this domain controller.

nls.example.local and directaccess.example.local are also listed with a
blank DNS server which defines an NRPT exemption for these FQDNs.

FIGURE 12 DirectAccess
Infrastructure Server Setup for DNS.

The blank DNS for the network location server is needed so that
DirectAccess clients can use the URL to determine if they are inside the
corporate network or on the Internet. When inside the network, the DirectAccess
clients will be able to access the site. When remote and connected via
DirectAccess, the clients will be unable to reach the site due to the blank DNS
entry, although they can reach all other internal resources. Example.local and nls.example.local
com have been added as NRPT exceptions because of the split-brain DNS
configuration. If these exceptions were not added then clients would not be
able to resolve these FQDNs when they were on an external network.

15. Click Next.

16. On the Management page, if there were internal management servers,
such as Microsoft System Center Configuration Manager 2012 (SCCM) servers that
needed to reach the DirectAccess clients, they would be entered in this portion
of the setup. For the purposes of this scenario leave this blank and click
Finish.

17. In Step 4 Application Servers, click Configure.

18. On the DirectAccess Application Server Setup page, leave Require No
Additional End-to-End Authentication. If end-to-end protection were required,
this step in the configuration wizard is where the permitted application
servers would be added. For the purposes of this only the end-to-edge access
model is being used, so no additional configuration is needed.

During the configuration process two new Group Policy Objects are
created, each named DirectAccess

Policy-<GUID>. One has security filtering defined such that it
applies only to the DirectAccess server by computer name (DirectAccess$). The other
has security filtering defined such that it applies only to the

Implementing Microsoft DirectAccess Step by Step: Part 4Once the network location server has been configured the next task in
the DirectAccess deployment is to ensure that all domain members have a valid
client authentication certificate. The steps to complete this task may vary
depending on the overall certificate requirements for your environment. However,
for the purposes of this scenario the following generic steps should be used:

Implementing Microsoft DirectAccess Step by Step: Part 3The website used for the network location server (NLS) needs to support
HTTPS and can be any website that is available internally, although it is a
best practice that it be highly available. For the purpose of this scenario the
server WEBMO will be used to host the NLS Web site. To complete the NLS
configuration the first task is to ensure that the web server hosting the NLS
Web site has a valid server authentication

(SSL) certificate with customized subject and alternative name for the
network location URL. Use the following steps to complete this task:

4. In the console tree of the Certificates snap-in, expand Certificates
(Local Computer)\Personal.

5. Right-click Certificates, point to All Tasks, and then click Request
New Certificate.

6. Click Next twice.

7. On the Request Certificates page, click Web Server 2008, and then
click more information is required to enroll for this certificate.

8. On the Subject tab of the Certificate Properties dialog box, in
Subject name, for Type, select Common Name.

9. In Value, type nls.example.local, and then click Add.

10. In Alternative name, for Type, select DNS.

11. In Value, type nls.example.local, and then click Add.

12. Click OK, click Enroll, and then click Finish.

Note

Point 7 assumes that the Web Server 2008 certificate
template was created beforehand. For the purpose of this scenario the Web
Server 2008 template was a version 3 template that was duplicated from the
version 1 Web Server template. The permissions for the Web Server 2008 certificate
template were modified to allow Domain Computers to enroll for certificates
based on this template and the private key can be exported. Lastly, the subject
name and subject alternative name of a certificate can be specified during the
request.

Once the certificate has been installed the next task is to install the
Web Server (IIS) role and configure the HTTPS security binding on the default
Web site. Use the following steps to complete this task:

1. In the console tree of Server Manager, click Roles. In the details
pane, click Add Roles, and then click next.

2. On the Select Server Roles page, select the Web Server (IIS) check
box, and then click Next three times.

3. Click Install.

4. Verify that all installations were successful, and then click Close.

Implementing Microsoft DirectAccess Step by Step: Part 2The first task in a DirectAccess deployment is to modify the DNS service
configuration and remove the

ISATAP name from its default global block list. By making this change
the DNS will be able to service

ISATAP requests. Use the following steps to complete this task:

1. On PRIMARY Domain Controller, open PowerShell console session using the ― Run as
Administrator option.

2. In the PowerShell console, execute the following command:

dnscmd
/config /globalqueryblocklist wpad

Note

The preceding command needs to be run on each DNS
server on the internal network. In addition, it is important to understand that
this command is only being executed because this scenario is using ISATAP for
internal IPv6 support. Depending on your deployment needs, executing this
command may or may not be required.

The next task in the DirectAccess deployment is to create the NLS DNS
record (Network Location Server). This DNS record is used for the NLS URL that DirectAccess clients use
to determine if they are in the corporate network. Use the following steps to
complete this task:

4. In the Name field, type nls. In the IP address field, type the IP
address of the NLS website, click Add

Host, click OK, and then click done.

The last task in this section is to create a security group for
DirectAccess client computers. This allows the DirectAccess clients to be
defined within the DirectAccess configuration and apply specific

DirectAccess Group Policy Objects. For this scenario the group will be
named DirectAccessClients. Use the following steps to complete this task:

1. On DC01, launch Server Manager.

2. Expand Roles\Active Directory Domain Services\Active Directory Users
and Computers\ example.local and select the container that the new group object
will be created within.

3. Right-click on the container, select New, and then click Group.

4. In the Group Name field, type DA_Client.

5. Under Group scope, choose Global or Universal, under Group type,
choose Security, and then click

OK.

Configuring Windows Firewall for DirectAccess

The next task is to create and enable Windows Firewall rules that allow
inbound and outbound ICMPv6

We have compiled five step implementation posts, this will help you to
configure and monitor your Microsoft DIRECTACCESS using simple and complex scenario.

By completing this scenario the
following goals
will be accomplished:

Allow
a workstation to seamlessly move between internal, public, and home networks while retaining access to application servers.

Enable
IPv6 in an IPv4 network using IPv6 transition technologies.

This article
is for Windows Server 2012 and Windows 7/8 technologies that will automatically
enable and configure IPv6 using transitional technologies like IP-HTTPS,ISATAP,
6to4, and teredo.

Additionally, the intended DirectAccess server
must have two physical network interfaces. The first is connected directly to
the Internet (192.168.1.1) The second interface is connected to the internal network
(192.168.2.1).This two NICs should be on different IP network.

For this
scenario there are five servers and a client system. That we have configured
and tested against during the scenario.

· DC01 (192.168.1.2)—Domain controller,
DNS, and enterprise Certificate Authority server running Windows Server 2008
R2. The Active Directory domain is example.local The CA must have an Internet
available certificate revocation list (CRL) or you should have public
Certificates for your DA.