Tag Archives: DAC

Accessing load balanced Exchange 2010 through DirectAccess

In almost all cases, once DirectAccess connectivity is established, Outlook’s connection to Exchange inside the network starts working instantly over the IPsec tunnels, without any special considerations. There is one exception that I have come across a few times, and that is when running multiple Exchange 2010 servers that are load balanced. In such implementations, Outlook often cannot establish a connection to Exchange over the DirectAccess tunnels. This happens because TMG recognizes that the IP address of the CAS response doesn’t match the source IP for the load balancer, and TMG decides to drop the traffic.

Thankfully, there is an easy fix! Simply run the following script on your DirectAccess gateway(s) and then restart it, and Outlook should start connecting for your users:

    Dim oFPC
    Dim oFirewallFilter
    Dim oVPS 

    on error resume next


    Set oFPC = CreateObject(“FPC.Root”)

    ‘Get the filter admin object
    Set oFirewallFilter = oFPC.GetContainingArray.Extensions.ApplicationFilters(“{E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}”)
    if oFirewallFilter is nothing then
         Wscript.Echo “RPC filter ({E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}) is not installed in array”
    end if 

    ‘Get the filters vendor parameters set object
    Set oVPS = oFirewallFilter.VendorParametersSets(“{E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}”) 

    ‘If this vendor parameters set does not exist, create it
    If oVPS Is Nothing Then
         WScript.Echo “Adding vendor parameters set ({E331F638-AB86-4AA5-9B6A-2B0248C7B4FB})”
        Set oVPS = oFirewallFilter.VendorParametersSets.Add(“{E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}”,False)
    End If 

    ‘Add the needed parameters 

    oVPS.Value(“AllowAuthEndpointMapper”) = 1  


    ‘Inform the user of the result
    if err.Number <>0 then
         Wscript.Echo “Fail to set parameters. error code is:” & err.number & ” Desc:” & err.description
        Wscript.Echo “Paramters were successfully added”
    end if

Jordan Krause

Enabling or disabling the DirectAccess adapters for testing (6to4, Teredo, IP-HTTPS)

I have been asked a few times lately what method can be used for enabling or disabling certain Transition Technology adapters for testing purposes. The three transition technologies used by DirectAccess are called 6to4, Teredo and IP-HTTPS, and sometimes it is helpful to pin your client machine down to a particular one to test something out. Here are some methods you can use to enable or disable these adapters selectively on your client machines:


If you are working with a single machine where you don’t mind doing some manual commands, there are some simple netsh statements you can make to enable or disable the 6to4 interface:

netsh interface 6to4 set state disabled (disables 6to4)
netsh interface 6to4 set state enabled (enables 6to4)

If you need to accomplish this on a wider scale, you can use a GPO instead:

Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies
6to4 State = Enabled or Disabled


Once again, there are some easy netsh commands if that is your preference:

netsh interface teredo set state disabled (disables Teredo)
netsh interface teredo set state client (enables Teredo and sets it to the default “Client” status)
netsh interface teredo set state enterpriseclient (enables Teredo and sets it to “EnterpriseClient” status – this is my recommended state for Teredo on all of your DirectAccess client computers, as it allows Teredo to connect in more situations, like a client’s domain network)

Or, you can do it via GPO:

Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies
Teredo State = Enabled or Disabled (and you can also choose Client or EnterpriseClient)


This one’s a little trickier. There are no netsh commands to enable or disable IP-HTTPS, unless you wanted to point it at a dummy location but that works against the DirectAccess GPOs. So there are two ways I have done it before:

  1. Disable it in Device Manager:
    1. Open Device Manager, click on View and click “Show hidden devices”
    2. Under Network adapters, you will see the “iphttpsinterface”, which you can disable or enable as with any other adapter
  2. Disable it in the Registry:
    1. HKLM\Software\Policies\Microsoft\Windows\TCPIP\v6Transition\IPHTTPS\IPHTTPSInterface\IPHTTPS_ClientState
      To disable the interface, set the value to 3
      To enable the interface, set the value to 0

Jordan Krause
IVO Networks

UAG SP2 is now available for download

Surprise! I know that many had expected the next update released for UAG to be SP1 Update2, but instead we are going straight to SP2. This update not only resolves a list of issues that some customers have called into Microsoft about, but also comes with some added support for newer mobile client devices, and has some significant changes to the way that UAG works with ADFS.

Download it here

Installation instructions

As with any update to the UAG or TMG platform, we recommend launching the installer from an elevated command prompt. This Service Pack also includes some considerations to be taken for the current status of your UAG and TMG versions. Before running the SP2 installer:

  • Make sure UAG is running at least SP1 Update1
  • Make sure TMG is running at least SP2

List of new features (http://support.microsoft.com/kb/2710791 for the whole list)

  • Improved SharePoint 2010 support
    Forefront UAG 2010 SP2 lets users authenticate to a trunk by using Microsoft Office Forms-Based Authentication (MSOFBA) when the trunk uses Active Directory Federation Services (AD FS) 2.0 for authentication.
  • Improved Active Directory Federation Services 2.0 support
    You can provide remote and partner employees with access to published applications that have AD FS 2.0 enabled. For example, you can do the following:

    • Use AD FS multi-namespace support: Multi-namespace support for AD FS 2.0 lets you use a single AD FS 2.0 server that has multiple Forefront UAG trunks when the fully qualified domain names (FQDNs or public host names) of the trunks are in different domains. For example, the FQDN of the first trunk is portal.contoso.com, and the FQDN of the second trunk is portal.fabrikam.com. Both trunks can be configured to perform AD FS authentication by using the same AD FS 2.0 server (sts.contoso.com). In this kind of deployment, the AD FS 2.0 server is published through one of the Forefront UAG trunks or by an AD FS proxy that is parallel to Forefront UAG.
    • Use the AD FS proxy to publish the AD FS 2.0 server: Publishing the AD FS 2.0 server by an AD FS proxy has many advantages over publishing the AD FS 2.0 server through Forefront UAG. These advantages include support for Office 365 authentication and mobile devices.
    • Enable complex topologies: You can use Forefront UAG to publish a SharePoint website that is located in one site when the AD FS server is located in another site.
  • Added client devices
    Forefront UAG 2010 SP2 lets users connect from the following mobile devices:

    • Windows Phone 7.5
    • iOS 5.x on iPad and iPhone
    • Android 4.x on tablets and phones

PING over ISATAP results in General Failure

I was recently working to enable selective ISATAP for a UAG DirectAccess customer, and ran into a problem that I wanted to share. We had completed the work of setting up a custom DNS record to use for ISATAP, and had created a group and GPO to contain the ISATAP clients and settings. The DA client GPO for the firewall settings was also already in place, set to allow RDP and File access from the ISATAP prefix. All in all, everything appeared to be in order, and all we had to do was start adding internal computer accounts into the ISATAP clients group to get this working.

We added our first computer account, rebooted, and received an ISATAP IPv6 address. Good news right?! Then we tried to RDP into a DA client, and it timed out. Hmm, could still be a number of different things wrong at this point I guess. What was especially strange though and something I had not seen before was that when trying to ping DirectAccess client computers from the ISATAP client, we could resolve the IPv6 addresses but the pings resulted in “General Failure” – indicating some kind of routing problem. We decided to enable another internal client as an ISATAP client and try to route between the two ISATAP hosts, and got the same thing. Packets were not successfully routing in the ISATAP environment. Now I have never, ever had to adjust or troubleshoot ISATAP settings on one of our DirectAccess Concentrator appliances before, they always just work. So I was doubtful that there was anything I could change on the server side that would make this better.

We were just starting to dig deeper into ipconfig and route statements when the customer I was working with decided to try changing some settings in their Symantec Endpoint Detection, and voila! Everything started working. I have struggled with SEP in working with DirectAccess implementations numerous times in the past, but always on the external side of the connection. Symantec is very good at blocking things that are needed for a successful DirectAccess connection to happen from outside of the network, but this is the first time I have had it interfere with ISATAP connectivity from the internal network. Since the ISATAP clients were able to get an IPv6 address successfully, this sounds eerily similar to the situation where many cell card carriers allow the initial handshake to happen for 6to4, but then block IP Protocol 41 (the same thing used by ISATAP) which causes DirectAccess not to work over many cell data cards until you disable the 6to4 adapter. It looks like the same situation here, Symantec was allowing initial contact and granting of an IP address, but then was blocking all traffic attempting to flow over ISATAP.

So lesson learned: Whenever there are routing problems in the DirectAccess world, look for the existence of Symantec Endpoint Protection. I shouldn’t really say that, as really it could have been any kind of local firewall, or a network firewall that could have caused this same behavior. It just so happens that I have seen many more cases of failed IPv6 communications caused by SEP than any other platform.

Jordan Krause
IVO Networks

DirectAccess – Help! I’m drowning in certificates

PKI is traditionally the trickiest part of DirectAccess installations for companies. The problem is not that there are major requirements that involve a complicated configuration, but rather that there is no clear guidance available to “Joe Admin” on what is and is not needed to make DirectAccess work.

There are three places where certificates are involved in a DirectAccess configuration:

1.  SSL certificate for the NLS website

A major part of the way that DirectAccess works is your Network Location Server (NLS) website. This is simply a website running inside your corporate network that the DA client machines are going to query. Basically, if they can see it they determine they are inside the corporate network, and if they cannot see it they determine they are outside of the corporate network. The NLS website is a very simple requirement, the only special instruction on creating the site is that is must be HTTPS with a valid SSL certificate so that it cannot be spoofed. This certificate gets installed onto whatever web server you are using in-house to host the NLS website. The only machines that are going to be accessing this website are your corporate DA computers, therefore the SSL certificate does not need to be one that was purchased from a public CA (though it can be if you choose), an SSL certificate generated from your internal CA server will work just as well, since all of your domain-joined corporate machines should already be configured to trust this CA.

2.  SSL certificate for the IP-HTTPS listener

6to4 and Teredo connect without utilizing SSL, so many of your client connections are not relying on this certificate. However, when a DA client fails to connect using 6to4 or Teredo, they will fall back and try to connect using IP-HTTPS. IP-HTTPS traffic is required to be authenticated as SSL traffic, and therefore requires a valid certificate installed onto the UAG/DirectAccess server. For this certificate I absolutely recommend going out and purchasing one from your public CA of choice. Doing so allows them to retain responsibility for publishing the CRL and managing that certificate for your external users. It is technically possible to use an SSL certificate from your internal CA server and publish the CRL publically, but I have seen so many people on the forums attempt and fail at doing this that I wouldn’t even bother trying. Once this certificate is installed into the store on the UAG/DA server, you choose for UAG to utilize the certificate from the “IP-HTTPS Certificate” screen inside Step 2 of the DirectAccess configuration wizards.

3.  Machine certificates for the IPsec tunnels

This is the part that most admins are not familiar with. You must have a CA server running inside your corporate network, which will be used to issue machine certificates to all of the DirectAccess client computers, as well as all of your DirectAccess gateway servers. When you install the CA server role onto a Windows server, it installs some default certificate templates. One of those templates is called the “Computer Template”, and this is the one that I recommend using to issue your DirectAccess certificates from. You don’t need to modify anything with this template, simply issue certificates to all of the machines involved based off this template and you’re in business. You can issue certificates manually if you so choose, by requesting them from inside the certificates MMC snap-in (make sure to snap-in the “Computer account” templates instead of User), or you can automate the issuance of your certificates by setting up AutoEnrollment inside Active Directory. Once your certificates are in place on the server and the clients, you configure this part on the next screen inside Step 2 of the UAG DirectAccess configuration wizards, “IPsec Certificate Authentication”. Simply choose the CA server that you use to issue these certificates.

If there is a reason that you do not want to utilize the default Computer template, you can create a custom template and use it to issue certificates as well. There are four main requirements that you need to incorporate into your custom template:

  1. It must serve the intended purpose of Client Authentication
  2. It must serve the intended purpose of Server Authentication
  3. The Subject name of the certificate must be the CN of the machine (FQDN of the computer its being assigned to)
  4. The SAN (Subject Alternative Name) of the certificate must be the DNS Name of the machine (also the FQDN of the computer its being assigned to)

That’s it! Three places where certificates are required for DirectAccess. I hope this guide is helpful for your implementation, and as always if you have any questions or comments, please feel free to reach out to me directly.

Jordan Krause
IVO Networks

Defining UAG DirectAccess Acronyms and Technologies – 6to4 | Teredo | IP-HTTPS | ISATAP | NAT64/DNS64 | IPsec

Today I would like to identify some of the acronyms and explain the different technologies at work “under the hood” of Microsoft UAG DirectAccess. One of the great things about the wizard-driven nature of configuration in DirectAccess is that you don’t necessarily need to know what is going on in the background, but most DA Admins will want to explore and understand the underlying technologies at some point. Why not today?

Let’s start with the client side of the connection. When a DirectAccess client computer connects to its DirectAccess gateway in the corporate network, it chooses one of three transition technologies to establish a tunnel. A transition tunnel is needed because DirectAccess packets are IPv6 packets, but most of the internet today is still IPv4. So each of the three client-side transition technologies – 6to4 | Teredo | IP-HTTPS – each work to accomplish the same goal: Encapsulate the IPv6 packets inside IPv4 headers so they can be transmitted over the internet.

The DirectAccess client computer attempts to establish a 6to4 tunnel first, but can only do so if the client’s NIC has been assigned an actual public IPv4 internet address. This is not a very common scenario, the most common situation where you might find yourself with a public IP address is when using a broadband card provided by a cellular carrier. I have seen some hotels issue public IPs to computers inside their network as well, though this is rare and I expect it will become increasingly rarer in the future. 6to4 uses IP Protocol 41 as its transport method, and occasionally cell carriers will block Protocol 41 on their networks which means 6to4 cannot function anyway. This potential problem that would result in a helpdesk call combined with the rareness of 6to4 being used in the first place leads me to recommend as a best practice disabling the 6to4 interface on all of the DA client computers via GPO. One other point to add to this is that if/when you move to a multi-site DirectAccess deployment (multiple DA gateways in different locations) you must disable 6to4 anyway.

Teredo is the most common connectivity method for DirectAccess clients. It attempts to connect whenever a DA computer is sitting behind a NAT. For example, when you are sitting at home and you have received a “192.168.something” address from your home router. One recommendation I always make during installations is to use a GPO (same GPO as the one that disables 6to4 perhaps) to set your Teredo State to “EnterpriseClient” on the client machines. By default Teredo runs in “Client” state and will not connect if the computer is sitting inside of a domain network. Sometimes users plug into clients or other business networks, or sometimes users have domains on their home networks, and setting Teredo to EnterpriseClient allows Teredo to connect when inside a domain network. Teredo does the same job as 6to4, encapsulates IPv6 packets inside IPv4 headers, but Teredo uses UDP port 3544 for its transport. Therefore, if you are sitting behind a port restricting firewall that doesn’t allow UDP…

This is the method of last resort for creating a transition tunnel for DirectAccess. IP-HTTPS takes the IPv6 packet, encapsulates it inside an IPv4 header, and then throws that inside an HTTP header that is encrypted, creating an SSL traffic stream. This enables DirectAccess traffic to make its way successfully through port restricted firewalls (even a firewall where only HTTPS traffic is allowed), but is the method of last resort because you are essentially encrypting every packet twice, once with the standard DirectAccess IPsec encryption and then again with the SSL encryption. So this is a less efficient protocol, which is really the only reason that it is not the one and only protocol.

The Intra-Site Automatic Tunnel Addressing Protocol is also an IPv6 transition technology, similar to the three mentioned above. Its job is also to encap IPv6 packets inside IPv4 headers, but the main difference is that ISATAP is for use INSIDE your corporate network. UAG contains a great feature – NAT64/DNS64 – that converts the IPv6 packet stream into IPv4 for application servers and networks that do not understand IPv6 (more on that later) but occasionally you may have the need to make an outbound initiation from the internal network out to a DirectAccess connected client machine. The most common example of this is a Helpdesk PC trying to RDP into a DirectAccess laptop. When you want to generate a true outbound initiation like this, when the Helpdesk personnel punches “CLIENT1” into the RDP client, their PC is going to ask DNS how to get to CLIENT1. DNS is going to respond with the IPv6 address that the DA computer is currently connected with, and then that Helpdesk computer has to have an IPv6 layer of connectivity to be able to establish that connection. If you have native IPv6 inside your network then great, you don’t need ISATAP. If you do not have native IPv6 inside as most companies do not, you can use ISATAP to create a “virtual IPv6 cloud” inside your network. Your UAG box will act as an ISATAP relay which you can think of as an IPv6 DHCP server. You configure your Helpdesk PC to point at the UAG server for its ISATAP configuration, and it gets assigned an ISATAP IPv6 address. Then when the RDP connection takes place, those packets stream over the ISATAP connection (which is taking the IPv6 packets and putting them in IPv4 headers so your internal network and routers don’t need to know anything about IPv6) and those packets can then make their way successfully outbound to the DirectAccess client machine.

Note: Neither native IPv6 or ISATAP are required for a successful UAG DirectAccess implementation. Many management functions like Group Policy updates and patches for the DA client computers are actually “pulls” not “pushes” and therefore the management servers inside the network don’t actually need outbound access to these client computers as they are simply responding to the “pull” request that was initiated by the client. Those pull responses will happen successfully without any form of IPv6 connectivity inside the office.

NAT64 / DNS64
These two technologies (pronounced “NAT 6 to 4” and “DNS 6 to 4”) are included with UAG and are the mechanisms used to make your IPv6 DirectAccess packets be able to successfully contact IPv4 application servers inside your network. When your Outlook requests “EXCHANGE01” the DA client will ask your UAG appliance how to contact EXCHANGE01. UAG in turn asks DNS. If DNS responds with a AAAA (IPv6) record, UAG passes that along to the client who is happy to simply use the IPv6 record for communications back and forth. However, if EXCHANGE01 is a Server 2003 that doesn’t know anything about IPv6, DNS is going to return a regular A record which the DirectAccess client computer doesn’t know what to do with. Therefore, when DNS64 in UAG realizes that it’s talking to an IPv4 host inside the network, it creates a “fake” IPv6 address on the fly and returns that address to the DA client instead. Then DNS64 and NAT64 combine to create a transport method between client and server, where the client always thinks it’s talking to an IPv6 server, and the server always thinks it’s talking to an IPv4 client. There is nothing to configure to make this work, it simply does. It’s a beautiful thing!

One thing I didn’t discuss is the actual encryption of the DirectAccess traffic. Of course an IP-HTTPS stream would be SSL encrypted, but you obviously wouldn’t want clear-text packets flowing through the internet inside a UDP tunnel when connected over Teredo! Therefore regardless of what transport method the client chooses to connect with (6to4, Teredo or IP-HTTPS) inside that transition tunnel are IPsec tunnels which are carrying the actual packets the client is sending and receiving. In a typical DirectAccess implementation there are two IPsec tunnels at work on every DirectAccess client. The first is called the “Infrastructure Tunnel” and is a tunnel that is automatically established based on computer account and certificate authentication. This first tunnel is restricted only to your management servers. Domain controllers so that the user can successfully authenticate and so that Group Policies can be pulled down, and then whatever other management servers inside your network that you might want to have access to the DirectAccess client computers prior to user authentication. Then once user authentication does happen, a second IPsec tunnel is established based on both computer certificate and user authentication and this second “Intranet Tunnel” carries all of the user driven traffic.

There are potentially many more acronyms that we could discuss here. Things like NLB, NAP, OTP, etc etc. Those items are a little bit more generic and though they do have specific tie-ins with DirectAccess, I think I’ll leave it at that for today. As always, please feel free to reach out to me directly if you have any questions.

Jordan Krause
IVO Networks

Using DirectAccess for remote offsite backups

Here’s an interesting idea. The “Cloud Backup” business seems to be expanding rapidly, I stumble upon new ones all the time always toting the same message – “Keep your data backed up here for $X per month”. Sounds great, but the problem is that $X per month usually turns into $10X or even $100X per month once you realize how much data you actually own and would cry over if you lost.

So why not create automatic, offsite backups for yourself? FOR FREE

I’m a Microsoft DirectAccess enthusiast, and as such I am always trying to keep my eyes open for new ways in which it can be used to make life easier on IT. This is absolutely one of those areas. If you have DirectAccess, you already have the infrastructure needed to establish a remote backup site – at any physical location of your choosing. All you have to do is:

1. Build out your backup machine – This can be a desktop, laptop or server and it can be running Windows 7 or Server 2008 R2 (yes, Server 2008 R2 can also be a DirectAccess client).

2. Enable DirectAccess on this machine – Add this new machine to your Security Group or OU for DirectAccess so that it receives the DA connectivity settings and the necessary certificate from your CA server.

3. Move the machine to a remote location of your choosing.

That’s it! As long as the machine gets internet connectivity at the remote location it will establish itself some DirectAccess IPsec tunnels, and you will have a 24x7x365 connection to your new offsite backup server. You can now use whatever backup methods you choose, and push the results at this offsite machine just as if it were another machine sitting inside your corporate network.

Keep in mind that as with any DirectAccess client, you will need to create Firewall rules that allow the necessary ports for whatever backup method you are using. I recommend doing this with a GPO. Create a new one, add the inbound firewall rule or rules to it, and assign it to this client machine. For example, if you are using a backup utility that simply needs access to be able to push files at a file share that is running on the offsite backup server, open up TCP 445 inbound and you should be all set.

This method for offsite backups could prove especially helpful for businesses that do not have a second location or if they do it may not have an expensive WAN link keeping the two connected. This offsite backup server could be placed anywhere, at an employee’s home for example. You will have complete management access of this backup server at all times because it is connected via DirectAccess. You can push patches and GPO settings at it, remotely control it, whatever you might need to do to ensure safety and security of your data.

Jordan Krause
IVO Networks

Client-side IPv6 and DirectAccess don’t always get along

A handful of cases have rolled across my desk recently involving laptops that will not connect via DirectAccess from particular internet connections. In working on these cases I discovered a commonality – all of the laptops in question were being assigned a native IPv6 address onto the NIC in addition to the expected IPv4 address:

Some of these laptops were getting this IPv6 address from a home router, and some were getting an IPv6 address assigned to them by a new 4G card that the user had recently acquired. The clients were also getting an IPv6 address for Teredo or IP-HTTPS, but the problem showed up near the bottom of the DirectAccess Connectivity Assistant logs:

The DirectAccess IPsec tunnels (at least some of them) were attempting to establish themselves using the native IPv6 address instead of the Teredo/IP-HTTPS addresses. The resolution to the problem on all machines was to disable that native IPv6 address from being assigned to the laptops. Since we didn’t want to try walking the users through reconfiguring their home routers we unchecked TCP/IPv6 from the NIC properties and that took care of it for the home users:

And for the 4G card users we found a setting in the software for the 4G card – it was basically just a checkbox for “IPv6” that the user was able to uncheck and the next time they connected with the 4G card, it issued only an IPv4 address, not an IPv6 address and then the tunnels established correctly over Teredo/IP-HTTPS.

The official word from Microsoft is that client-side IPv6 is supported, but after reviewing the details of these cases they agreed that the best solution to this issue is to simply stop those native IPv6 addresses from being assigned to the client machines.

Jordan Krause
IVO Networks

UAG SP1 Update 1 including UAG hotfix is available

Update 1 for UAG SP1 has been released and is ready for download on IVO Networks appliances. Some of the changes contained in this update are:

-          Lync web services publishing

-          Dynamics CRM 2011 publishing

-          SharePoint 2010 with Office Web Apps

-          Improved browser support

Full details are available here – http://technet.microsoft.com/en-us/library/hh490321.aspx

Additionally, UAG SP1 Update 1 includes the recently released MS11-079 security update.

Download Update 1 here – http://www.ivonetworks.com/downloads/uag_sp1_update1.zip

If you are running UAG before SP1, you cannot make use of this new update and therefore should install the standalone hotfix for MS11-079 which corresponds to your current UAG level. Visit the link below for a list of downloads available:


As always, please contact your IVO support engineer should you have any questions at all. Thanks!

Jordan Krause
IVO Networks

Multi-site UAG DirectAccess

Many companies have multiple datacenters. Depending on the organization’s needs, these datacenters will obviously have different purposes and ways that the users connect. In this article we are going to explore some of the ways that DirectAccess provided by UAG can be used across multiple entry points.

The traveling user connecting to a home datacenter:

Sometimes users travel, and you want them always connected back to their primary datacenter to reach their information. For example, you may have a US employee traveling to India, but their primary email and file servers are located in the US, and so when they are in India you would want DirectAccess to connect them back to their US datacenter. This is what happens by default, and there is nothing special whatsoever you would need to establish to make DirectAccess function like this. But maybe you also have a datacenter in India that is the primary location for email and files provided to India based employees. So your requirements are basically the same – you want US employees to connect to the US datacenter no matter where they are in the world, but you want India employees to connect to the India datacenter no matter where they are in the world. This “manual distribution of DirectAccess clients” is possible with UAG DirectAccess today. You can place a DirectAccess entry point in the US, and another DA entry point in India, and by utilizing separate GPOs for the client connectivity settings, you can create this scenario very easily by simply adding the US computer accounts to the “DA_Clients_US” group, and adding the India computer accounts to the “DA_Clients_India” group. If you ever had a need to move a laptop from one entry point to another, you simply move the computer account from one group to the other, and the next time that laptop receives its Group Policy refresh, it is automatically reconfigured to connect through the new entry point.

The traveling user connecting to geographically local datacenters:

What if you have traveling users that you would rather have connected through the datacenter in the local geographic region they are located? Unfortunately this is not a scenario that DirectAccess is (yet) capable of providing on its own, but with UAG in the mix it makes for a pretty easy solution to this requirement. Simply create a UAG portal in each of your datacenters that allows employees to login and have a VPN session created. So when that US user travels to India, they can launch a simple web address from their browser, login, and then have full network connectivity to the India datacenter. If for some reason they forget to establish this connection, their DirectAccess will still be connecting them automatically to the US datacenter where they can work like normal, as if they are still in the US office.

To summarize, I believe the need for scenario #2 where users have to connect to their geographically local datacenter is dwindling. With internet speeds being what they are today, even reaching “across the pond” is not a big deal. I would personally like my users continuing to connect through their usual point of entry and always having access to the same resources that they do from anywhere else, this is certain to reduce helpdesk calls. But, if ever there is some specific reason that users would be expected to connect to a datacenter other than their home, it is easily accomplished with UAG.

Jordan Krause
IVO Networks