Verzögerung beim Laden des gecachten Roaming User Profiles wenn man zum Internet Provider verbunden ist

Hallo, hier wieder einmal Rol. Dieses mal mit einem Thema zu Roaming User Profiles. Diese gehören ja bei vielen Unternehmen inzwischen zum Standard, auch für Laptops. Die nimmt man dann auch gerne mit nach Hause und verwenden, da man nicht mit dem Firmennetz verbunden ist, somit die lokale Kopie des eigenen User Profiles.
Soweit alles erstmal kein Problem. Nur stellt man fest, daß sobald man mit dem WLAN/DSL Internet Provider verbunden ist, es deutlich länger dauert, bis das gecachte Profil geladen ist. Das lange Starren auf den Running Donut zehrt jedoch nun etwas an den Nerven. Ist man vom Provider getrennt, geht es deutlich schnell, teilweise 3-5min.

An was kann das nun liegen? Hier gibt uns ab Windows Vista das GPSVC Logging gute Informationen. Aktivieren kann man das zugehörige ETL Logging wie im folgenden Technet Blog beschrieben: https://blogs.msdn.com/b/spatdsg/archive/2007/02/07/userenv-vista.aspx. Allerding kann das erzeugt Log nur Microsoft intern ausgewertet werden, dazu wird der Source Code benötigt. Nicht ideal aber ein Grund mehr, die Ergebnisse in diesem Blog zu veröffentlichen.

Sucht man im konvertierten Text-Log nach den größten Verzögerungen, wird man schnell fündig:

[1] 03A8.17F4::05/21/2010-12:15:58.778 [profsvc](:_CheckIpNetworkSlowLink:network_cpp443) Got profile server name PROF-SRV1.contoso.com
[0] 03A8.17F4::05/21/2010-12:15:58.924 [profsvc](:_CheckIpNetworkSlowLink:network_cpp475) IP Address = 80.156.86.78 [0] 03A8.17F4::05/21/2010-12:15:58.924 [profsvc](:_CheckIpNetworkSlowLink:network_cpp475) IP Address = 62.157.140.133 [0] 03A8.17F4::05/21/2010-12:15:58.925 [userenv](:PingComputerEx:util_cpp273) PingComputer: PingBufferSize set as 2048
[0] 03A8.17F4::05/21/2010-12:15:58.926 [userenv](:PingComputerEx:util_cpp332) PingComputer: Adapter speed 5500000 bps
[0] 03A8.17F4::05/21/2010-12:16:03.571 [userenv](:PingComputerEx:util_cpp397) PingComputer: First send 0x858c9d3e failed with 11010
[0] 03A8.17F4::05/21/2010-12:16:08.579 [userenv](:PingComputerEx:util_cpp397) PingComputer: First send 0x858c9d3e failed with 11010
[0] 03A8.17F4::05/21/2010-12:16:13.571 [userenv](:PingComputerEx:util_cpp397) PingComputer: First send 0x858c9d3e failed with 11010
[0] 03A8.17F4::05/21/2010-12:16:13.571 [userenv](:PingComputerEx:util_cpp511) PingComputer: No data available
[0] 03A8.17F4::05/21/2010-12:16:13.572 [profsvc](:_CheckIpNetworkSlowLink:network_cpp502) PingComputer failed, hr = 8007003B [0] 03A8.17F4::05/21/2010-12:18:25.096 [profsvc](:_CheckFileSystemSlowLink:network_cpp576) Tick Count = 59998
[0] 03A8.17F4::05/21/2010-12:18:25.096 [profsvc](:CUserProfile::CheckRupSlowLink:profile_cpp1835) The profile is across a slow link
[0] 03A8.17F4::05/21/2010-12:18:25.096 [profsvc](:CUserProfile::CheckRoamingProfile:profile_cpp1441) Slow link detected, disable RUP
[0] 03A8.17F4::05/21/2010-12:18:25.096 [profsvc](:CUserProfile::CheckLocalProfile:profile_cpp2153) Checking Local Profile ...

Dem Windows Client ist der Profil-Server Name PROF-SRV1.contoso.com bekannt und er macht bei aktiver Netzwerkverbindung auch den Versuch der Namensauflösung – und erhält erstaunlicherweise vom Provider zwei IP Adressen, obwohl dieser doch eigentlich den DNS Namen PROF-SRV1.contoso.com gar nicht kennen dürfte.
Im Anschluß macht er dann Ping-Prüfungen zur Slow-Link Detection, bis er feststellt, daß das doch alles nicht geht (Fehler 8007003B = ERROR_UNEXP_NET_ERR “An unexpected network error occurred.”) und letztendlich dann den lokalen Profile Cache lädt.

Wie man sieht, wurden anstelle des zu erwartenden Fehlschlagens der Namensauflösung vom Provider IP Adressen zurückgegeben. Das in der Folge den Profile Service dann ordentlich durcheinander gebracht.

Ursache hierfür ist, daß einige Provider standardmäßig sogenannte Navigationshilfen implementiert haben. Das soll helfen bei Fehleingaben im URL Alternativen zu finden, äußert sich andererseits aber wie DNS Spoofing mit ungewünschten Effekten. Und der in diesem Blog beschriebene ist nur einer davon.

In unserem Beispiel ist der Provider T-Online und gibt bei der Namensauflösung nach PROF-SRV1.contoso.com die IP Adresse 80.156.86.78 zurück, diese ist aber von navigationshilfe1.t-online.de.
Test mit Ping:

C:\>ping navigationshilfe1.t-online.de Pinging navigationshilfe1.t-online.de [80.156.86.78] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 80.156.86.78:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Vermutlich bekommt man bei der DNS Auflösung nach GibtsGarNicht.contoso.com auch diese IP zurück. Ein IPCONFIG /DISPLAYDNS oder Trace sollte es zeigen.

Hintergrund ist die sogenannte Navigationshilfe für das Web-Browsing. Hierbei wird statt des technisch zutreffenden Fehlers, daß das DNS Ziel nicht gefunden wird, vom Provider eine Alternative zurückgegeben. Beim Browsen werden hier dann ähnliche Web-Domänen angeboten. 
Die Thematik der Navigationshilfen ist auch im Web zu finden, ein Beispiel zum Zeitpunkt der Veröffentlichung dieses Blogartikels ist: https://www.teltarif.de/t-online-navigationshilfe/news/33799.html
Hier wird auf den Sinn und Zweck der Navigationshilfen eingegangen und am Beispiel von T-Online erklärt wie man die Navigationshilfe auch abschalten kann.

Wer also auf die entsprechende Navigationshilfe verzichten kann und sich zutraut, bei offensichtlichen Fehleingaben den URL selbst zu korrigieren, der sollte bei der Verwendung von Firmen-Laptops zu Hause das Provider Feature wohl besser abstellen.

Damit frohes Schaffen, auch zu Hause!
Euer Rol