One of the most difficult decisions you have to make as an administrator and network engineer is to decide how you’re going to allocate your limited time to evaluating new products and technologies. There are so many other things you need to do. So when you make the decision to try out a new technology you’re actually taking a significant risk and gambling with your time.
If you win, you’ll be the hero and can begin long process that goes toward a production deployment. If you lose, you’ve wasting many hours on something that you thought sounded good, but ended up not getting it to work.
I feel that pain and have felt that pain in the past. One thing that has created a lot of pain for me was trying to figure out how to do a proof of concept test of a new and complex technology. While I might have figured out how to make the thing work in a test lab, it’s an entirely different ball of yarn to translate that test lab experience to a useful proof of concept.
So I put my thinking cap on and asked around to get some ideas on how to create a proof of concept lab guide that would provide a simulated environment that could closely mirror what you would do in a “live” proof of concept, where you might have 10-20 people from the IT group and maybe some power users from the employee base to participate in.
What I came up with was a UAG DirectAccess Proof of Concept Lab Guide that would walk you through the steps of putting together a proof of concept test lab. The goals of the POC lab guide were:
- Introduce you to UAG DirectAccess
- Provide you with some guidance on how to configure a POC in a multi-forest deployment
- Enable you to build a POC that allows the POC users to test the actual applications they use in the production environment
- Highlight the “gotcha’s
- Provide valuable configuration validation steps so you know how to do the same in your own POC
- Include key troubleshooting steps so that you can more easily understand how various components of the solution work when they go wrong
A key issue with the POC guide is that we wanted to break out the UAG DirectAccess forest from the production forest. There are a few reasons for this:
- The UAG DirectAccess server must be a domain joined machine, and many organizations do not want/allow a machine joined to the production forests to be an Internet facing device
- For a proof of concept, it’s fairly simple to set up a collection of virtual machines for the UAG DirectAccess server and domain controller and create the two-way trusts required to make the proof of concept work
- After the POC is finished, its easy to break the trusts, and tear down the POC environment without leaving any remnants behind in the production forests
After you finish the POC lab guide you’ll have a much better understanding of how you might approach the deployment of a limited POC. After completing the POC you’re ready to start a larger pilot program – where more users are involved and the machine accounts are in the production forest instead of the UAG DirectAccess forest.
You can find the UAG DirectAccess POC guide over at:
Finally, I have to tell you that the POC lab guide isn’t built to the Test Lab Guide specifications that I talk about over at http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx The reason for this is that I created this document before we had hammered down the TLG concept. I could have back-ported the POC guide but given that the Base Configuration is really focused on a single forest concept and we have two forests for the POC, I decided that it would be OK to not back port it to TLG specs. However, if you’re really interested in the POC guide, but desperately want to take advantage of your existing Base Configuration snapshot – then I’ll take the time and make v2 consistent with the TLG design.
Let me know what you think and as always, you’re welcome write to me if you want any questions about the POC guide or if you’re having problems getting it to work. Also, if there are any other TLGs (all future TLGs will be written to the TLG spec) you’re interested in, let me know!
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