Yay! This is the end of round 1. Remember, each of two rounds in the contest have four quizzes – and this is the fourth quiz of round one.

Let’s first get to the answers for Quiz 4 and then we’ll look at the leaderboard and the assignment of points for the round.

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

Question 1:
When a DirectAccess client is directly connected to the Internet and is assigned a public IP address, the only IPv6 transition technology the DirectAccess client can use to connect to the UAG DirectAccess server is 6to4.
     A.  True
     B.  False

The answer to question 1 is B.

A DirectAccess client can use one of three IPv6 transition technologies to tunnel IPv6 messages over an IPv4 Internet. You have probably read that when the DirectAccess client is on the Internet and assigned a public IP address, it will use 6to4 as its IPv6 transition technology. While that is true, that doesn’t mean that the DirectAccess client is limited to using 6to4 when assigned a public IP address. While the algorithm for determining which IPv6 transition technology will be used at any point in time, when the DirectAccess client is assigned a public IP address it will try to activate its 6to4 adapter. However, if the 6to4 adapter fails to initiate, the DirectAccess client can attempt to enable its Teredo or IP-HTTPS adapters. Several people have noticed that when a DirectAccess client is connected to some wireless carriers, the 6to4 adapter fails to start and Teredo is used in its place. While we’re not sure what the root cause of this situation is in all instances, there is a chance that the wireless carriers are blocking IP Protocol 41 somewhere between the DirectAccess client and DirectAccess server.

You can find more information on how the DirectAccess client choose an IPv6 transition technology to use at 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 

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

Question 2:
Which of the following UAG DirectAccess component technologies require certificates and PKI?
     A.  IP-HTTPS Listener
     B.  Infrastructure tunnel
     C.  Intranet tunnel
     D.  Network Location Server
     E.  Client authentication for IP-HTTPS
     F.  All of the above
     G.  None of the above

The answer to question 2 is F.

Certificates and PKI are used in a number of places in the DirectAccess solution architecture. The IP-HTTPS listener requires a certificate bound to it so that an SSL session can be established between the DirectAccess client and server.

The infrastructure tunnel is an IPsec tunnel that allows the DirectAccess client access to management servers on the intranet. The intranet tunnel is an IPsec tunnel that allows the DirectAccess client access to all other resources on the intranet. Both IPsec tunnels require that the DirectAccess client and DirectAccess server have computer certificates to enable both authentication and encryption for both of the IPsec tunnels.

The Network Location Server is used to help the DirectAccess client determine if it is currently on or off the intranet. If the DirectAccess client can establish an HTTPS connection to the Network Location Server, the Name Resolution Policy Table will be disabled and the DirectAccess client will use the DNS server configured on its local NIC for name resolution. A certificate is required on the Network Location Server’s web site so that the SSL session can be established.

When a DirectAccess client uses IP-HTTPS to connect to the DirectAccess server, the DirectAccess client uses client certificate authentication to authenticate itself before successful establishment of the IP-HTTPS tunnel. In the case of IP-HTTPS, certificates are used by the IP-HTTPS listener and by the client to authenticate before the IP-HTTPS tunnel is established.

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

Question 3:
In order to support DirectAccess client access to the intranet tunnel using NAP, you must deploy at least one Windows-based CA.
     A. True
     B.  False

The answer to question 3 is A.

When the DirectAccess client starts, it automatically negotiates the infrastructure DirectAccess tunnel. The infrastructure tunnel enables the DirectAccess client access to key management servers on the intranet, such as domain controllers, DNS servers, and management servers that are used by IT to command and control DirectAccess clients. The second DirectAccess tunnel, called the intranet tunnel, allows the DirectAccess client to connect to all other resources on the intranet. Normally, the DirectAccess client uses computer certificate authentication and Kerberos (user) authentication to start the intranet tunnel.

However, you can improve the level of security applied to enabling the intranet tunnel by requiring the DirectAccess client to pass NAP inspection. However, in order to deploy NAP-based access control over the intranet tunnel, you must have at least one Windows-based CA on the intranet to support NAP.

For more information on DirectAccess with NAP requirements, check out http://technet.microsoft.com/en-us/library/gg315299.aspx 

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

Leaderboard

Here are the results of Round 1:

Winner – christophf (5 points)

2nd – mika (3 points)
            jasonj (3 points)
            oblaba (3 points)

3rd -  olivier (1 point)

Point assignment is based on the rules described on Quiz 1 Round 1 at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx

Next week we begin Round 2. There will be 4 quizzes in Round 2.

Now for those of you who think you’re out of the running – don’t give up! Even if you’re mathematically out of the running for this contest (which ends with the end of round 2), there will be another contest where round 2 of this contest (which starts with the next quiz) will be round 1 of contest 2! So – keep playing!

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

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

(If you didn’t participate in Quiz 1 – you can read the rules of the game over at http://blogs.technet.com/b/tomshinder/archive/2010/12/02/uag-sp1-directaccess-contest-quiz-one-round-one.aspx)

It’s time for Quiz 4 Round 1!

This is the last quiz in Round 1. If you’re in front, make sure you don’t miss this one – and if you’re playing catch up, it’s even more important, as I suspect some of the leaders will miss today’s quiz because of Christmas, which give you a chance to move ahead.

Now for the questions!

There you go! I know you’re all busy this week and next, so the questions are short and sweet.

Now send your answers to me at (make sure to use this link since it contains the subject line I need):

tomsh@microsoft.com

Send your entries until 9AM Central Standard Time (-0600 UTC) on Monday December 27th.

Good luck!

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

Happy Holidays guys! We got a great response to this weeks quiz and added some new contestants. That’s great! Even with the busy holiday it’s cool to see you all interested in playing and learning more about UAG DirectAccess.

Now for the answers:

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

Question 1:
You must be running IPv6 on your corporate network in order to deploy a UAG DirectAccess server that enables DirectAccess clients to connect to intranet resources from virtually anywhere.
     A.  True
     B.  False

The answer to Question 1 is B. When you use the UAG DirectAccess server solution, there are no IPv6 dependencies for resources on the intranet. Because the UAG DirectAccess server includes the NAT64/DNS64 service, all the machines behind the UAG DirectAccess server can be IPv4-only operating systems. When you use the UAG DirectAccess server, the only machine that needs to be Windows Server 2008 R2 on the network is the UAG DirectAccess server. Note that when you use an IPv4-only network behind the UAG DirectAccess server, you will not be able to take advantage of a full “manage-out” deployment. In a full “manage-out” deployment, hosts on the intranet can initiate connections to DirectAccess clients. IPv4-only hosts cannot initiate connections from DirectAccess clients, but DirectAccess clients can initiate connections to IPv4-only hosts on the intranet.

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

Question 2:
You have installed UAG RTM and you want to begin the configuration of the DirectAccess feature. The UAG Management console opens and you are able to see the information on all nodes except for the DirectAccess node in the left pane of the console. When you click on the DirectAccess node in the left pane of the console, you see the following error dialog box:

     (Cannot Load the DirectAccess view (0).)

What is a possible cause of this problem?
     A.  The NetBIOS name of the UAG server contains more than 15 characters
     B.  In order to configure DirectAccess, you must first install UAG Update 1
     C.  The DirectAccess server is a member of a Windows Server 2003 domain
     D.  A firewall behind the UAG server is blocking the SNA (TCP/UDP 108) protocol

The answer to Question 2 is A. This is an interesting problem that was discovered by Shannon Fritz, which he shared on the TechNet forums and discusses in his blog post over at http://blog.concurrency.com/infrastructure/uag-cannot-load-the-directaccess-view-0/ The solution was to rename the machine so that the host name portion of the FQDN was 15 characters or less.

===========================================
Question 3:
A UAG DirectAccess server must be a domain member. However, the UAG DirectAccess server does not need to be a member of the same forest or domain as the resources that DirectAccess users will connect to. What Active Directory domain functional level is required for the domain that the UAG DirectAccess server belongs to for DirectAccess to work correctly?
     A.  Windows Server 2008 R2
     B.  Windows Server 2008
     C.  Windows Server 2003
     D.  None of the above

The answer to Question 3 is D. This is a tricky question. Many of you answered C because you might have read that Windows Server 2003 domain functional level is the minimum domain functional level. I can’t confirm or deny that is true, since it’s not documented anywhere and I suspect that no testing was done with Windows 2000 Server domain functional level. However, regardless of what the minimal domain functional level might be, the question asked which was required. Because you can use any of these domain functional levels in answers A, B and C, none of them are required – you can use any one of them. This makes answer D the correct answer.

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

Leaderboard

The race remains pretty close as we enter into the last quiz of the first round. Six contestants are within two points for the lead. Also, note that the zeros you see in the results are due to contestants that didn’t send an entry for that quiz – no one has scored a zero on any of their entries. The blue highlighting on the cell indicates that no entry was received. But you can see that a few of the new entrants have some strong performances and could end up in the top three if any of those near the top decide to take a Christmas vacation for Quiz 4 .

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

I want to thank everyone who participated in Quiz 3, Round 1. Quiz 4 and the last quiz in Round 1 will be posted on December 23, 2010 – so make sure you put that on your calendar so you don’t miss the quiz because if you do, someone behind you might sneak up and take your position!  But even if you don’t end up in the top three, you’ll learn a lot and remember more when you have some “skin in the game”. And then there’s always Round 2. See you then!

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

Thanks!

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

Test Lab Guides provide a method for you to try out a new product or technology and see how it works in your own test lab. When you use Test Lab Guides you see all the working parts, all the front-end and back-end components, and most importantly, see how that all work together to create a working solution.

Test Lab Guides enable you to get your hands on each configuration setting for simple to extremely complex scenarios. In fact, I’m working on a Test Lab Guide now that will require 10 virtual machines – but provides a demonstration of a very complex multi-site deployment of UAG DirectAccess using a single ISATAP cloud to enable multi-point access to the intranet. You’ll see what it looks like in about two weeks.

Test Lab Guide Types

There are three types of Test Lab Guides:

• The Base Configuration on which all Test Lab Guides are based
• The Demonstrating Test Lab Guides, where you build out a specific product or technology or collection of technologies in the Test Lab
• The Troubleshooting Test Lab Guides, where you learn how to use troubleshooting tools to troubleshoot a specific product or technology, or collections of products and technologies in a complex scenario

The following troubleshooting TLGs are available:

• Test Lab Guide: Troubleshoot DirectAccess
• Test Lab Guide: Troubleshoot DirectAccess with Network Access Protection (NAP)
• Test Lab Guide: Troubleshoot UAG DirectAccess
• Test Lab Guide: Troubleshoot UAG DirectAccess with NAP

The Troubleshooting Test Lab Guides are actually based on a working configuration that you have already created when you did one of the “Demonstrating” Test Lab Guides.

For example, the Test Lab Guide: Troubleshoot UAG DirectAccess is based on the completion of another Test Lab Guide called Test Lab Guide: Demonstrate UAG DirectAccess. In the troubleshooting Test Lab Guide you begin with a working configuration and then break stuff on purpose (we give you instructions on what to break, in what we call “Break-Me’s). After you break the stuff, you use a variety of troubleshooting tools and techniques to troubleshoot the broken configuration.

For an example of how “Break-me’s” work, check out this video.

The goal of the Troubleshooting Test Lab Guides is to show you what tools are available to troubleshoot the product, technology or scenario and what their output looks like when things are working right, and then what the output looks like when things aren’t working (because you’ve broken it on purpose).

Troubleshooting Test Lab Guides – Are They Worth IT?

We have received various feedback regarding the “Troubleshooting” guides and we would like to get input from the community on whether or not you find this approach valuable and if we should continue investing in the troubleshooting guides. Of course, we think the Troubleshooting Test Lab Guides are a great idea because you get hands-on experience with the troubleshooting tools and some insight into what things should look like and what they might look like when they’re broken. In the guides we try to focus on the most common troubleshooting scenarios so that you get the most “bang for your buck”.

What do you think? Are the troubleshooting Test Lab Guides valuable to you? Would you like to have more troubleshooting Test Lab Guides? Is there something missing from the current approach to Troubleshooting Test Lab Guides that would make them more useful for you?

Let us know! You can write to me at tomsh@microsoft.com and let me know what you think about the Troubleshooting Test Lab Guides or you can write your thoughts and ideas about Troubleshooting Test Lab Guides in the comments section below. I do subscribe to the RSS feed for the comments section, so I’ll know when you’ve posted a comment and I’ll acknowledge your input and address your issues.

Thanks for the help!

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