Update adds BPA rules for DirectAccess in Windows Server 2012

There is a update that adds new Best Practices Analyzer (BPA) rules. The rules are for DirectAccess on the servers that are running Windows Server 2012.
The following rules are added:

  • Checks whether the Domain Name System (DNS) address that is used for internal network resources is correct. If the internal interface of the DirectAccess server has only an IPv4 address, the DNS server that is configured in the Name Resolution Policy Table (NRPT) must be the DNS64 address.
  • Gives a warning if the option that enables DirectAccess for Windows 7 clients is not selected. 
  • Returns an error if the DirectAccess server is also a domain controller.
  • Returns an error if both force tunneling and Kerberos authorization are configured on the DirectAccess server.
  • Returns an error if the AcceptInterface parameter for DNS64 does not use the same IP address as the one that is used for DNS64.
  • If DirectAccess is configured by using the Remote Access Management user interface, checks whether DirectAccess policies are configured on the server.
  • Gives a warning if any certificate that can be used on the DirectAccess server has subject alternative names (SANs) but no subject name.
  • Provides information if the order of the Internal network interface is below the Internet network interface in Adapters and Bindings.
  • Gives a warning if the private key of the IP-HTTPS certificate does not exist on the server when the certificate is used.
  • Gives a warning if the DirectAccess client security group includes desktop computers.
  • Sends an HTTP request to test whether the certificate revocation list (CRL) field in the IP-HTTPS certificate that is configured on the DirectAccess server is valid. If the request fails, a warning is displayed. This test is only required when Windows 7 clients are configured for DirectAccess.
  • Sends an HTTP request to test whether the CRL field in the network location server certificate that is configured on the DirectAccess server is valid. If the request fails, a warning is displayed. This test is only required when Windows 7 clients are configured for DirectAccess, and when NLS is deployed on the DirectAccess server.
  • Checks whether an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router or load balancing is configured on the network. If this is the case, checks the DNS records for ISATAP. The DNS server should have the records for the internal dynamic IP (DIP) of the server and for the internal virtual IP of the load balancer.
  • Checks whether the email address field is configured for Network Connectivity Assistant.
  • Checks whether the default gateway is configured on the Internet interface instead of on the Internal interface. If the check fails, a warning is displayed.
  • Gives a warning if NRPT exemptions are configured when force tunneling is deployed. 
  • Makes sure that probes other than Internet Control Message Protocol (ICMP) probes are configured in NCA.

Download the update here: HERE

After configuring DirectAccess in an IPv4-only deployment with a single network adapter, and after the default DNS64 (the IPv6 address which contains ":3333::") is automatically configured on the network adapter, attempting to enable load-balancing via the Remote Access Management console causes a prompt for the user to supply an IPv6 DIP. If an IPv6 DIP is supplied, the configuration fails after clicking Commit with the error: The parameter is incorrect.

  1. Download the backup and restore scripts from Back up and Restore Remote Access Configuration.
  2. Back up your Remote Access GPOs using the downloaded script Backup-RemoteAccess.ps1
  3. Attempt to enable load balancing until the step at which it fails. On the Enable Load Balancing dialog box, expand the details area, right-click in the details area, and then click Copy Script.
  4. Open Notepad, and paste the contents of the clipboard. For example:

    Set-RemoteAccessLoadBalancer -InternetDedicatedIPAddress @(‘10.244.4.19/255.255.255.0′,’fdc4:29bd:abde:3333::2/128’) -InternetVirtualIPAddress @(‘fdc4:29bd:abde:3333::1/128’, ‘10.244.4.21/255.255.255.0’) -ComputerName ‘DA1.domain1.corp.contoso.com’ -Verbose

  5. Close any open Remote Access dialog boxes and close the Remote Access Management console.
  6. Edit the pasted text and remove the IPv6 addresses. For example:

    (Remove de IPv6 IP Addresses)
    Set-RemoteAccessLoadBalancer -InternetDedicatedIPAddress @(‘10.244.4.19/255.255.255.0’) -InternetVirtualIPAddress @(‘10.244.4.21/255.255.255.0’) -ComputerName ‘DA1.domain1.corp.contoso.com’ -Verbose

    In an elevated PowerShell window, run the command from the previous step.

  7. If the cmdlet fails while it is running (not due to incorrect input values), run the command Restore-RemoteAccess.ps1 and follow instructions to make sure that the integrity of your original configuration is maintained.
  8. You can now open the Remote Access Management console again.