When I’m between doing things that I sort of want to do, but not enough where I want to start on them right away, I’ll do a little ego surfing. If you haven’t heard the term “ego surfing”, it’s the act of going to your favorite search engine (or multiple search engines) and searching for the results returned on your name. I do this from time to time because, well, ahhh – for the same reason anybody else does it!

Today I was doing some ego surfing for someone else. That “someone else” in this case was DirectAccess. I wanted to see what the top search engine results were for DirectAccess using a number of search engines. On more than one search engine, I found an article that left me a little perturbed. The title of the article is Microsoft DirectAccess: The ugly truth. Now, I know that headline writers write outrageous headlines because they get more attention, but I felt that I needed to write a response to show that the ugly really isn’t there and that there is beauty in its place.

Microsoft UAG DirectAccess: The Beautiful Truth

In fact, when it comes to UAG DirectAccess, much of the ugliness is swept away and what we see is a real thing of beauty. Hence the name of this article Microsoft UAG DirectAccess: The Beautiful Truth. To find this beautiful truth about UAG DirectAccess, let’s take a look as some quotes from the Network World article.

“The following list of DirectAccess requirements comes directly from Microsoft TechNet:

• One or more DirectAccess servers running Windows Server 2008 R2 with two network adapters: one connected directly to the Internet, and a second connected to the intranet.
• On the DirectAccess server, at least two consecutive, public IPv4 addresses assigned to the network adapter that's connected to the Internet.
• DirectAccess clients running Windows 7.
• At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2.
• A public key infrastructure (PKI) to issue computer certificates, smart card certificates, and for NAP, health certificates.
• IPsec policies to specify protection for traffic.
• IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo, and 6to4.
• Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients”

Let’s look at each one of these:

• One of more DA servers running Windows Server 2008 R2 with two NICs: one connected directly to the Internet and one to the intranet. That’s still true – although the external interface does NOT need to be directly connected to the Internet – putting the UAG DirectAccess server behind a front-end firewall is fully supported.
• On the DirectAccess server, at least two consecutive, public IPv4 address assigned to the NIC that’s connected to the Internet. Well, we know that the external interface does NOT need to be connected to the Internet. However, we still need two consecutive public IP addresses to support Teredo.
• DirectAccess clients running Windows 7. That is true – the only systems that can act as DirectAccess clients are Windows 7 Enterprise and Ultimate, and Windows Server 2008 R2 (yes – the Windows Server 2008 R2 operating system can act as a DirectAccess client – which sets up for some interesting scenarios)
• At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2. If you have using UAG DirectAccess, you do not need a Windows Server 2008 SP2 or above domain controller or DNS server. So UAG debunks this “ugly” truth
• A Public Key Infrastructure (PKI) to issue certificates, smart card certificates, and for NAT health certificates. Yep, a PKI is required. But come on folks, everyone has at least a simple PKI in place already – too many Microsoft and non-Microsoft products and services require a PKI these days not to already have one in place. And the PKI requirements for UAG DirectAccess are very simple: use autoenrollment to deploy the computer certificates, use a web site certificate to assign to the Network Location Servers, and use a commercial certificate to assign to the IP-HTTPS listener. When it comes to certificates and PKI, DirectAccess requirements are on the “no-brainer” of the certificates food chain.
• IPsec policies to specify protection for traffic. Yes, you still need those, but when you run the UAG DirectAccess wizard, all of these policies are created for you. The amount of knowledge you need about IPsec to get a working UAG DirectAccess solution work is around, well – ZERO. The UAG DirectAccess wizard creates the IPsec policies and then if you want, will automatically deploy them to Group Policy (either a security group or OU linked GPO, it’s your choice) for you.
• IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo and 6to4. This is mostly true, but he left out IP-HTTPS .  Teredo, 6to4 and IP-HTTPS are used to tunnel IPv6 communications over an IPv4 Internet to connect to the UAG DirectAccess server. How much do you need to understand about these protocols? Of course, that’s up to you – but the only thing you really need to know is that if you have a firewall in front of the UAG DirectAccess Server, you should enable TCP port 443 inbound and outbound, UDP port 3544 inbound and outbound, and Protocol 41 inbound and outbound to and from the external interface of the UAG DirectAccess server. That’s it. The UAG DirectAccess wizards takes care of the rest, so don’t need to make it an avocation (or worse, a vocation) of trying to understand the intricacies of IPv6 transition technologies. The same is true of ISATAP (Intra-site Automatic Tunnel Addressing Protocol) – UAG configures itself automatically to be an ISATAP router. All you need to do is create a DNS entry and that’s pretty easy!
• Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients. We can debunk this one for UAG DirectAccess with one word NAT64/DNS64 (OK, maybe not one word). With the integrated NAT64/DNS64 feature built into UAG, there is no need to bring in any third-party solutions to provide transparent access to IPv4-only resource. Another example the Beautiful Truth of UAG DirectAccess.

Now that we’ve debunked many of the issues regarding DirectAccess for UAG, let’s take a look at another quote from the article:

“That is no small list of requirements. What it means is that to implement DirectAccess, I have to change, replace, or upgrade just about everything at my network edge. In addition to maintaining a public-facing firewall for Internet access, I have to add another direct-to-Internet server to act as the DirectAccess termination point. As servers are replaced and updated, I can see the enterprise eventually getting to the point where all of these things are already in place. But for most of us, this set of conditions can be a showstopper.”

Everyone already has a firewall at the edge of their networks. So, there’s nothing to add there. And, firewalls and NAT are not the same thing. All you need to do is create a small block of public addresses for the UAG DirectAccess server and route the connections through the firewall (firewalls still provide firewall protection without NAT) – so there’s nothing to add there when it comes to hardware, and subnetting is pretty easy for the network guys. Yes, it is true that you need to add the DirectAccess server as an Internet facing device – but you already have a lot of those, so what’s one more? Again, this is something most network admins do frequently and it isn’t a odd “one off” situation. There really don’t appear to be any show stoppers here – and with UAG DirectAccess, I think we end up with the “star of the show” when both users and IT tip their hats to you for giving them what they’ve actually wanted since the first PPTP VPN was deployed.

Let’s finish up with another quote that we can easily address:

“Also, because other releases of Windows server operating systems don't support dual-layer IP, DirectAccess can't natively talk to them. If your enterprise has a bank of Windows Server 2003 or older machines that won't be upgraded anytime soon, that data is in a silo that DirectAccess can't directly access.”

With UAG DirectAccess and its built-in NAT64/DNS64 service, the only Windows Server 2008 or above machine you need on your network is the UAG DirectAccess server. Your entire network can be full of Windows Server 2003, Windows 2000 Server, and Windows XP. DirectAccess clients will be able to connect to these network resources just fine. In addition, you can run your domain on Windows Server 2003 domain controllers and DNS servers. Like I said – only the UAG DA server needs to be running Windows Server 2008 R2. That means there is no silo – DirectAccess users can access whatever they need on legacy operating systems.

There you go. Microsoft UAG DirectAccess – The Beautiful Truth. I hope that you’ve had a chance to read this article before you read the ugly truth article, but if you read the ugly truth article first, at least you know what the truth is regarding UAG DirectAccess. And with these truths in mind, I hope that you’ll consider researching a possible DirectAccess deployment for your company. If you have any questions on how to do this, send me a note at the address in the sig line below.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Both the Windows DirectAccess and the UAG DirectAccess solutions are heavily dependent on the Windows Firewall with Advanced Security. DirectAccess clients take advantage of both firewall rules and Connection Security Rules. Connection Security Rules are IPsec rules that control the IPsec tunnel mode connections between the DirectAccess clients and the DirectAccess server. In addition to the IPsec tunnel mode connections, Connection Security Rules are used to enable IPsec transport mode connections for servers for which you want the DirectAccess clients to connect using end-to-end security.

In order to get the most out of DirectAccess and how DirectAccess works, it helps to have a better understanding of the different components of the Windows Firewall with Advanced Security and how some of the important settings work and how they interact with DirectAccess

Windows Firewall Profiles – Pubic Profile, Private Profile and Domain Profile

Windows Firewall offers three firewall profiles: domain, private and public. The domain profile applies to networks where the host system can authenticate to a domain controller. The private profile is a user-assigned profile and is used to designate private or home networks. Lastly, the default profile is the public profile, which is used to designate public networks such as Wi-Fi hotspots at coffee shops, airports, and other locations.

Different firewall and connection security rules can be configured for each profile. There are default settings that are applied to each profile, but the administrator can customize their default settings.

What Does This Have to Do with DirectAccess?

The different profiles are important because a computer only works as a DirectAccess client when it is not on the corporate network. In order words, if the DirectAccess client detects that it can connect to its domain controller and is on the corporate network, it will use the domain profile. The DirectAccess client will only act as a DirectAccess client when the Private or Public Profiles are enabled. The reason for this is that the Connection Security Rules that enable the IPsec tunnel mode connections to the DirectAccess server are included only in the Public or Private Profiles. There are no Connection Security Rules that enable IPsec tunnel mode connections to the DirectAccess server in the Domain Profile.

The UAG DirectAccess server (as well as the Windows DirectAccess server) will create the Connection Security Rules that allow for the creation of the DirectAccess IPsec tunnels (and the end-to-end IPsec transport mode connections for servers configured for end-to-end security). However, the UAG DirectAccess wizard does not import any firewall rules that you might have configured to work on the corporate network. Those rules that you created for the intranet hosts were created for the Domain Profile. If you want your Domain Profile firewall rules to apply to DirectAccess clients, you will need to enable those rules on the Public Profile and Private Profile too.

How Do I Create Firewall Rules for DirectAccess Clients?

In order for intranet computers to connect to DirectAccess clients, there need to be firewall rules in place on the DirectAccess clients that allow the incoming connections from the intranet servers. In addition, if you are blocking outbound connections, you may need to create rules that enable required protocols outbound. There are several things you need to know about these firewall rules:

• Teredo clients need to have the Edge Traversal setting enabled on inbound firewall rules that allow the intranet clients to connect to DirectAccess clients that are using Teredo to connect to the DirectAccess server (http://technet.microsoft.com/en-us/library/ee809076.aspx)
• Teredo clients must have also have rules that allow them ICMPv6 access to intranet clients, such as ICMPv6 neighbor discovery. This rule is enabled by default and you should not delete it. In addition, Teredo clients require ICMPv6 Echo Request access to your intranet if you are using ISATAP or native IPv6 on the intranet. If you are using NAT64/DNS64, then you need to enable ICMPv4 Echo Requests to your intranet (http://technet.microsoft.com/en-us/library/ee649189(WS.10).aspx).
• With reference to the second bullet point, you should be aware of a scenario where domain policy doesn’t allow firewall rules to merge with local policy. While the required rule is enabled by default in local policy, if your organization disables merging local with domain policy, then only rules created for domain policy will be applied to the DirectAccess client, which will cause this rule to be disabled. If this is the case, you should manually create all of the required infrastructure rules, such as those required for IP-HTTPS, Teredo, 6to4, ESP, IKE and ICMPv6.
• DirectAccess clients using 6to4 and IP-HTTPS to connect to the UAG DirectAccess server don’t require the Edge Traversal setting to allow for remote management. However, since you can’t predict which IPv6 transition protocol will be used by the DirectAccess client, you should always enable Edge Traversal on the firewall rules.
• The firewall rules that enable intranet hosts to connect to the DirectAccess clients should be applied to the Public and Private profiles. You can apply them to the domain profile if you like, but in order for the computer that is acting as a DirectAccess client to apply these rules, they must be enabled on the Public and Private Profiles.
• When creating these firewall rules, make sure that one of the endpoints (can be the remote endpoint, it doesn’t matter) includes the IPv6 prefix of the intranet. Failing to configure this type of access control in the rule may create a security issue that allows anyone on the Internet to connect to the DirectAccess client using these protocols. You can find the ISATAP IPv6 prefix in the details of the intranet tunnel rule as Endpoint 2.
• If you have firewall rules that you enable for intranet clients using the Domain profile, be aware that these are not automatically applied to the DirectAccess clients, since they will be using either the Public or Private profile. Therefore, if you want your domain firewall rules applied to DirectAccess clients, make sure to replicate them for your DirectAccess clients’ Public and Private profiles.

While it’s possible for you to create your firewall rules in the DirectAccess Clients GPO, that’s not a good idea because your rules will be overwritten the next time you use the UAG DirectAccess wizard and deploy updated GPO settings. Instead, create a new GPO with the firewall settings and apply it to your DirectAccess clients security group or OU.

For a very good tutorial on configuring firewall rules for DirectAccess client, check out How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to DirectAccess connected machine at http://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-directaccess-connected-machines.aspx

And if you want to try it out for yourself in your UAG DirectAccess Test Lab, check out Test Lab Guide: Demonstrate UAG DirectAccess Remote Management over at http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=385a3144-8e84-4335-896b-a2927e4d46cd

Anything Else I Need to Know About DirectAccess Client Firewall Rules?

I’m glad you asked! Yes, there are a few more things you should think about when configuring firewall rules for DirectAccess clients. These are:

• Don’t turn off the Windows Firewall on either the DirectAccess client or DirectAccess server. This will disable IPsec and Edge Traversal – so it essentially breaks all DirectAccess connectivity
• Avoid allowing all inbound connections to the DirectAccess clients. Doing so will disable Edge Traversal. This breaks Teredo and manage-out.
• Avoid blocking all outbound connections as well. If you block all outbound traffic, you will not only need to enable the infrastructure protocols, you will also need to allow any other protocol required by the DirectAccess client, such as HTTP, SMT, RDP, etc) on the Public and Private Profiles.
• If your organization manages all of your firewall rules through a central GPO, you need to make sure that you enable the rules that are required for DirectAccess to work. These include rules to support IPv6 Transition Technologies, ICMPv6 (as mentioned previously) and ESP and AuthIP. However, you do not need to any rule to the UAG server, as the Firewall capability is disabled on the UAG and the TMG server is in control.

Authors:

Yaniv Naor, SDE
Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Here are the answers to Quiz 1, Round 1:

====================================================

Question 1: Which Operating System(s) can be configured as DirectAccess clients? (choose the best answer)

A. Windows 7

B. Windows Vista SP2

C. Windows Server 2008 R2

D. Windows 7 and Windows Vista SP2

E. Windows Server 2008 R2 and Windows 7

The answer to question 1 is E. Actually, a couple of people pointed out to me that I should have mentioned that you needed Enterprise or Ultimate Edition of Windows 7. While that is true, the editions are different SKUs, and not different operating systems. Therefore, the answer is Windows 7 and Windows Server 2008 R2 when asked which operating system.

====================================================

Question 2: What happens when the DirectAccess client successfully connects to the Network Location Server (NLS)?

A. The DirectAccess client turns on the Windows Firewall Domain Profile

B. The DirectAccess client disables its ISATAP interface

C. The DirectAccess client disables the Name Resolution Policy Table

(note: there was a typo in answer C – I left out the word “client”, but the meaning of the answer remains unchanged)

The answer to question 2 is C. When the DA client connects to the intranet and successfully connects to the Network Location Server and receives a 200 HTTP response that is acceptable to WinHTTP (that is to say, that WinHTTP is able to successfully parse the web page) it will disable the NRPT. You can see the result of this turning off of the NRPT by using the command netsh namespace show effectivepolicy.  You can see the result is Note: DirectAccess settings would be turned off when computer is inside corporate network in the figure below.

http://blogs.technet.com/b/tomshinder/archive/2010/07/19/what-defines-a-functional-connection-to-a-network-location-server.aspx

====================================================

Question 3: When you do an ipconfig /all in a command prompt window and see both the Teredo and IP-HTTPS interfaces assigned an address, which interface is actually being used to transfer data?

A. The Teredo interface

B. The IP-HTTPS interface

C. Both the Teredo and IP-HTTPS interfaces

D. None of the interfaces – when both appear it indicates that the Windows Firewall Domain Profile is active

The answer to question 3 is B. This condition occurs when the DirectAccess client takes more than the computed delay for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test for this condition, run the ipconfig command at a command prompt. If you have global addresses on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.

http://blogs.technet.com/b/tomshinder/archive/2010/08/24/why-are-both-the-teredo-and-ip-https-interfaces-active.aspx

====================================================

Leaderboard

====================================================

I want to thank everyone who participated in Quiz 1, Round 1. This was a difficult quiz and I pulled some pretty tough questions first time around. Some of the quizzes will be easier, some will be more difficult. But I hope you will continue to play and that you find this a useful and fun learning experience. Quiz 2, Round 1 will be posted on December 9, 2010 – so make sure you put that on your calendar so you don’t miss the quiz because if you do, someone who’s ahead of you now might miss the next quiz and that will be your chance to take the lead!   For the same reason, those of you who didn’t participate in Quiz 1 still have a chance – so make sure to take next week’s quiz and get yourself on the leaderboard!

====================================================

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

When a DirectAccess client computer is on the Internet, it connects to the corporate network using DirectAccess. All communications between the DirectAccess client and DirectAccess server are done over IPv6 (encapsulated by an IPv4 tunnel to carry the IPv6 traffic over the IPv4 Internet). In fact, the client application assumes that the connection is IPv6 from end-to-end, even when the destination server on the intranet is an IPv4-only capable resource. UAG DirectAccess can enable IPv4 connectivity to an intranet resource by using its NAT64/DNS64 IPv6/IPv4 protocol translation feature, which allows the UAG DirectAccess server to map an IPv6 address associated with the IPv4 address of the intranet resource. This mapped IPv6 address is used by the DirectAccess client to connect to the IPv4 resource on the intranet. The UAG DirectAccess server will translate this to an IPv4 address and forward the connection to the desired IPv4-only resource on the intranet.

While NAT64/DNS64 solves the problem of IPv4-only capable systems on the intranet, the client side application on the DirectAccess client must be IPv6 capable. If the client-side application is not IPv6 capable, it must use a non-DirectAccess method to reach the application server, such as an Internet accessible application gateway.

In the context of connectivity to SAP resources, you had to use an alternate method outside the DirectAccess tunnels before the release of SAP GUI version 7.1. With the introduction of SAP GUI 7.1, the DirectAccess client can connect to SAP resources on the intranet over the DirectAccess tunnels. However, to get this to work, you need to set a specific environment variable, which we will discuss later in this post. This solves the IPv6 problem on the client side.

If the SAP server is not IPv6 capable (meaning that it isn’t using ISATAP or native IPv6 addressing), then the UAG DirectAccess server’s NAT64/DNS64 feature will be used for IPv6/IPv4 protocol translation. While this will allow access to a SAP server, it will break SAP load balancing. The end result is that if you don’t need SAP load balancing, then all you need is to do is set the environment variable on the SAP GUI client and connectivity will work over DirectAccess because NAT64/DNS64 will take care of the protocol translation for you.

Solving the Load Balancing Problem

However, if you need load balancing for your SAP servers, NAT64/DNS64 isn’t going to do all the work. In this case you’re going to need to bring in another component, called a SAPRouter.

A SAProuter is a non-transparent gateway that can accept both IPv4 and IPv6 connections and do protocol translation between IPv4 and IPv6. NAT64/DNS64 are not used. Instead, the DirectAccess client connects to the SAPRouter using the SAPRouter’s IPv6 address, and then the SAPRouter can route  the connections to the IPv4-only SAP servers behind the SAPRouter. At this point the SAP servers are able to load balance the connections and also return the responses to the SAPRouter, which is then able to return the responses to the DirectAccess clients through the UAG DirectAccess server.

Figure 1 illustrates the request/response path between the DirectAccess client and the SAP resource servers (note that the load balancing component of the SAP servers is called out to make the path easier to understand).

Figure 1

1. The DirectAccess client sends a request to the IPv6 address of the SAPRouter to gain access to the SAP CRM resource on the intranet.
2. The UAG DirectAccess server forwards the connection request to the IPv6 address of the SAPRouter.
3. The SAPRouter forwards the connection to the IPv4 address of the SAP server load balancer.
4. The SAP server load balancer forwards the request to the IPv4 address of the SAP CRM resource server.
5. The SAP CRM returns a response to the IPv4 address of the SAP server load balancer.
6. The SAP server returns the response to the IPv4 address on the SAPRouter.
7. The SAPRouter returns the response to the IPv6 address of the UAG DirectAccess server.
8. The UAG DirectAccess server returns the response to the IPv6 address of the DirectAccess client.

Configuring the SAPGUI 7.1 Client

The following are instructions should configure the SAP GUI 7.1 client to work with DirectAccess:

1. Start SAP Logon.
2. Click the button 'New Item'.
3. Click the button 'Next'
4. In the window "Create New System Entry" choose the connection type "Custom Application Server".
   Add the following into the dialog:
   Field "Description"                  > A description
   Field "Application Server"    > enter the hostname of the SAP Application Server
   Field "System Number"         > The number of the instance
   Field "System ID"                      > The System ID

If you are using a saprouter you would have to add an entry in the field "SAProuter String", for example "/H/saprouterxy".

Summary

• If you don’t need load balancing for your SAP CRM resources, then all you need to do is configure the SAP GUI 7.1 client
• If you need load balancing for your SAP CRM resources, then you will need to introduce a SAPRouter
• The SAPRouter can translate IPv4 to IPv6 and back so that the DirectAccess client can be configured with the IPv6 address of the SAPRouter

If you have further questions regarding this issue, please write to the address in the sig line below.

Authors:

Noam Ben-Yochanan, Senior Program Manager, DA

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

I’ve seen a few people ask if there are problems with access to IPv4 only resources after installing UAG Service Pack 1 (UAG SP1).

The cause of the problem is that after you install UAG SP1, the DNS64 service is set to Manual. You need to reconfigure the DNS64 service to start automatically. This issue is documented in the UAG SP1 Release Notes at http://technet.microsoft.com/en-us/library/gg315322.aspx

After installing SP1 RTM on a Forefront UAG server running SP1 RC and acting as a DirectAccess server, the DNS64 service will be set to Manual. Following the installation, set the DNS64 service to Automatic and start the service.

BTW – if you were trying to troubleshoot this issue, you would have been exposed to this scenario in the Test Lab Guide: Troubleshoot UAG DirectAccess which you can find http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=d2e460c8-b4bf-4fda-9f86-ecc4b7add5d1 (just thought you’d like to know - there’s a lot of other cool troubleshooting scenarios and information in that Test Lab Guide, so give it a try when you have a chance).

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder