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

If you’re not aware of Test Lab Guides, they’re part of a new initiative we have at Microsoft that is intended to make life easier for you when it comes to adopting new products and technologies. We realize that when you consider bringing in a new product and technology, you have to consider how long its going to take to learn how it works. Sure, you might try a hands-on lab or a virtual lab to see what the product or technology can do, but after that, then what?

You’re likely going to try to set it up in a test lab. But do you know all the front-end and back-end components that go into making the product or solution work? Maybe – but only after you dig through a pile of design and deployment guides and maybe a few KB articles and some obscure forum posts. That “paper chase” takes a lot of time and if you’re like me, you consider the risk/benefit ratio when it comes to your time before you try out something new.

That’s where Test Lab Guides come in. Using a Test Lab Guide, you can test a new product or technology in a well-defined and pre-tested lab environment that covers all the front-end and back-end components. You configure everything in the test lab, you see all the moving parts, and you see how everything works together. Many people have told us already that the Test Lab Guides allowed them to quickly learn complex technologies because they could see how all the parts worked together – something that would have taken a long time using the traditional approach of sifting through hundreds of pages of documentation. Even better, after you go through the Test Lab Guide and get a working configuration, you can save a snapshot of the working setup and return to it later, either to check out how things look like when they’re working, or to extend it on your own with custom settings that mirror your current production environment.

It’s All About the Virtualization

As you can imagine, the key to test lab success is virtualization. Sure, you could scare up a bunch of PCs and create a lab network, but who has the time and resources for putting together a physical test network that contains 10, 15, 20 or even more clients and servers? While I know that can be done because that’s how we used to do things, the idea of saving disk images and exporting them and then importing them again to extend the configuration is just too time consuming for today’s busy admin. Nope – the reality is that with the advent of client and server virtualization on commodity hardware, test labs are almost exclusively done in a virtualized environment.

Test Lab Guides were designed with virtualization in mind. But if that’s true, why isn’t there any virtualization related information contained in the Test Lab Guides outside of the last step in each guide that tells you that you should snapshot your configuration? The reason for this is that when I’ve written Test Lab Guides, I’ve assumed that the admin using the Test Lab Guide is already well versed in his or her virtualization platform of choice, and would easily be able to translate the TLG instructions into that virtualization platform. While we naturally would prefer that you use Hyper-V as your Test Lab Guide virtualization platform, we realize that there are a number of different virtualization platforms to choose from: VMware Workstation, ESX, Xen and other’s are all capable environments on which you can run your Test Lab Guide scenarios.

Providing virtualization specific information would mean that we would include information that is specific for some platforms and not others. In addition, for the non-Hyper-V platform, if there are changes, we might not necessarily know about them, as it’s not in our charter to stay on top of each version of each virtualization offering.

However, I think it is important to share some virtualization information that will help you with your Test Lab Guide experience. Some of this is Hyper-V specific, but hopefully most of it will be easily applied to to non-Hyper-V platforms. And if you’re not currently using Hyper-V, you might want to give it a look. I was a big VMware user prior to joining Microsoft. However, after joining Microsoft I felt it was important for me to have some basic understanding of Hyper-V. The result is that I’ve been using Hyper-V almost exclusively in my Test Lab Guide development process and am very impressed with it. So if you’re a “VMware guy or gal” and never looked at Hyper-V, I recommend that you give it a look. If for no other reason, you might want to use Hyper-V for Test Lab Guides.

Another thing to consider when using virtualized environments for Test Lab Guides is memory. Some virtualization platforms enable something called "memory overcommit" what allows you to assign your virtual machines more memory than is available on the physical host machine. However, some virtualization do not - and Hyper-V is one of those solutions. While in some cases you can run a Test Lab Guide scenario with a machine that has 8 GB of memory, I have made the assumption that most organizations are using virtualization platforms that support at least 16 GB of memory, and ideally can support 24 GB or more. This allows you to run more complex, but more realistic scenarios in the Test Lab.

Virtual Networking

When working with virtualization, you need a  good working understanding of how its virtual networking feature operates. With Hyper-V, there is the concept of “virtual networks” – with each virtual network acting as a type of virtual switch. VMware has a similar concept, which are called “VMNet’s”. Each virtual machine you connect to the same virtual network or VMNet is on the same virtual network segment, or in other words, in the same Ethernet broadcast domain. If you want to create a multi-segmented network, you would create a virtual network for each segment.

When working with Test Lab Guides, you can create virtual networks for each of the subnets called out the in the Test Lab Guide. For example, in the Base Configuration Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab6c61af-9c34-4692-815c-4396b482d31b), you are asked to create a “Corpnet subnet” and an “Internet subnet”. When using Hyper-V, you would create a virtual network for the Corpnet subnet and another virtual network for the Internet subnet.

If you need more network segments, you would create more virtual networks. For example, in the Test Lab Guide: Demonstrate UAG DirectAccess (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d), you need to create a new subnet called the “Homenet” subnet. To support the Homenet subnet, you just create a new virtual network.

If you are working with Hyper-V, you need to be aware that there are three types of virtual networks that you can choose from. These are:

• Internal networks. These virtual networks allow hosts connected to the same virtual network to communicate with one another and with the host operating system.
• Private networks. These virtual networks allow hosts connect to the same virtual network to communicate with one another. They are not able to communicate with the host operating system through the virtual network.
• External networks. These virtual networks allow you to connect virtual machines to a live network. Each External network is associated with a particular NIC connected to your computer.

When I create the Base Configuration, I create two Private virtual networks: one for the Corpnet subnet and one for the Internet subnet. You can name them whatever you want and it’s probably best to name them Corpnet subnet and Internet subnet. Do the same for any other virtual networks you need to create to support the Test Lab. The Test Lab Guide will provide you some guidance on the name of the network (such as calling the new network the “Fabrikam” network), in which case you create a new virtual network for the Fabrikam subnet.

What about Internet Access?

Now you might be wondered what to do if you need to provide Internet access to a machine on a Private virtual network. Remember that virtual machines connected to a Private virtual network are able to communicate with other VMs on the same Private virtual network, but aren’t able to communicate with any other physical or virtual machine. You’ll have to do something to else to provide a virtual machine actual Internet access.

You might want to provide a VM actual Internet access if you want to download some applications or updates. The approach you use to provide this access will vary with the role the virtual machine is playing on the Test Lab network. For example, CLIENT1 (from the Base Configuration) is a Windows 7 client machine that’s designed to move between the Corpnet subnet, the Internet subnet and the Homenet subnet (and even the Fabrikam subnet if you choose to use the Fabrikam Base Configuration [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4521421f-bd0c-4eed-b280-a7aaf2fde321]). You can create an External virtual network and connect CLIENT1 to that network. It will then pick up IP addressing from the “live” network’s DHCP server and you can then download the information you need from the Internet. After you get the information you need, you can move CLIENT1 from the External virtual network back to the Corpnet subnet (which is a Private virtual network).

While this approach works fine for virtual machines that are designed to be mobile, it gets a bit more tricky when you want to provide Internet access for more “sessile” machines. Examples of these types of machines would be domain controllers and Exchange Servers; both of which really aren’t designed to be moved from one network to the other and be DHCP clients. We’re going to have to think of a different approach for these servers.

In addition, there might be scenarios when you need to demonstrate actual  Internet from specific client types access or you want to provide Internet access to all machines so that you can demonstrate things like Windows Update Services.

To do this, you might consider what I did in the Test Lab Guide: Demonstrate UAG SP1 RC Force Tunneling (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=756e35c6-d706-4b18-80c2-881e9bccda3c). In that Test Lab Guide, I configured INET1 with a second network interface and then configured that network interface to use an External virtual network so that it could connect to the Internet. I then configured the default gateway settings on the computers in the Test Lab so that Internet bound traffic would go through INET1. There were some network gateway and DNS configurations that were required to make it work, but it did allow all the computers in the Test Lab Internet access, including DirectAccess clients.

Note:
We plan to update the Base Configuration Test Lab Guide so that Internet access is made a default option. I hope to have that update to the Base Configuration Test Lab Guide to you before the end of January. If you need help before that, please let me know and I’d be happy to show you how to provide Internet access to your Test Lab.

Make sure to always create the virtual networks you need before you create the virtual machines that you’ll to connect to them. It’s better to have the virtual network ready for the virtual machines instead of having the virtual machines wait for you to create the networks to connect to them.

For more information about configuring virtual networks on a Hyper-V server, check out the following video: http://www.screencast.com/t/Ft4Dpm4tLZ (around 7 mins)

Creating and Snapshotting the Virtual Machines

This is one area where there are a number of options and everyone has their favorite. One popular option is to use parent/child disk configurations, where you essentially create a parent disk that subsequent virtual machines can take advantage of when you want to quickly create new virtual machines for your Test Lab. Kurt Hudson did a great job describing how you do this in his TechNet wiki article Hyper-V Virtual Machine (VM) Parent-Child Configuration Using Differencing Disks http://social.technet.microsoft.com/wiki/contents/articles/hyper-v-virtual-machine-vm-parent-child-configuration-using-differencing-disks.aspx

While this is a valid and popular approach for quickly creating new virtual machines, and something that can be done with VMware and other virtualization platforms, I’ve have chosen not to use this approach when it comes to building out Test Labs. This and similar approaches that “key” into a parent disk introduce dependencies and potential points of failure that reduce the flexibility of the solution. It also makes it more complicated. However, it does have the advantages of allowing you to create virtual machines more quickly, and even more significant is the amount of disk space you can save by using this approach.

If disk space isn’t an issue for you, and if you’re willing to put in a few more minutes per virtual machine to reduce the risks of a parent/child configuration to your entire virtual lab infrastructure, then you might want to consider my approach. My approach is easy and it’s simple (which pretty much describes me). The approach I use for virtual machines:

• Each virtual machine has its own disk file with the default value of 127 GB (it doesn’t take this much space on the physical disk because the virtual disk grows in size as needed to fit the data placed on the disk)
• Each virtual machine is placed in its own folder on the hard disk. This makes it easy to identify the location of the virtual machine and the files associated with it
• For the base configuration, after the operating system is installed, connect the virtual machine to an External virtual network and run Windows Update. Do the same for any other virtual machines that you might add to the Base Configuration
• Connect the virtual machines to the virtual networks on which they will participate in the specific Test Lab that you’re using. Some virtual machines (such as CLIENT1) will move between virtual networks in many Test Lab scenarios.
• At the end of each Test Lab, save a snapshot of the all the machines that participated in the Test Lab and give all the snapshots the same name.

Snapshot the Virtual Lab

Creating virtual machines and snapshots are closely related topics. Each virtual machine you create and configure represents a good chunk of invested time. If you don’t snapshot that virtual machine at the end of your Test Lab, you’ve wasted your efforts (OK, not wasted completely because you probably learned something during the process). When you snapshot the virtual machines in your Test Labs, you can quickly restore the snapshots and start at the end of that Test Lab. At that point you can create a new Test Lab, you can play with the settings to see what happens, or you can use troubleshooting and diagnostic tools and see what they look like when the system is working correctly. Snapshots are unique to virtualization and are a powerful tool to speed your ability to create advanced, realistic and actionable Test Lab scenarios that enable you to learn about your products and communicate more effectively than ever.

However, you need to be systematic about snapshotting. Over my years of using VMware Workstation I had created hundreds of virtual machines to support thousands of possible scenarios for ISA Server and TMG. I didn’t have a co-ordinated system for managing the snapshots and as you can imagine this lead to snapshot sprawl. Over time the sprawl got so bad that my carefully saved snapshots didn’t provide me value and I ended up often having to recreate Test Lab scenarios that I had already done.

At the end of each Test Lab Guide there is a step that informs the reader to snapshot the lab. The step also includes instructions on what to name the Test Lab. The reader should be instructed to shut down each of the virtual machines gracefully at the end of the lab and then snapshot all the virtual machines at the same time after all machines have shut down. After the snapshot it complete, rename the snapshot from its default name to the name suggested in the Test Lab Guide.

Something that we don’t include in the Test Lab Guides regarding virtualization, but something that most virtualization savvy admins are already aware, is that the order you start the VMs is important. In general, you want to start the domain controllers first. Then start servers that provide key infrastructure services to other servers and clients.

This requires that the reader understand the overall solution – and this might not be a reasonable expectation, since the reason for going through the Test Lab Guides is to learn about the product. For example, in the Demonstrating UAG DirectAccess Test Lab Guide, you should start the DC1 virtual machine (a domain controller) first, and then start the UAG DirectAccess server. The reason for this is that the UAG DirectAccess server acts as an ISATAP router for the rest of the network, and it should be available when the ISATAP hosts on the network start up and configure their ISATAP adapters as they start up.

I have not included this start up information in the Test Lab Guides, which is something we will fix in the next version of the Test Lab Guide specification.

Three suggestions for you, and things I plan to implement in the next version of Test Lab Guides are:

1. Tell the reader which virtual machines to start up as part of step 1. Typically, step 1 in all Test Lab Guides is to complete the steps in some other Test Lab Guide, and then restore the snapshots in that Test Lab Guide. I would recommend that you have the reader start all the virtual machines that were part of the prerequisite Test Lab Guide, even if they won’t be configuring all of them. This creates a more coherent set of virtual machine snapshots and enables you build on the entire environment without having to worry about Active Directory or services sync that might get problematic if you don’t start the entire lab.
2. Provide the reader guidance on the order of restoration of the snapshots. Like in the example I gave above, tell the reader to start DC1 first, then start UAG1, and then you can start all the other virtual machines at the same time.
3. Provide the reader information about the approximate amount of memory they should have available on the virtual server to run the entire Test Lab. This includes the memory required to restore the snapshots and the memory required by virtual machines. Also, I’ve made the assumption that Test Lab admins have almost unlimited disk space – you might want to consider providing some information on how much disk space will be used by the end of completing you Test Lab Guide.

To get a better idea of how snapshots are created, restored and named, please see my video on this subject at http://www.screencast.com/t/pGpBxCoZO4QO (around 7 mins).

Summary

In this article I provided a handful of tips and tricks that I use with virtualization when creating Test Lab Guides. These are methods that have worked for me and many of them come from habits of working with virtualization for the last decade; some of the habits might be good and some might need improvement. But if you starting on your trek of writing Test Lab Guides and also beginning your work with virtualization, I hope that these notes help you creating your Test Lab Guides faster than might have otherwise.

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 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

Troubleshooting is always a challenging topic. Challenging from the point of view of the person who has to do the troubleshooting, and challenging to the product group who wants to provide valuable troubleshooting information so that you can solve your troubleshooting issues.

Because information on troubleshooting is so dynamic, we need a way to share information on what we learn about troubleshooting as soon as possible. For this reason, we’ve decided to publish UAG DirectAccess troubleshooting information to the TechNet wiki. With the TechNet wiki, we can provide you “just in time” information about how to troubleshoot problems you might encounter with UAG DirectAccess.

And even more important, if you find that you have a valuable troubleshooting information that will help other UAG DirectAccess admins, you can share that information on the TechNet wiki!

As we begin this effort, we’ve created a main UAG DirectAccess troubleshooting page – Forefront UAG DirectAccess Troubleshooting. On this page you will find useful links to UAG DirectAccess troubleshooting content. Right now, you’ll find links to the following wiki docs:

Troubleshooting forwarding on network interface related Event IDs.

Troubleshooting adapter and IP address related Event IDs.

Troubleshooting DNS64 Startup, Shutdown and General Event IDs.

Troubleshooting Iphlpsrv related Event IDs.

Troubleshooting DNS64 external monitoring related Event IDs.

Troubleshooting timeout related Event IDs.

The great utility of the wiki is that if you find other UAG DirectAccess troubleshooting information, you can add to this list – as another logged onto the wiki can edit and enhance the content. Make sure to add the RSS feed for this page so that you receive automatic updates when this troubleshooting page is updated.

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

You’ve deployed DirectAccess on your network as a pilot project for your IT group over the holidays and everything is working great. When the users are behind a wide open NAT device, they use Teredo to connect to the UAG DirectAccess server. When they’re behind a port-restricted firewall or web proxy only, then they fall back to IP-HTTPS. Of course, you’d prefer that they use Teredo because it’s better performance. But IP-HTTPS connectivity is better than no connectivity at all.

Then it happens – the unthinkable!

Performance seems to slow down. You do an ipconfig and find that the Teredo interface isn’t starting up and only IP-HTTPS is being used. You move the client around, first behind a wide open NAT device and nothing changes. Then you disable the 6to4 interface and connect the client directly to the Internet. Still, only the IP-HTTPS interface comes up.

What’s up with that?

Here are some hints:

First, check out http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx

Next, check out the graphic below:

Finally, check Ben Lee’s blog where he puts all the pieces together to come up with a solution over at http://www.bibble-it.com/2010/12/19/uag-directaccess-only-connects-via-ip-https

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal 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