Clientversion: 1.7.4.6077 und höher, unter Windows 10 > 1803
Maschine außerhalb der Domäne
Auf manchen Rechnern dauert es sehr lange, bis wapt-get update abgeschlossen ist.
Beim Ausführen von `wapt-get update -ldebug` finden wir regelmäßig Folgendes in den Protokollen:
2019-06-13 14:59:43,460 DEBUG Transaktion dauerte zu lange: 2,33699989319
2019-06-13 14:59:45,822 DEBUG Transaktion dauerte zu lange: 2,31399989128
2019-06-13 14:59:48,397 DEBUG Transaktion dauerte zu lange: 2,31700015068
2019-06-13 14:59:50,740 DEBUG Transaktion dauerte zu lange: 2,30399990082
2019-06-13 15:00:17,855 DEBUG Transaktion dauerte zu lange: 2,37700009346
2019-06-13 15:00:20,233 DEBUG Die Transaktion dauerte zu lange: 2,34000015259
Gleichzeitig bleibt Procmon beim Erscheinen dieser Meldungen für etwa 2 Sekunden bei "CreateFile \\WORKGROUP*\MAILSLOT\NET\NETLOGON" hängen:
Umgehungslösung:
NetBIOS über TCP/IP deaktivieren:
Nach erneutem Ausführen von `wapt-get update -ldebug` verschwindet die Meldung „Transaktion dauerte zu lange“. Procmon versucht nun nicht mehr, Mailslots zu öffnen.
Soweit ich das verstanden habe, scheint es mit einem Active Directory (AD)-Aufruf zur Benutzerkontenverwaltung zusammenzuhängen. Dieser AD-Aufruf wird sogar verwendet, um ein lokales Konto abzufragen, das nicht zur Domäne gehört. Ich muss das genauer untersuchen, um es besser zu verstehen.
Der unten stehende Thread war sehr hilfreich, da die erwähnten Timeouts denen ähnelten, die ich erlebt hatte:
https://social.technet.microsoft.com/Fo... inserverDS
Die erste Antwort geht auf das Problem ein, und die Deaktivierung von NetBIOS über TCP/IP löst es, sodass wir endlich eine schnelle WAPT-Verbindung nutzen können
Ich glaube, das Wapt-Team ist auf dieses Problem nicht gestoßen, weil sie Wapt hauptsächlich auf Rechnern in einer AD-Domäne verwenden.
Ich werde meinen Beitrag später fertigstellen.
