1) I have verified on the server by running "netsh http show sslcert" that DSMapping is enabled for the DA listener 2) The client has a certificate which has the FQDN for both the subject name and SAN (used AD enterprise CA - computer template) 3) The name mappings in AD shows the computer path as specified in the article 4) I have used a wildcard cert on the UAG server for the IP HTTPS listener (step 2, screen 2) 5) I have used the Internal CA root cert for the root certificate in step 2, screen 3 (the same internal CA which has allocated the client certificate and a UAG server certificate)
im hoping its going to be something silly and simple ive missed - can anyone offer assistance ?
sure can.... i can download the CRL directly from the URL and the same cert is working for the RDGateway via UAG - therefore i figured its a fair bet the CRL is fine - as otherwise RDGateway would spit it.
Im going to spend a bunch of time on this tommorow and will post back what i find (if anything!) - i figured a few days away from it might help.
I had to reboot the server for patching - and when it came back up - DA was working - so unfortunately im not sure which of the things that was done made it work, or what the original issue actually was.
On another note - the DACA still reports that its not working when connected from the internet, the reason being is that my network location server AD04.company.com is not contactable. In the DA config - it is specified that the letwork location server must be excluded from DNS resolution in order for DA to work.... I was really hoping to have the DACA to say "all is good" - is this epxect behaviour or have i configured something else wrong ?
Additionally, with no IPV4 name resolution - ive noticed services that rely on SRV records for server location (such as Lync) - no longer function. Im guessing there is a way around this - but if you know if it - it would be handy! Thanks.
< Message edited by verukins -- 3.Apr.2011 8:36:55 PM >