Dos command Profilswitching dauert lange

Seba · 2010-05-11 09:30

Hallo

Woran könnte es liegen wenn beim Umschalten eines Profils in der Kommandozeile (z.B. netsetman.exe -as 1) es bis zu 30 Sek. oder manchmal auch länger dauert bis das Aktivierungsfenster öffnet?

Gruß
Hans

NetSetMan Support · 2010-05-17 14:06

Was steht denn im log? ("+"-Schaltfläche im Aktivierungsdialog)
Anhand der Zeiten könnte ersichtlich sein, wo die Verzögerung eintritt.

Generell muss beim ersten Aktivieren eines Profils Windows unter Umständen zunächst die WMI-Schnittstelle initialisieren. Dies geschieht aber sowohl bei der Kommandozeilenaktivierung als auch bei normaler Verwendung im Programm. Ob bzw. wie lange diese Initialisierung dauert, ist von System zu System unterschiedlich.

Seba · 2010-09-28 09:27

Hallo

Jetzt muss ich doch mal antworten. wink
Also die wartezeit entsteht ja schon in der Kommandozeile, da ist das NSM Fenster noch garnicht aktiv, deshalb kann ich auch noch nicht auf das log zugreifen/sehen.
Habe mich evtl. auch etwas falsch ausgedrückt denn ich miente nicht das Aktivierungsfenster ansich sonder das Hauptfenster von NSM.
Ich starte NSM mit einer Verknüpfung auf dem Desktop so "netsatman.bat 1" die Batchdatei hat diesen Inhalt "netsetman.exe -as %1", nach einem doppelklick öffnet das Kommandofenster und zeigt das an "c:\netsetman\netsetman.exe 1" , manchmal ist dieses Kommandofenster lange offen bevor NSM gestartet wir und manchmal geht es sehr schnell.

NetSetMan Support · 2010-10-06 11:50

Wie lange ist denn "lange"?
Vermutlich hat das gar nichts mit der Kommandozeile zu tun, sondern mit dem Programmstart an sich. Denn die Kommandozeile macht nichts anderes als Windows anzuweisen, das Programm zu starten.
Ein verzögerter Programmstart kann mit Verwendung des NSM Services zusammenhängen. Dieser muss aus Sicherheitsgründen erst prüfen, ob das Programm legitimiert und unverändert ist, bevor eine Kommunikation stattfinden darf. Dazu wird unter anderem die Signatur des Programms überprüft.

Wenn auf dem System keine aktuelle Liste von gültigen Root Certificates vorhanden ist, holt sich Windows die benötigte Info ggf. direkt vom Microsoft Server. Hierbei kann die Verzögerung auftreten.

Infos auf Deutsch
Infos auf Englisch

Manuelles Update der Root Zertifikate:
Update for Root Certificates [August 2010] (KB931125)

Seba · 2010-10-18 08:37

Naja, unter lange verstehe ich bis ca. 30 oder 40Sek. dann muss noch NSM das Profil umschalten und das script starten das ganz kann bis zu einer Minute dauern ist aber unterschiedlich.

Sorry aber ich verstehe jetzt nicht ganz welches Programm legitimiert werden muss, Netsetman?
Wenn man diese rootsupd.exe einmal ausführt (mit Zugriff aufs IN) ist das weg aber NSM ist doch garnicht in der Liste aufgeführt oder denke ich falsch?
Wir vewenden hier ja die Notebooks ohne Zugriff auf das Internet also nur um einen anderen Rechner per Remotedesktop zu steuern, da ist das nach ihren Angaben dann schon verständlich das es zu verzögerungen kommt aber ich verstehe nicht weshalb dennoch alles korrekt ausgeführt wird wenn doch das System die Liste der aktuellen Stammzertifikate garnicht abholen kann da keine Verbindung zum Server besteht und wenn die Liste manuell mit dem rootsupd.exe aktualisiert wird erhält NSM dann damit ein Stamnmzertifikat ?

Gruß
Hans

NetSetMan Support · 2010-10-18 16:07

NetSetMan wird durch ein Comodo Code Signing Certificate (www.instantssl.com) digital signiert. Das schützt das Programm vor Veränderungen durch Dritte und garantiert, dass an dem Programm nicht manipuliert wurde.

Genau dieser Test wird vom NSM Service durchgeführt, wenn NetSetMan mit ihm verwendet werden soll.
Comodo Stammzertifikate sind standardmäßig mit Windows dabei. Allerdings werden solche Zertifikate gelegentlich aktualisiert, ergänzt, etc. Sind die vorhandenen Zertifikate also "veraltet", versucht Windows diese bei Bedarf automatisch zu aktualisieren. Kann keine Aktualisierung durchgeführt werden, tritt nach einiger Zeit ein Timeout ein und Windows verlässt sich dann auf die bereits vorhandenen Zertifikate. Diesen Aktualisierungsvorgang kann ich leider nicht beeinflussen; das hat im Grunde mit NetSetMan nichts zu tun. Sind die Zertifikate allerdings aktuell, verläuft der Test verzögerungsfrei und auch der Start ist entsprechend ohne Wartezeit.

Seba · 2010-10-19 07:49

Hallo

Danke für die ausführliche Information.
Ich habe die Datei rootsupd.exe von MS heruntergeladen und ausgeführt und es scheint jetzt wirklich verzögerungsfrei zu laufen.
Eine letzte Frage habe ich noch, ist dieser Aktualisierungsvorgang nach längerer Zeit wieder erforderlich oder bleibt das jetzt so bzw. kann es sein das es erneut zu verzögerungen beim Ausführen kommt?

NetSetMan Support · 2010-10-19 11:56

Um ehrlich zu sein: Ich weiß es nicht genau.
Nach meinem Verständnis sollte dieser Aktualisierungsvorgang im Falle von NetSetMan erst wieder notwendig sein, wenn das zur Signatur verwendete Zertifikat erneuert wurde. Dies wird aber voraussichtlich erst wieder in 2,5 Jahren notwendig sein. Bis dahin bleiben das vorhandene Stammzertifikat und das zur Signatur verwendete Zertifikat gleich und es sollte keine Aktualisierung notwendig sein.

Allerdings läuft bei Windows leider nicht alles so logisch und konsequent ab, wie man es sich wünschen würde, weshalb ich keine Garantie aussprechen kann.

Ich würde mich über eine Rückmeldung an dieser Stelle freuen, wenn die Verzögerung doch irgendwann wieder eintreten sollte, ohne dass an den Stammzertifikaten manuell etwas verändert wurde.

NetSetMan Support · 2010-10-20 13:08

Ich habe mich etwas näher mit dem Thema beschäftigt.
Das aktuelle "UTN-USERFirst-Object"-Stammzertifikat ist bis Mitte 2019 gültig. Sofern also für NetSetMan in 2,5 Jahren das gleiche Zertifikat wie aktuell erworben wird, brauchen Sie auch danach keine Aktualisierung durchzuführen.

Ausgehend von Ihrem Fall bin ich auf die Idee gekommen, dass sich das benötigte Stammzertifikat auch mit NetSetMan im Installer mitliefen ließe. Dann können solche Probleme gar nicht erst entstehen. Heute durchgeführte Tests verliefen positiv.

Bis dies soweit ist, kann das Stammzertifikat auch manuell installiert werden. Dazu folgenden Code in eine leere Textdatei kopieren und diese unter dem Namen "UTN-USERFirst-Object.crt" abspeichern. Es lässt sich dann per "Rechsklick -> Zertifikat installieren" in das System einbinden.

NetSetMan Support · 2012-05-12 16:26

Ich beschäftige mich aktuell wieder mit der Verzögerungsthematik rund um die Zertifikatsprüfung in NSM. Welche Erfahrungen konnten Sie seit unserer letzten Konversation hier machen? Ich würde mich freuen, wenn Sie Ihre Erfahrungen dazu schildern könnten.

Nach meinen aktuellen Tests tritt die Verzögerung speziell bei einer abgelaufenen Zertifikatssperrliste (Certificate Revocation List) auf. Comodo stellt diese (aktuell) scheinbar leider nur mit einer Gültigkeitsdauer von 5 Tagen aus, wo entsprechend ein regelmäßiger Internetzugang von Vorteil ist.
Manuell aktualisiert bzw. hinzugefügt werden kann die CRL übrigens über http://crl.usertrust.com/UTN-USERFirst-Object.crl
Bei Verwendung eines Alternativbrowsers sollte der Link übrigens nicht direkt geklickt, sondern per Rechtsklick gespeichert und in Windows über einen Rechtsklick installiert werden. Alternativbrowser wie Firefox etc. pflegen nämlich ihre eigenen Listen.

NetSetMan Support

#1 2010-05-11 09:30

Dos command Profilswitching dauert lange

#2 2010-05-17 14:06

Re: Dos command Profilswitching dauert lange

#3 2010-09-28 09:27

Re: Dos command Profilswitching dauert lange

#4 2010-10-06 11:50

Re: Dos command Profilswitching dauert lange

#5 2010-10-18 08:37

Re: Dos command Profilswitching dauert lange

#6 2010-10-18 16:07

Re: Dos command Profilswitching dauert lange

#7 2010-10-19 07:49

Re: Dos command Profilswitching dauert lange

#8 2010-10-19 11:56

Re: Dos command Profilswitching dauert lange

#9 2010-10-20 13:08

Re: Dos command Profilswitching dauert lange

#10 2012-05-12 16:26

Re: Dos command Profilswitching dauert lange