10
MSRA- (Remote Assistance) Verbindungen verzögern sich um 45 Sekunden auf Win10 1803 und1809
Moin Kollegen.
Ärgerlich für Supporter in Umgebungen ohne direkten Internetzugang: Microsoft hat offenbar die Arbeitsweise von msra.exe auf Win10 v1803/1809 verändert.
Will man über eine Einladungsdatei eine Verbindung aufbauen, braucht dies 45 Sekunden nach Eingabe des Verbindungscodes!
Das Zielsystem ist dabei unerheblich, es tritt auf, sobald die Einladung auf 1803/1809 geöffnet wird.
Dies passiert nur auf Systemen ohne Internetzugang, also vermutlich ein Timeout-Problem.
Wer mir helfen möchte, dies aufzuklären, kann es ja mal nachstellen auf zwei VMs, die offline sind (einfach an einen internen oder privaten virtuellen Switch anschließen), und dann bitte meinen Technet Thread (nicht DIESEN Thread hier, sondern nachfolgenden Link) upvoten - Danke!
Diesen findet Ihr unter https://social.technet.microsoft.com/Forums/ie/en-US/c1f4acda-e579-49bb- ...
Ärgerlich für Supporter in Umgebungen ohne direkten Internetzugang: Microsoft hat offenbar die Arbeitsweise von msra.exe auf Win10 v1803/1809 verändert.
Will man über eine Einladungsdatei eine Verbindung aufbauen, braucht dies 45 Sekunden nach Eingabe des Verbindungscodes!
Das Zielsystem ist dabei unerheblich, es tritt auf, sobald die Einladung auf 1803/1809 geöffnet wird.
Dies passiert nur auf Systemen ohne Internetzugang, also vermutlich ein Timeout-Problem.
Wer mir helfen möchte, dies aufzuklären, kann es ja mal nachstellen auf zwei VMs, die offline sind (einfach an einen internen oder privaten virtuellen Switch anschließen), und dann bitte meinen Technet Thread (nicht DIESEN Thread hier, sondern nachfolgenden Link) upvoten - Danke!
Diesen findet Ihr unter https://social.technet.microsoft.com/Forums/ie/en-US/c1f4acda-e579-49bb- ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 397461
Url: https://administrator.de/contentid/397461
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
10 Kommentare
Neuester Kommentar
Moin.
Hast du schon versucht einen Wireshark-Mitschnitt während der Zeit anzufertigen, ob die Kiste versucht irgendwelche Gegenstellen im Internet zu erreichen?
Ich tippe auf den fehlenden Zugriff auf pnrpv2.glbdns2.microsoft.com (Easyconnect) führt dann zum Timeout.
Gruß A.
Hast du schon versucht einen Wireshark-Mitschnitt während der Zeit anzufertigen, ob die Kiste versucht irgendwelche Gegenstellen im Internet zu erreichen?
Ich tippe auf den fehlenden Zugriff auf pnrpv2.glbdns2.microsoft.com (Easyconnect) führt dann zum Timeout.
Gruß A.
Hi.
Mit Internetverbindung läuft es 1a, jedoch haben wir in diesem gesicherten Netz kein Internet. Die 1709er funktioniert noch offline.
Somit erübrigt sich die Fehlersuche. MS muss nachbessern.
Mit Internetverbindung läuft es 1a, jedoch haben wir in diesem gesicherten Netz kein Internet. Die 1709er funktioniert noch offline.
Somit erübrigt sich die Fehlersuche. MS muss nachbessern.
Hey, ich war vorhin sehr in Eile.
Nun, ich kann den Mitschnitt machen, aber was ändert das? Irgendwas im Internet wird geprüft - aber wo ist die Stellschraube, die entweder diese Prüfung auslässt oder die Timeouts minimiert?
Ich hatte schon dies getestet:
Local Computer Policy\Windows Settings\Security Settings\Public Key Policies
Certificate Path Validation Setting -> Network Retrieval tab, change the URL retrieval timeout from 15 to 1 second.
->keine Veränderung.
Nun, ich kann den Mitschnitt machen, aber was ändert das? Irgendwas im Internet wird geprüft - aber wo ist die Stellschraube, die entweder diese Prüfung auslässt oder die Timeouts minimiert?
Ich hatte schon dies getestet:
Local Computer Policy\Windows Settings\Security Settings\Public Key Policies
Certificate Path Validation Setting -> Network Retrieval tab, change the URL retrieval timeout from 15 to 1 second.
->keine Veränderung.
aber was ändert das? I
Du wüsstest was er wo nachfragt und könntestso gezielter Nachforschen oder bei MS anfragen.Btw. das ganze hattest du schon mal hier gepostet ...
MSRA- (Remote Assistance) Verbindungen verzögern sich um 45 Sekunden auf Win10 1803
Btw. das ganze hattest du schon mal hier gepostet …
Jaaa, ganz Recht. mit dem Resultat, dass ein Einziger das Ding upgevotet hat...die Peilos voten lieber den Thread hier "up" 
Ich mach morgen einen Trace.
Wireshark ergibt, dass der Zielrechner (welcher ferngewrtet werden soll) in der Wartezeit mehrmals versucht, http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/ ... runterzuladen.
Wie zu vermuten war, hat der Spaß was mit Certificate Revocation Lists zu tun, die geprüft werden sollen. Da sich diese ändern, wird wohl immer ein Onlinezugriff benötigt.
Aber warum lässt man dann die Verbindung überhaupt zu, wenn die Prüfung fehl schlägt? Das leuchtet mir nicht ein. Man muss das abstellbar machen, Microsoft.
Wie zu vermuten war, hat der Spaß was mit Certificate Revocation Lists zu tun, die geprüft werden sollen. Da sich diese ändern, wird wohl immer ein Onlinezugriff benötigt.
Aber warum lässt man dann die Verbindung überhaupt zu, wenn die Prüfung fehl schlägt? Das leuchtet mir nicht ein. Man muss das abstellbar machen, Microsoft.
Es geschehen noch Wunder:
Angeregt durch einen Kommentar auf meine Frage bei experts-exchange.com habe ich
1 mir die benötigten Dateien aus dem internet geladen: pinrulesstl.cab und disallowedcertstl.cab
2 einen lokalen IIS eingesetzt und das Verzeichnis nachgebildet
3 einen DNS-Eintrag gesetzt, so dass ctldl.windowsupdate.com auf meinen lokalen IIS zeigt...
und es geht fortan ohne die kleinste Verzögerung!
Kann natürlich Nebenwirkungen haben, deshalb werde ich weiterhin Microsoft bearbeiten müssen.
Angeregt durch einen Kommentar auf meine Frage bei experts-exchange.com habe ich
1 mir die benötigten Dateien aus dem internet geladen: pinrulesstl.cab und disallowedcertstl.cab
2 einen lokalen IIS eingesetzt und das Verzeichnis nachgebildet
3 einen DNS-Eintrag gesetzt, so dass ctldl.windowsupdate.com auf meinen lokalen IIS zeigt...
und es geht fortan ohne die kleinste Verzögerung!
Kann natürlich Nebenwirkungen haben, deshalb werde ich weiterhin Microsoft bearbeiten müssen.
Die Lösung:
--
1 auf einem Rechner mit Internetzugang fragt man die aktuellen Zertifikate ab - am besten regelmäßig per geplantem Task:
Hierbei wird also auf einer Freigabe "certs" auf Server "server" gespeichert
2 Auf den offline-Clients verteilt man den Registrywert (REG_SZ) RootDirURL mit dem Inhalt file://\\server\certs
in HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate
3 Clients neu starten
Das ist schon alles.
--
1 auf einem Rechner mit Internetzugang fragt man die aktuellen Zertifikate ab - am besten regelmäßig per geplantem Task:
Certutil -syncWithWU \\server\certs\2 Auf den offline-Clients verteilt man den Registrywert (REG_SZ) RootDirURL mit dem Inhalt file://\\server\certs
in HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate
3 Clients neu starten
Das ist schon alles.
Hallo DWW,
der Registry-Key legt den Gleichlauf dieses Verhaltens mit der automatischen Aktualisierung der Stammzertifizierungsstellen nahe. Dafür gibt es die Richtlinie "Automatisches Update von Stammzertifikaten deaktivieren" in der Internetkommunikationsverwaltung und - wahrscheinlich hier die speziellere Wahl - unter Sicherheitseinstellungen>Richtlinien für öffentliche Schlüssel die Einstellungen für die Überprüfung des Zertifikatpfades, Tab Netzwerkabruf.
Grüße
Richard
der Registry-Key legt den Gleichlauf dieses Verhaltens mit der automatischen Aktualisierung der Stammzertifizierungsstellen nahe. Dafür gibt es die Richtlinie "Automatisches Update von Stammzertifikaten deaktivieren" in der Internetkommunikationsverwaltung und - wahrscheinlich hier die speziellere Wahl - unter Sicherheitseinstellungen>Richtlinien für öffentliche Schlüssel die Einstellungen für die Überprüfung des Zertifikatpfades, Tab Netzwerkabruf.
Grüße
Richard
Moin Richard.
Das ist schon alles deaktiviert gewesen, dennoch kam es zur Verzögerung.
Das ist schon alles deaktiviert gewesen, dennoch kam es zur Verzögerung.
