How’s that for a catchy title?
Test Lab Guides (TLGs) are a new method that Joe Davies and I have developed that makes learning complex technologies easier than ever. Using TLGs, you can significantly cut down on the time it takes for you to learn a new technology, product or an entire multi-tier solution by configuring a Test Lab using a TLG.
Now you might be wondering “what’s the difference between a Test Lab Guide and a Step by Step Guide?” In the past, we’ve used the term “step by step guide” to describe a lot of different types of content. It might be a collection of steps you do to issue a certificate, or maybe the steps required to enable and disable the Windows Firewall, or it could be a large collection of steps used in a lab type of environment.
The problem with step by step guides is that they don’t define a standard environment on which you could test out the steps and then validate that the steps actually worked. You could create your own test lab using what you think might be the best settings for a collection of clients and servers, but when you were done with it, you were done. The next time you wanted to go through a different step by step guide, you had to build out another lab, with different settings, clients, servers and services, and go through the steps. Then if you wanted to check out another step by step guide, you had to go through the entire drill all over again.
It was a time consuming process and many of us shied away from the valuable experience the step by step guidance could provide. Test Lab Guides solve this problem by enabling you to create a reusable environment that speeds your lab setups and allows you to get to testing the technology, product or solution faster than ever.
At the heart of the Test Lab Guide concept is the Base Configuration. The Base Configuration is a standard set of servers and clients that are used to simulate a private network and the Internet. The Base Configuration defines the names, IP addressing information and network services used in the Base Configuration setup. After you create the Base Configuration, you take a snapshot – as all subsequent Test Lab Guides will start with the Base Configuration. By creating a snapshot of the Base Configuration, you save a few hours each time you want to try out a new Test Lab Guide. Over the course of a year, this can save you literally days of effort!
The Base Configuration is shown in the figure below:
Now that you have a snapshot of the Base Configuration, what do you do with it? The next step is to build on it using Test Lab Guide modules.
A Test Lab Guide module always builds on the Base Configuration. For example, the figure below shows a Test Lab Guide module named Demonstrate UAG DirectAccess. When you go through the Demonstrate UAG DirectAccess module, the first step is to restore the Base Configuration and you start with the Base Configuration. The module then uses the servers and services already configured in the Base Configuration and adds what’s required to demonstrate DirectAccess.
When you finish the module, you can take a snapshot of the working solution, so that you can return to it later. This is very cool because you don’t have to go through the entire module again to see what the working solution looks like. But if you wanted to do the module all over again, you can restore the Base Configuration and start all over.
See how flexible this approach is?
Now let’s have even more fun. TLG modules build on the Base Configuration. But modules can also build on other modules, so that your TLG actually represents a stack of modules! Check out the figure below. You see three new TLG modules:
These three Test Lab Guides are modules that build on the Demonstrate UAG DirectAccess module. So, if you already did the Demonstrate UAG DirectAccess module and took a snapshot of that module, all you need to do is restore the snapshot of that module, and then go to work on one of the TLGs higher up in the stack. We like to call these “third level modules” since they’re the third module in the stack.
Of course, your stack can get as high as you want, and as long as you take a snapshot after each module, you don’t have to spend time going through all the steps all over again just to begin the new module. Again, a tremendous time saver that allows you to test a greater number of capabilities in the technology, product or solution that you want to learn about.
Virtualization is the key to success with TLGs because it allows you to easily take snapshots of the entire Test Lab and then restore them to proceed to the next module in a Test Lab Guide stack. Before the mainstreaming of virtualization, putting together Test Labs that provide a reasonable facsimile to a production environment would be very difficult. And the time it would take to image the disk drives and restore the images can take quite a while – with virtualization technology, regardless of the virtualization solution you’re interested in, snapshots and restoration is a “snap”.
And it doesn’t stop there. While I’m using DirectAccess as the example technology for Test Lab Guides, the TLG approach can be used for any technology, and we’re expecting that many of the teams at Microsoft will be adopting the Base Configuration and Test Lab Guide module approach so that mixing and matching TLGs will be easy and enable you to build on your collection of TLG snapshots.
For example, maybe the Exchange Team wants to build a TLG on demonstrating Exchange remote access. They could take the Demonstrate UAG Direct Access TLG and build on that, since UAG is part of that TLG and all they need to add is the Exchange configuration and the UAG Exchange publishing configuration. In that way, they don’t need to “reinvent the wheel'” and start from the beginning. Again, a big time saver and a way to get this key information out to you so that you can test it in record time.
What’s even better is that YOU can get into the Test Lab Guide game by creating Test Lab Guide Extensions. A Test Lab Guide Extension is something that you can create that extends the value of a Test Lab Guide. For example, suppose you wanted to create a Test Lab Guide module that built on the Demonstrate UAG DirectAccess and NAP TLG to show how smart cards work with UAG DirectAccess and NAP. What you could do is use the TLG Extension template and create a module that builds on top of the Demonstrate UAG DirectAccess and NAP TLG stack. That way, you don’t have to write out all the steps have already been written – you only need to include the steps required to add the smart card integration.
Of course, you could create your own stack and use the Base Configuration as the start of any technology that you’d like to create a TLG extension for. You start your own stack, beginning with the Base Configuration and then add a stack of TLG extensions. Then others can reuse your stack and create their own extensions. Everyone ends up saving time and learning more because the reusability of the Base Configuration, modules and extensions.
Go Ahead – give it a try – or as we like to say “The Test Lab Guide Base Configuration: Make Something of IT!”
So let’s put it all together.
The figure below shows the components of the Test Lab Guide approach to building out Test Labs using the theoretical example of the solution consisting of UAG DirectAccess, NAP, and SCCM. At the bottom is the core of all Test Lab Guides, which is the Base Configuration. Then modules are built out of the Base Configuration (second level modules). Then modules are built on the second level modules (third level modules) and so forth. You can also see where you can build out your own TLG extensions in the TechNet wiki. Notice on the right side a little icon of a woman taking a snapshot. These are points where you would want to take a snapshot of your configuration so that you can return to it to either redo the steps for a module, or to build a new module or extension.
There’s no doubt about it – you really don’t know how to do something until you actually do it, and that’s what Test Lab Guides are all about. With our reusable TLGs, you’ll be able to get up to speed on simple and more importantly, complex technologies faster than ever. And you’ll be learning the technology, product or solution using a tested and reliable TLG that you know will end up in a working configuration.
You’ll learn all the moving parts, all the tricky areas, and infrastructure requirements that go into making things work. You’ll also have more confidence in the solution, as there isn’t any “smoke and mirrors” configuration in the background – you’ll do every step to configure the front-end and the back-end so that you’ll understand how all the pieces fit together.
Try out some of the Test Lab Guides. You can find the TLG clearinghouse on the TechNet wiki. Right now we have TLGs stacks for Windows DirectAccess and UAG DirectAccess, but we’re expecting many more technologies to be included in the future, and we’ll update the wiki when they become available. Also, remember that anyone can update the wiki, so if you create a Test Lab Guide extension, make sure to update the wiki with your extension. We’re looking forward to some great contributions by the community of original and innovative TLG extensions.
Finally, I want to let you know that I’m here to help. If you have questions about Test Lab Guides let me know. If you want to create a new extension but not sure how to proceed, send me a note and I’ll try to help you. Test Lab Guides speed up all of our knowledge and knowledge is power – let’s go for the power!
Thanks!
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
Let’s face it – you can make it an avocation (or worse, a vocation) of reading all the documentation we have on UAG DirectAccess and still not be able to figure out how to actually put together a working DirectAccess solution. A big part of that is that there are a lot of moving parts, and until you get a good feeling for all those parts and how they work together, DirectAccess looks a more more complicated than it really is.
Believe me – if you can configure an Exchange or SharePoint server, DirectAccess will be a veritable no-brainer.
The real key to really understanding something is to actually do it. And that’s where your old buddy the Edge Man comes in to help. I’ve been in the Edge Man’s skunk works for the last few weeks frying up some tasty Test Lab Guides for you. After you run through these babies a few times, you’re going to feel like you have a pretty good handle on UAG DirectAccess and you’ll be chomping at the bit to plan and deploy your live proof of concept.
Did I say proof of concept? I sure did – and I’ll have a proof of concept guide for you by next week as well.
But enough of the sales job, it’s time to produce the goods:
Go ahead and give them a try!
These Test Lab Guides supersede the UAG DirectAccess Step By Step Guide and contain many bug fixes, exposure to new features, and tips and tricks on how to configure UAG DirectAccess and troubleshoot situations as they come up. The Test Lab Guide for Troubleshooting UAG DirectAccess is also a great way to get your hands wet with DirectAccess, IPv6 and IPsec and I think after you go through the troubleshooting Test Lab Guide you’ll gain new insights into how DirectAccess works and have even more confidence in how to deploy the UAG DirectAccess solution.
Let me know what you think of these new Test Lab Guides and if you have suggestions for more, let me know! I’m always looking for new ideas and if there are problems I can help you solve, then I’m here to help.
Also, remember if you have any DirectAccess questions, make sure to visit the UAG DirectAccess forum over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
HTH,
One of the key pieces of a working DirectAccess solution is the Network Location Server or NLS. The purpose of the Network Location Server is to help the computer configured as a DirectAccess client to know that it’s inside the corporate network. When the DirectAccess client is inside the corporate network, you don’t want it to use the DirectAccess tunnels to reach internal resources. Instead you want the DirectAccess client to connect directly to the resources when they’re on the corporate network.
There are actually two primary things that happen when the computer configured as a DirectAccess client enters the internal network:
Figure 1
You can tell that the NRPT has disabled itself by running the netsh namespace show effectivepolicy command. You’ll see the Note: DirectAccess settings would be turned off when computer is inside corporate network, as seen in the figure below.
Figure 2
Conversely, if the DirectAccess client can’t find a domain controller and it can’t connect to the Network Location Server, then it will try to enable the DirectAccess IPsec tunnels and it will enable the Name Resolution Policy Table (NRPT). When the NRPT is enabled, name resolution for requests for intranet resources will be sent over the DirectAccess tunnels (if they can be established) and resolved by the UAG DNS64 DNS proxy.
If the DirectAccess client can’t establish the DirectAccess tunnels to connect to the DNS64 component, then name resolution requests for intranet resources will fail. As you can imagine, not being able to resolve names on the intranet can have some pretty negative consequences, some of which I describe at http://blogs.technet.com/b/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx and http://blogs.technet.com/b/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx
Which brings us to a case we encountered a couple of weeks ago. Everything was set up right:
Things looked perfect. However, when the DA clients were returned to the intranet, the NRPT would not turn itself off. This would be consistent with a problem connecting to the NLS, but when we pointed the browser to the NLS, the default web page came up fine.
We did a network trace using NetMon 3.4 and found that the DA client was making repeated connection attempts to the NLS. This was a bit strange, so we dug deeper.
We found out that the web server (a non-IIS server, but that’s no problem, we support any web server for the NLS server) was returning a bad header. This lead WinHTTP to not be able to parse the web page response and conclude that there was a server failure. In contrast, when we connected to the site using the web browser (IE), the bad header was ignored by WinInet (used by IE) and the page was successfully rendered in the browser.
What surprised me about this was that I had the impression that all we needed to do for a successful NLS connection was to successfully establish an SSL connection to the NLS and receive a 200 OK response from the web server. In fact, we need a little more than that – WinHTTP needs to be able to successfully parse the web page response in order to create a successful NLS connection.
I don’t expect this to be an issue for the vast majority of DirectAccess admins, but it might be something to keep in your back pocket if you’re having problems with the NRPT not being disabled when the DirectAccess clients are on the intranet and when you are using non-IIS servers for your NLS server, where you’re more likely going to customize the headers and thus might experience a typo in the process.
One more thing – if you ever have any questions on DirectAccess make sure to head on over to the UAG DirectAccess forum over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
You’re learning about DirectAccess and you like what you see. The next step is to build out a test lab. You can build out your own, or you can let me to the heavy lifting for you and use the UAG DirectAccess Step by Step Guide over at http://technet.microsoft.com/en-us/library/ee861167.aspx You’ll save a lot of time by using the lab I put together for you, and you’ll learn a lot about DirectAccess terminology and configuration issues.
When you do put your Test Lab together, you’ll find that there are a lot of technologies and a lot of steps involved with making it work. The reason for this is that DirectAccess is really a collection of product and platform technologies that work together to create a working remote access solution that we’ve named DirectAccess. All the components of the solution need to be configured correctly for it to work.
And that will likely be your first challenge when you start working with DirectAccess. You’ll have gone through all the steps in the Step by Step guide and BAM! It didn’t work. Don’t worry – a lot of the technologies are probably new to you. That means there’s a good chance that you missed a step. I’ve done it, other DirectAccess experts have done it. Consider this a normal part of the DirectAccess learning process. After you’ve gone through the test lab a few times, all the concepts and technologies will fall into place in your mind and you’ll actually get to a place where you’ll forget what it was like not to understand how all the DirectAccess pieces fit together.
With that in mind, I wanted to take a few minutes to talk to you about using ping to test DirectAccess connectivity. We’re all accustomed to using ping to test connectivity issues – this is something firmly ingrained in all of our years with working with the Windows network operating system. And while you definitely can take advantage of ping to help you troubleshoot DirectAccess connectivity issues, there are a few things that you need to keep in mind about ICMP and DirectAccess connectivity.
First, remember that DirectAccess uses IPsec tunnels between the DirectAccess client and DirectAccess server to allow DirectAccess clients access to intranet resources. There are two tunnels:
It is commonly said by DirectAccess experts (including myself) that all traffic moving through the DirectAccess client to resources on the intranet is through one of these tunnels. This is true for all traffic except ICMP traffic. In a UAG DirectAccess scenario, IPsec policy is configured to exempt ICMP from IPsec authentication and encryption. Therefore when you ping a resource on the intranet, you are sending those pings outside of the infrastructure and intranet IPsec DirectAccess tunnels.
Now you might be asking yourself “If the ping traffic isn’t going through the DirectAccess tunnels, how it is getting to the intranet”? That’s a good question and unless you’ve been in the IPv6 transition technology game for awhile, the answer is definitely not obvious.
Take a look at the figure below. What I tried to draw here are two tunnels. The larger tunnel is an IPv6 transition technology tunnel. IPv6 transition technologies can be used to allow the IPv6 communications between the DirectAccess client and DirectAccess server to be carried over the IPv4 Internet. The DirectAccess client can use one of three IPv6 transition technologies over the Internet: 6to4, Teredo or IP-HTTPS. The details of each these isn’t important here.
What is important is to understand is that each of these IPv6 transition technologies tunnel IPv6 packets inside an IPv4 header. Inside of the IPv6 transition technology IPv4 tunnel is the IPsec tunnel – where IPsec is used to authenticate and encrypt the IPv6 packets. When you think about DirectAccess tunnels, you should think of two tunnels – the IPv6 transition technology tunnel and the IPsec tunnel.
The above figure shows that ICMP messages are carried over the IPv6 transition technology tunnel, but that they are outside the IPsec tunnel. The reason why we decided to do this is to make Teredo work correctly, as Teredo requires ICMP access outside the IPv6 IPsec tunnel to determine what type of NAT device the DirectAccess client might be located.
Because of this decision, you need to be aware of a couple of issues:
Before going into the details of ICMP traffic and troubleshooting, I wanted to point out where the ICMP exemptions for IPsec traffic are configured. In the first figure below you can see the Group Policy Object (GPO) for the DirectAccess servers. When you right click the Windows Firewall with Advanced Security – LDAP {GUID} entry and click Properties, you’ll see what appears in the figure right below it – in the Windows Firewall with Advanced Security dialog box, on the IPsec Settings tab. In the IPsec exemptions frame, you’ll see the Exempt ICMP from IPsec option is set to Yes.
Now let’s take a look at what happens when the IPsec infrastructure and intranet tunnels fail. In this example, I took a working DirectAccess setup and broke it by configuring the UAG DirectAccess server to use the wrong root certificate for mutual computer authentication. Since the root certificate configured in the UAG DirectAccess configuration points to a root CA that didn’t issue the computer certificates used for computer certificate authentication, all IPsec tunnel connection attempts will fail.
One of the standard things we do when troubleshooting DirectAccess connections is to see if we can ping the 6to4 address of the UAG DirectAccess server itself. You can get this address by using the
netsh namespace show effectivepolicy
command on the DirectAccess client, as seen in the figure below.
Now that we have that address, let’s try and ping it.
Yay! That worked and shows that we have IPv6 connectivity with the DirectAccess server. This proves that at least the IPv6 transition technology is working enough so that we can ping the UAG DirectAccess server side of the Teredo (in this example) tunnel. What it doesn’t tell us is if the other components that allow address to resources behind the UAG DirectAccess server are functional.
To enable ICMP access to resources behind the UAG DirectAccess server, you will need to know the IPv6 address of the resource you want to connect to. This can be an ISATAP address or a native IPv6 address (or as well see later, a NAT64 address). It doesn’t matter which type – what matters is the fact that the DirectAccess client only communicates with the DirectAccess server and the networks behind it using IPv6 (except when NAT64/DNS64 is used, in which case the communications are “NATed” by the UAG DirectAccess server, so that between the DirectAccess client and the UAG DirectAccess server IPv6 is used and communications between the UAG DirectAccess server and the IPv4 resource on the intranet, IPv4 is used).
We can go to the domain controller on the network and use ipconfig /all to check it’s ISATAP address. In this example the ISATAP address of the domain controller (DC1) is 2002:836b:2:8000:5efe:10.0.0.1 so we’ll ping that ISATAP IPv6 address from the DirectAccess client on the Internet.
Yay again! It worked. Now we know that the Teredo tunnel between the DirectAccess client and the DirectAccess server is up, and that the Teredo relay configured on the UAG DirectAccess is working.
What if you’re not using ISATAP and you’re not using native IPv6 addresses behind the UAG DirectAccess server? This is a common scenario where you have an IPv4-only network behind the UAG DirectAccess server. In this case, you’re taking advantage of the UAG DirectAccess server’s NAT64/DNS64 capabilities. If you want to learn more about NAT64/DNS64, I highly recommend you read Meir Mendelovich’s excellent coverage of this subject over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
The problem we have to solve is how do we figure out what the NAT64 address is of an IPv4 only host? Well, the answer comes from an exceptional blog post by Ben Bernstein over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx
The UAG NAT64 address of an IPv4 only host is:
2002:WWXX:YYZZ:8001:[Hex of IPv4 address] /96 (the /96 means that the prefix is 96 bits of the 128 bit IPv6 address)
The WWXX:YYZZ is the Hex representation of the first of the two consecutive IPv4 public address on the UAG DirectAccess Server. You can figure this out if you like, but UAG has already done this work for you. If you look in the figure above, you can see these components of the IPv6 address:
836b:2: – this is the WWXX:YYZZ Hex representation of the IPv4 address
8000: – this is the value used to represent the ISATAP prefix (this is covered in more detail in Ben’s article if you want more information in this)
What we can do is take this information and build out our NAT64 address for the IPv4 only resource. First, we can define our prefix, which is:
2002:836b:2:8001 /96 (the 8001 value is used to represent the NAT64 prefix)
The last 32 bits of the address is Hex representation of the IPv4 only resource. In this example, the IPv4 only resource has the IPv4 address 10.0.0.4. We convert to this to Hex:
10 = 0a in Hex (8 bits)
0 = 00 in Hex (8 bits)
4 = 04 in Hex (8 bits)
Or – 0a00:0004 (32 bits represented by two 16 bit blocks)
Now we can put our prefix and address together and get:
2002:836b:2:8001:0000:0000:0a00:0004 /96
You might be wondering where the 0000:0000 entry came from. First, you need to know that each “block” (the value between the colons) represents 16 bits. There are eight blocks in a 128 bit IPv6 address. We defined the first 64 bits of the NAT64 prefix with the four blocks 2002:836b:2:8001. However, the NAT64 prefix is 96 bits, so we need to add another 32 bits to the prefix to make it add up to 96. We can do this by adding two blocks of zeros. That gives us the 96 bit prefix. Then we just append the Hex presentation of the 32 bit IPv4 address at the end.
NOTE: There is something called “zero suppression” when describing IPv6 addresses where leading zeros can be left out and where they can be replaced with a double colon “::”. We don’t need to get into that now, but you’ll notice that is done automatically by the operating system when it converts the WWXX:YYZZ and also in the ping responses.
Let’s give it a try.
Yay for a third time! It worked again. This proves that we have ICMP connectivity to both IPv6 and IPv4 resources on the intranet. At this point we must be feeling pretty good, as we’ve successfully pinged the UAG DirectAccess server and a IPv4 and IPv6 resources on the intranet.
But what about traffic isn’t ICMP? A quick check can be done by using the web browser. In the figure below I’m using the ISATAP address of a web server on the intranet. Notice that if you want to use IPv6 addresses in Internet Explorer, you have to surround them with brackets.
This connection fails because it’s using HTTP, which isn’t ICMP. The reason for the failure is that in order to transport HTTP, the DirectAccess IPsec tunnels must be available. And because I broke IPsec, there are no tunnels. You can prove that to yourself by using the Windows Firewall with Advanced Security console and finding no Main Mode or Quick Mode Security Associations. There is a process to troubleshoot IPsec tunnel establishment failure, but that’s not why we’re here today :)
The key points I want you to remember from this article include: