Thanks for the clarifications, Tom.  But I'm still a little confused as to how I actually install a third party certificate for the IP-HTTPS listener.  Where/how do I create the CSR to send to the commercial provider and where do I import the certificate?  Do I use IIS7 or the Certificates console?  I've done it on a Windows server for a website or Exchange, but I don't see any info on the specific procedure in this case.

And finally, if I'm using a commercial certificate for IP-HTTPS, does the CRL distribution point for the private PKI need to be available on a public web site at all?  (I thought using a commercial certificate mitigated the need for a highly available CRL).  Or is the reason a highly available CRL is not needed for the private PKI because of the "soft" check?

Sorry if I'm asking stupid questions.  I'm just trying to wrap my head around everything.

Thanks so much Tom.  I thought it would be pretty easy.

Now that I've got some time to work on this I have one more question about which I haven't found any info yet:  I typically have been using a ".local" domain suffix for setting up Windows domains due to the ease of not having to deal with any additional DNS configuration for the "real" website domain on the internal network.

However, since the TLG is using a ".com" suffix and because there are certain URLs that need to be exposed to the internet, will using an invalid suffix like this be a problem for DirectAccess?  Do the DNS records used for IP-HTTPS and the CRL distribution point need to match the internal domain suffix or can they be use a different suffix?  (i.e., the internal domain suffix is company.local, but the IP-HTTPS cert points to da.company.com and the CRL distribution point is crl.company.com)