Krampfadler

Nochmals zur Klarstellung: Das Verbinden der Drucker macht keine Probleme. Nur das Enumerieren (über den Aufruf von EnumPrinterConnections) erzeugt diese Verzögerung. Dasselbe gilt übrigens auch für EnumNetworkDrives - ist der Server in diesem Zustand, dauert auch der Aufruf dieser VBS-Funktion 40 Sekunden. Jedes Mal. Bis zum Reboot des Servers, danach ist alles wieder ganz normal. Es hat also nichts mit dem Drucken an sich zu tun! Ich habe nur das Script solange reduziert, bis ich das Phänomen auf diesen einen Befehl festnageln konnte. Daher vermute ich ja auch, dass sich irgendwas auf Betriebssystemebene verklemmt, vielleicht irgendein Dienst nicht richtig arbeitet oder Ähnliches. Diese 40 Sekunden riechen doch verdammt nach einem Timeout - irgendetwas im System geht schief und die Funktionen gehen dann einen anderen Weg, der dann letztendlich erfolgreich ist. Die Rückgabe der Funktionen ist dann auch immer korrekt, es werden alle Drucker/Netzverbindungen aufgelistet, es erscheint keine Fehlermeldung, der Fehlercode ist 0. (Derzeit haben wir keinen Server in diesem Zustand, in den letzten Wochen kam dies jedoch sporadisch immer wieder vor, zu selten, um es zu reproduzieren, zu häufig, um es zu ignorieren.)

Es geht nicht um Powershell vs. VBS, möglicherweise bauen wir das Script tatsächlich mal auf Powershell um. Ich habe das Phänomen (das auch an anderen Stellen auftritt, unabhängig von dem genannten Script!) eben mit diesen paar Zeilen VBS schön reproduzieren können, und hoffte dabei, dass gleich jemand schreit: "40 Sekunden? Hatten wir auch mal, liegt an XXX". Scheint jedoch nicht der Fall zu sein :-) add-printer geht im übrigen so schnell wie die entsprechende VBS-Funktion WshNetwork.AddWindowsPrinterConnection. Nur das Enumerieren dauert besagte 40 Sekunden. Ich denke auch nicht, dass es am Scripting Host liegt, sondern an irgendetwas, was tief im System vergraben liegt. Aber wo?

Im Originalscript ja, in diesem Demo-Vierzeiler habe ich es weggelassen. Das Phänomen existiert jedoch unabhängig davon.

Klar, Eventlog habe ich natürlich durchgesehen, doch nichts in dieser Zeit gefunden. Zusätzlich bin ich auch mit Process Monitor und Process Explorer drübergegangen, doch nichts Auffälliges entdeckt. cscript.exe werkelte mit niedrigster CPU-Last vor sich hin schien gar nichts zu tun, nach 40 Sekunden war der Prozess dann weg und die nächste Zeile ausgeführt. Ich habe auch mal in einer Schleife die ermittelten Drucker ausgegeben, die waren alle korrekt, doch wie gesagt: Ich vermute, dass die Wartezeit schon vor dem eigentlichen Enumerieren der Drucker entsteht. Aber wo?

Hallo zusammen, auf einem Windows 2008 R2-Server haben wir manchmal ein seltsames Phänomen in einem VB-Script. Das Script benötigt plötzlich 30-50x so lange wie normal (= ca. 200 statt 5 Sekunden). Hat der Server einmal diesen Zustand erreicht, bleibt diese lange Laufzeit des Scripts so lange reproduzierbar, bis der Server neu gestartet wird. Dann ist alles wieder gut bis irgendwann (typischerweise nach einigen Tagen) das Problem urplötzlich wieder auftaucht. Es ist mir gelungen, das Problem auf folgende Zeilen einzugrenzen. Mit diesem Vierzeiler kann ich sofort prüfen, ob das Problem derzeit besteht oder nicht: Set WshNetwork = CreateObject("WScript.Network") WScript.Echo "1" Set objLocalPrinters = WshNetwork.EnumPrinterConnections WScript.Echo "2" Normalerweise werden die beiden Ziffern "1" und "2" sofort hintereinander ausgegeben. Im Falles des Problems erscheinen die beiden Ziffern in einem Abstand von exakt 40 Sekunden. Die CPU-Last des Servers ist auch in diesen 40 Sekunden nahezu 0, das Verbinden von Druckern von einem Printserver geschieht schnell, auf Netzlaufwerke kann ebenfalls zugegriffenen werden, die Drucker werden in der Systemsteuerung problemlos angezeigt. Neustart des Spoolerdienstes nützt nichts, wobei interessant ist, dass wenn der Spoolerdienst nicht läuft, das Script zwar eine Fehlermeldung "Laufzeitfehler in Microsoft VBScript: Der Remoteservercomputer ist existiert nicht oder ist nicht verfügbar" erzeugt, aber erst NACH dieser 40-Sekunden-Pause. Hat jemand eine Idee? Die konstante Verzögerung von 40 Sekunden riecht ja stark nach einem Timeout, doch wo anfangen zu suchen? (Es ist ein Citrix-Server mit XenApp 7.6, doch vermute ich mal, dass dies keine Rolle spielt.) Danke für jeden Hinweis.