On Thu, Feb 7, 2013 at 10:28 AM, Jeremiah Rumball <[email protected]> wrote:
> Hi all,
>
> We are looking into Direct Access as a possible solution for one of our
> clients. Do any of you have some real world experience with it? Are there
> any pitfalls to watch out for?
>
> Thanks!
>From an earlier note I sent to this list - edited a bit, and
especially see the note at the end:
The clients must be Win7 or Win8, Enterprise or Ultimate. Nothing
else. If your intended clients are Pro, or an earlier OS, look to
something else.
For the server, it requires either Server 2008 R2 with UAG, or Server
2012, no UAG needed.
The 2008 R2 with UAG requires a working PKI for its clients, but the
2012 version only requires a working PKI for Win7 clients.
Someday MSFT might not require the Enterprise version of the clients -
that would be really outstanding, but I'm not holding my breath...
One big limitation of the DirectAccess technology is that it is a pure
IPv6 solution. However, when I say pure IPv6, I mean that it tunnels
IPv6 over IPv4, and the client applications don't know the difference
- as far as the applications are concerned, the IPv4 stack still
exists, and badly written apps can try to talk to that stack, instead
of making more generic calls to the networking stack and letting the
OS handle communications. If you have client software that makes
explicit calls to the IPv4 stack, you're screwed (Lync 2010 and
Shoretel client, I'm looking at you).
IME, the 2008 R2/UAG version is tedious and a bit tricky to set up - I
haven't yet played with the 2012 version, which is supposed to be much
simpler.
But, other than that, it's a way cool technology - no extra logins
required, once the GPOs take effect, you just open your laptop, turn
it on, log in as if you were in the office, and you're off to the
races, subject to the limitations of your connection speed.
However, a caveat - Things Can Go Wrong...
o- I've had one guy whose DirectAccess has fallen down, and haven't
figured it out yet - I haven't had a chance to get my hands on the
laptop to diagnose it. The output of 'gpresult -h' was interesting,
showing some odd missing stuff in the applications of the GPOs, but I
couldn't reach any firm conclusions.
o- I was able, from home, using a connection via an SSL VPN tunnel,
first to get a brand spanking new corporate machine joined to the
domain, then to get the GPOs to load on it ('gpupdate /force' and then
a reboot), and it worked great. However, I've got one remote worker
whose machine was joined to the domain a long time ago, and it doesn't
seem to be able get the GPOs applied properly. The results from
'gpresult -h' are also very interesting, but not conclusive - and
specific to problems with his TCP/IP stack, but I haven't been able to
pin him down to finalize troubleshooting for him, either.
On the whole, though, I'm glad I turned it up. I'm also glad we have
an SSL VPN appliance for fallback - it's mostly for staff to work from
home on personal machines, but for the applications that are stupid,
and for backup if DA falls down, it's pretty essential.
Kurt
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin
