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.
Enter the Base Configuration
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:
Test Lab Guide Modules and Stacks
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:
- Demonstrate UAG DirectAccess with NAP
- Demonstrate UAG DirectAccess with Array and NLB
- Demonstrate UAG DirectAccess Remote Management
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 Test Lab Guide’s Best Friend
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”.
The Test Lab Guide Base Configuration – Make Something of IT!
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!”
Putting It All Together
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.
Test Lab Guides – We’re All In
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!
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: https://twitter.com/tshinder