A common requirement or ask for most UAG DirectAccess deployments is the need to remotely manage DirectAccess clients when they are away from the corporate network. This is often termed ‘manage out’ and is one of the major benefits of a UAG DirectAccess solution when compared to traditional VPN remote access solutions. The ability to reach a managed client, irrespective of their location, irrespective of whether they are logged in, is a power tool for IT administrators.
However, the need for corporate connected manage out clients to be IPv6 capable often presents a challenge if the customer is not running IPv6 within their environment. This challenge is often met by configuring an intranet transition technology called ISATAP (Intra-Site Automatic Tunnel Addressing Protocol).
Unfortunately, the ISTAP mechanism uses a hard coded DNS lookup process that is automatically enabled on on Windows Vista, Windows 7 and Windows Server 2008/R2. This DNS lookup requires the creation of a global ‘isatap.domain.com’ DNS host record, and this will ultimately enable ISATAP, and automatically assign IPv6 addressing and prefix information, across the entire Windows Vista+ environment. In some scenarios, enabling IPv6 support using ISATAP is desirable, but for many deployments, adding IPv6 capabilities to all Windows systems is not desirable; especially when Windows will naturally favour IPv6 communications over IPv4. For many customers, the cultural change this IPv6 preference brings to a desktop and/or server administrator is more than a little confusing, and definitely not something that should be enabled globally without some thought.
So, how do we provide the IPv6 capabilities required for UAG DirectAccess manage out, whilst still preserving a more traditional IPv4 experience for other Windows systems?
The main way to solve this problem is to move away from using the global ‘isatap.domain.com’ DNS host record that is hard coded into all Windows Vista+ systems, and use a custom ISATAP router name that is specific to your environment. With this DNS host record created, all we need to then do is enabled specific clients to use this custom ISATAP router name and we have a mechanism of controllers ISATAP on our terms.
Please Note: An alternate approach using HOSTS files is feasible for very small deployments, but this has limited scalability and does not allow for the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a UAG DirectAccess array. Therefore this approach is not recommended outside of a lab environment.
In my opinion, the best way to achieve this technically is by way of Group Policy and a dedicated Windows security group for manage out clients, as follows:
Step 1: Create a Custom ISATAP DNS Record
Create a new DNS record called [something]isatap.domain.com, or similar.
Step 2: Create a Windows Security Group
Create a new Windows security group called UAG DirectAccess Manage Out Clients. or similar.
Step 3: Create a New Group Policy
Using GPMC, create a new group policy object called UAG DirectAccess: Manage Out Clients (Enable ISATAP) or similar, with the following properties:
Under the Scope tab, remove Authentication Users from the Security Filtering section and add the Windows security group created above; UAG DirectAccess Manage Out Clients in our example.
Under the Details tab, set the GPO Status to User configuration settings disabled
Edit the newly created GPO and define the following settings:
Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies
ISATAP Router Name: Enabled
Enter a router or relay name: [something]isatap.domain.com
ISATAP State: Enabled
Select from the following states: Enabled State
Once completed, this should result in the following output in the Settings tab:
Step 4: Add Computer Accounts to Windows Security Group
All that now needs to be done is to add the computer accounts for machines that will be used for remote management of DirectAccess clients to the UAG DirectAccess Manage Out Clients Windows security group.
Please Note: It will be necessary to reboot clients and servers after adding them to the UAG DirectAccess Manage Out Clients windows security group before the new GPO will be applied.
Once this has been done, the specific manage out clients that you have defined by group membership should now receive an ISATAP addressing and prefix information making them IPv6 capable.
Once configured correctly, you should receive a 2002:WWXX:YYZZ:8000:5efe:w.x.y.z format address (or similar) on the ISATAP adapter and will be able to remotely manage DirectAccess clients from this predetermined group of manage out machines.
Please Note: If the ISATAP adapter address assignment is not successful, it may also be necessary to use the following command to refresh the adapter state: sc control iphlpsvc paramchange
Hope this helps!
Nice article keep updating
ReplyDeleteGreat article, JJ.
ReplyDeleteI implement ISATAP to my customers in exactly the same way :)
That is far more elegant and manageable than individually modifying HOSTS files. Thanks!
ReplyDeleteI thought so! ;)
ReplyDeleteFantastic post Jason. Do we still need to remove ISATAP from global query blocklist on DNS server???
ReplyDeleteThanks - no, there is no need to remove a custom ISATAP entry from the DNS blocklist as only things like ISATAP and WPAD are blocked.
DeleteExcellent! Do you still need to register the address in DNS for the VIP and both DIPS for NLB configuration?
ReplyDeleteYep, same DNS requirements, just a custom name...
DeleteGood One.
ReplyDeleteAny issue applying making this group policy change in the GPO that is created for the DIrectAccess Client machines as part os UAG config?
ReplyDeleteYes, as customisations will get overwritten next time you apply changes in the UAG console...use a custom GPO
DeleteYou could just next the new ISATAP Manage out group inside the group you use for DA Clients as well. That should "stick" since the group doe not get recreated right?
DeleteNo really, as the groups defines what can do the managing, not what is being managed...
DeleteThis may sound stupid but where does the ISATAP DNS Record need to point?
ReplyDeleteTo the Ip address bound to the UAG internal interface
ReplyDeleteIf using an array it needs to point to the internal interface VIP and all array member dedicated ip addresses
DeleteIPv6 or IPv4 address of internal interface?
DeleteCould this solution also be implemented regarding Direct Access 2012?
IPv4 addresses
DeleteYes the same solution works for DA 2012 but MS recommended moving to native IPv6 not ISATAP
Tnx Jason I could not find any good article regarding manage out vs DA 2012.
DeleteIn what way?
DeleteI could not find out these "small" answers that I needed.
DeleteLike, what IPv6 address should SCCM use?
example:
da server - 2002:c2f7:dc1a:3333::1
sccm - 2002:c2f7:dc1a:3333::2
is this config ok?
I used this guide to setup ISATAP for my DirectAccess clients and I pointed the ISATAP to my DirectAccess Server. It seems work work pretty well.
ReplyDeleteThank you very much for the guide! I can now communicate with my DirectAccess clients.
FYI: I am running a full Server 2012 and Windows 8 Environment. Loving it!
I am understanding, if I want to use External Load balancer; I need to deploy external ISATAP router before DA deployment. Will that external router will be a single point of failure? what kind of architecture people following for this?
ReplyDeleteI believe that is the recommendation, but I have heard the single point of failure concern before. Let me ask around to find out what is best practice...
DeleteShould it be computernameisatap.domain.com or computername.isatap.domain.com pointing to the DA Server?
ReplyDeleteIt doesn't really matter as long as though it resolves the name the correct place and you have defined it in group policy. However, I would use .domain.com and keep the domain the same as your clients primary DNS suffix.
DeleteHow would this work if I have 2 DA arrays? We cant do stretched VLAN on internet side and hence are deploying 2 clusters in 2 data centres for 50% of the clients each.
ReplyDeleteIf the helpdesk are in this policy how will they get out to the clients if they resolve to the array that the client is not currently connected to or vice versa?
Thanks
Things get a bit more complicated with dual data centres as you need to look at using dedicated ISATAP routers and thinking about IPv6 in a bit more detail. The following may also help: http://www.windowsnetworking.com/articles_tutorials/configuring-isatap-router-windows-server-2008-r2-part2.html
DeleteThanks, can you expand on that at all? Is it even possible?
DeleteNot really, as I don't have any specific experience. Multi-site DA has only recently become possible with DirectAccess 2012 so it is still quite early in terms of practical multi-site experience...
DeleteP.S. With DirectAcces 2012 multi-site, MS are not recommending the use of ISATAP anyhow and say people should be using native IPv6.
DeleteA couple of questions:
ReplyDelete1) Which machines need to go into the ManageOut group? Obviously the machines that will be outside the perimeter, but you seem to imply that servers will need to be in it as well.
2) I'm managing a transition from an older server to a newer server with UAG on Win2k8 R2 for both. The old implementation uses isaptap.example.com, and I've set up us-isatap.example.com as a replacement, but isatap.example.com can't go away while I'm setting up the newer machine. In light of question 1), how might you handle this?
Thanks,
Kurt
Hey Kurt,
DeleteA1: Any machine that needs to initiate an outbound IPv6 connection with a DA client will need to be in the group. This could include internal client or internal servers; but should not include the UAG servers themselves.
A2: The two solutions should co-exist just fine as clients that don't receive the GPO will just use the default FQDN. Those clients that do receive the GPO will use the custom FQDN. This is the beauty of using this method as it is client targeted.
OK - trying to wrap my head around this...
ReplyDeleteSo, my Win2k8R2 DCs need to be in it, as well as my WSUS, Antivirus and other servers? Won't that interrupt communication with the old installs?
Kurt
No, manage out is all about "outbound initiated" connections when you want to use RDP or remote assitance to reach your DA clients. This is nomrally only needed from servers like SCCM servers or terminal servers than run your management tools. If you just need to access DA clients from a couple of internal machines to "manage out" to them, then just add these to the ISATAP GPO group.
DeleteThings like WSUS are actually inbound as the clients "pulls" data from the server and opposed to the server "pushing" out...
Hope that helps!
OK - that makes decent sense. I don't think we'll need to probe for new machines from the AV server, or things like that.
ReplyDeleteThank you for the explanation.
Kurt
very good article
ReplyDeleteJason, I have a question regarding manage out clients.
ReplyDeleteYou said "DA 2012 MS recommended moving to native IPv6 not ISATAP", so if I get it right, I have to add IPv6 address to SCCM server.
Example:
da01 - 2002:c2f7:dc1a:3333::1
sccm - 2002:c2f7:dc1a:3333::2
Am I right? :)
Tnx in advance
Yes, you need to provide static IPv6 addressing as appropriate for your network. This assumes your network is IPv6 ready of course...
DeleteHi Jason
ReplyDeleteI am planning to deploy DA in. 2 sites in the US and UK and they are on the same single domain.
Is it possible to create 2 DNS entries for ISATAP, say usisatap.xxx.com and ukisatap.xxx.com and filter the gpo to the the relevant machines that require to manage out depending on where they are located to ensure they use their local DA server?
Yes, that will allow you to ensure that clients receive the ISATAP address from a known (closer) location, but it doesn't guarantee that traffic will exit from the correct gateway and that is down to routing, not address selection...
ReplyDeleteThanks Jason. It looks like the actual resolution is to implement border routers but I am looking for an easier way around this :-)
ReplyDeleteThanks
Thanks Jason...This worked just perfect!
ReplyDeleteBart Timmermans
Hi Jason
ReplyDeleteJust testing this with 2012 DA. When enabling NLB the pre-req check ensures that ISATAP is present in DNS for all internal IP addresses.
If you name the dns entry isatap.domain.com it doesn't recognise the name. Looks like you can only use the name ISATAP.
Do you know if there is a work around such as renaming the DNS entry afterwards or just using the DNS name ISATAP but not enabling it on the DNS servers?
Thanks
Hmmm...maybe putting a ISATAP reference in the hosts file would be enough to trick/satisfy the pre-req checker...guess it depends on how thorough the test is...putting the native ISATAP DNS name with a fake IP address (to prevent clients from receiving addresses) may also be enough to pass the check...
DeleteCheers Jason, I will test this.
ReplyDeleteHello Jason,
ReplyDeleteExcellent article! I have installed DA in a 2008R2 AD environment. We are using Win 7 ENT clients. It was very straight forward install. Shortly after installation our logon times increased to 3 -5 minutes internally. I fully suspected the ISATAP/DNS issue.
I followed your article and the logon times returned to normal. Now my external DA clients now take 3 -5 minutes to logon and the shares no longer are present.
One point is that our External Authorative DNS is no an AD DNS. It is hosted on a SUN server.
Do you have any ideas?
Thanks VERY much.
ISATAP is irrelevant when the client is external, so shouldn't be that - what machines did you put into the management clients group as these normally wouldn't include the actual DA clients themselves...
DeleteHello Jason,
DeleteI have the Direct Access server and the Network Location Server. I don't have the AD/DNS or the File servers in there as I assumed that latency was due to AD/DNS servers were the issue.
Should these servers be members?
Thanks VERY much Jason...
Todd
Hi,
ReplyDeleteIf you have a back firewall between corpnet and DA servers what do I need to configure for this to work.
I belive its Protocol 41 but between which IP's? IP 6 IP's or IP 4?
If I add the IPv4 helpdesk subnet with a destination to the internal IP4 nics of the DA servers will that do the trick?
ISATAP is essentially IPV6 encapsulated in IPv4 so you need to define all ACLs using IPv4 addresses. Yes, IP protocol 41 is required through the back firewall between the management clients and the DA server internal interfaces.
DeleteI am trying to get domain isolation to work with DA but have no success.
ReplyDeleteI Think the problem now is that DA server (2012) travers ipv6 to ipv4 and then the ipsec transport (isolation) fails.
When I connect to internal host from DA client and do a netstat I see that the DA client Connection is established to internal host with the DA server IPv4 adress.
regards Jonas
Hi Jonas,
DeleteIn DirectAccess 2012, when using ISATAP, you need to enable AAAA queries for DNS64 with the PowerShell cmdlet, Set-NetDnsTransitionConfiguration -OnlySendAQuery $false
This may be the cause of your problems...
Cheers
JJ
Thanks a lot now i am able to have both side communication between sccm and DA Client. Started working on further scenario like client push and updates.
ReplyDeleteParth, what version of Direct Access are you using? I am planning to implement in my environment with a preexisting DA 2010 setup using SCCM 2012 R2. If you could provide me your steps and any issues you may have experienced during the implementation, would be helpful. Thanks!
Delete