TechEd 2010: How to troubleshoot Direct Access

OK, da war ich am falschen Planet und muß noch viel lernen, sehr viel! Aber ich bekam eine Idee.

(nett, Mr Craddock erinnert mich in jeder Art an den „Original“-Q von James Bond)

No SA = No IPsec

ICMPv6 is exempt from IPsec

                Check with ping -6

NetSH is your best friend:

Demo zur Fehlersuche, Client kommt nicht auf’s Intranet:

Ping ‘https://sharepoint.internal’ – njet

Ping was anderes, ok, d.h., Internet ok

Ipconfig /all

Netsh interface 6to4 show state

Netsh interface 6to4 show relay

Ping ‘relay name’ (ipv4 failed)

Ping ipv6-gw-adress ok, aber wir brauchen beide

Netsh interface ipv6 show route

Netsh namespace show effectivepolicy

(nun den internen DA-Server pingen)

Ok, passt

Net view \\‘ipv6 adresse eines internen servers‘

Geht nicht, also wahrscheinlich IPsec das Problem sein.

Trick: In Netzwerkumgebung, Troubleshoot Assistent für DA starten. „falsche“ Fehlermeldung (DNS Server geht nicht, aber das haben wir gecheckt)

Immer (!) ein zweites Mal probieren!!! (Nun fehlt das Cert, abgelaufen)

Cert hjinzu, funktioniert!

‚DirectAccess Connectivity Assistent‘ hilft in einer Oberfläche mit der Suche (von MS Download für den Client)

Testen ggf auch, ob die CRL erreichbar!

NRPT (Name Resolution Table) dient dazu, den passenden DNS Server zu nehmen (www.bing.com, lokal konfigurierte DNS Server, interne Anfragen über die internen Server)

Netsh namespace show effectivepolicy

Netsh dnsclient show state

XTseminars mit Mr Caddock sollten wir noch nach Wien organisieren!

Mit freundlichen Grüßen
Paul Scholda                 

P.S.: Anmerkung von Christian Decker: Letztes Jahr gab es eine ähnliche Session, zu finden hier: teched 2009 Direct Access Technical Drilldown Part 1 IPv6 & Transition Technologies und hier teched 2009 Direct Access Technical Drilldown PArt 2 Putting it all together