Tonight, I have some more DirectAccess 2012 woes and solutions to share. These are more or less some notes I jotted down while setting up DA2012 for a customer.
Note #1:
The following case occurred both with my customer’s DirectAccess 2012 server, as well as my home test lab. Both environments have a fresh Windows Server 2012 Datacenter installation and a brand new Windows Server 2012 Domain Controller (in Win2012 forest and domain levels) running in Hyper-V. DirectAccess was enabled using the basic single-NIC DirectAccess deployment method.
Opening the RemoteAccess console and looking at the Operations Status, all of the DA services are running and show a green check mark, but to the right an error is displayed, “Configuration for server cannot be retrieved from the Domain Controller”.
Performing a gpresult from an elevated command line showed the root cause right away:
Group Policy was filtering out my DA server from the GPO object for some reason. To fix, I opened up Group Policy Management on the domain controller and made sure that my DA server was a part of the group.
Note #2:
Open the Remote Access Console on your DA server. Click on “Configuration” in the left pane, then click on the edit button under Step #2. Do you see where the configuration wizard says that it is ok to type in an IPv4 address In the Network Topology screen? It is an outright lie!
DO NOT PLACE AN IP ADDRESS in the field. You MUST use a DNS name here. Setting up a free NO-IP.org dynamic DNS account will suffice. I believe the reason as to why this is the case is because of the self-signed certificate that is created – you can’t use an IP address, you need to use a DNS name that is reachable from the internet.
Note #3:
Make sure that the DirectAccess group policies created by the Remote Access Setup Wizard are not changed, moved, or edited in any way. Also, make sure that the two group policies are applied in the ROOT of the domain (right under the Default Domain Policy) and are NOT applied or moved to any organizational unit. Use the screenshot below as a reference.
If these policies are not in the domain root, they won’t apply correctly to the DA server (for the server policy) and your Windows clients (for the client policy). The lesson here is this: DO NOT MESS WITH GROUP POLICIES CREATED BY THE REMOTE ACCESS SERVER. EVER.
** If you did mess with the group policies, you will probably have to perform a manual removal of DirectAccess 2012 from your domain. Doing this is lengthy (and I do not have a complete process for doing this just yet because DA removal cleanup is done on a case-by-case or domain-by-domain basis).
Note #4:
You only need to forward ports 80 and 443 to the DA server behind a NAT, nothing else. Then, you need to allow internal domain traffic from Windows Firewall with Advanced Services only from the internal domain.
Note #5:
When in doubt, look up the official DirectAccess planning and configuration materials on TechNet. The key to resolving an issue is understanding how it works.
Note #6:
**DirectAccess in Windows 8 requires a TPM 1.2 enabled chipset on the PC. There are no workarounds for this requirement at this moment in time.
**DirectAccess only works on Windows 8 Enterprise, not Pro or Standard.
**Instead of using a physical smart card, you can use the new Virtual Smart Card feature in Windows 8 for DirectAccess to work. Look at this documentation for setting up a Virtual Smart Card to be used with DirectAccess in Windows 8: http://www.microsoft.com/en-us/download/details.aspx?id=29076
- Joe