When you use DirectAccess (DA) you have to unblock ISATAP on your DNS servers, so when clients do a DNS lookup for ISATAP they will get an answer.
If you add a new domain controller with the DNS role, you must remember to remove ISATAP from the block list. You removed it on your DNS servers when you configured DA long time ago, but will you or your successor remember to remove the blocking if you add a new DC/DNS?
I didn’t until I saw a 7600 event id on the new DC/DNS…
Too see the current settings:
dnscmd /info /globalqueryblocklist
To remove ISATAP manually from the block list:
dnscmd /config /globalqueryblocklist wpad
To avoid this from happening in the future, I configured a Group Policy (GPO) to do the job. I reckon a GPO is more reliable than a Teflon brain.
Open the Group Policy Management consol.
Create the WMI:
First you need to create a WMI filter so the GPO only apply to servers with the DNS server role. Give it a meaningful name.
Query: SELECT id FROM Win32_ServerFeature WHERE id = "13"
(ID 13 = DNS Server)
Create the GPO/GPP:
Group Policy Objects -> New
Give it a name. I called it “GPP_Unblock_ISATAP”.
Computer Configuration – Preferences – Windows Settings – Registry
Choose New – Registry Item
Value to remove: isatap
Link the GPO to the WMI filter you created:
Link the GPO to the OU where your DNS servers reside. I linked it to the Domain Controllers OU since we don’t have any standalone DNS servers. The WMI filter will anyway only apply to DNS servers, so you can link it higher up.
You’ll have to restart the DNS server service, or reboot the server before the setting is applied to the DNS server. Check the status “dnscmd /info /globalqueryblocklist”. If ISATAP is not present you are good to go.
Notice this only apply to Win2008 and newer, since legacy OS don’t have the Win32_ServerFeature class.
If you have Win2003 DNS servers, you’ll see that the WMI filter return “false” and the GPO will not apply:
On Win2008 and newer: