Vorschläge (vor allem bei virtuellem WHS, aber nicht nur)

Bitte posted hier eure Ideen, damit unsere Entwickler sehen was die Community wünscht.
PSaR

Vorschläge (vor allem bei virtuellem WHS, aber nicht nur)

Beitrag von PSaR »

Hallo,

mein WHS läuft seit ca. 1,5 Monaten virtualisiert auf einem VMware ESX 5 Hypervisor, da es sich anbot, weil ich sowieso so eine Maschine zum Testen haben wollte. Dadurch ist es jetzt zu einigen Schwierigkeiten gekommen, die mir vorher so gar nicht in den Sinn gekommen wären, weil Lights Out einfach nur klasse funktionierte (im Grunde macht es das ja immer noch). Dann fange ich mal an, was mir so einfällt:


1. WOL funktioniert nicht mehr, da LO den Clients immer die MAC von der VM mitteilt und nicht die vom ESX. Ich habe die MAC schon in der Registry der Clients und auch in der IPAddressList.xml auf dem Server geändert, aber diese werden immer wieder überschrieben. Ich meine mal davon gelesen zu haben, dass Martin einem User mal eine LO Version bereitgestellt hat, bei der dies nicht der Fall war. Ist da noch irgendwie dranzukommen? Jetzt werden viele sagen, dass ich ja einfach ein Kommandozeilen-Skript auf den Desktop packen könnte, aber da ich einen kleinen Tick habe und alles zu 95% perfekt sein muss :D , würde ich die andere Variante bevorzugen, da mein Desktop schon voll genug ist und LO diese Funktion ja eigentlich schon bietet. Ideal wäre natürlich ein Feld in den Server-Einstellungen, wie etwa das für die Wake-on-WAN Domain, wo sich die MAC des Servers eintragen lässt.

2. Die Option "Überwachung aktivieren und Server aktiv halten" im LO-Client-Kontextmenü missbrauche ich als Möglichkeit, den Server manuell an zu lassen (standardmäßig überall deaktiviert). Die standardmäßige Deaktivierung sorgt dafür, dass der WHS relativ schnell wieder herunterfährt. Das Problem bei mir ist nämlich, dass z. B. ein Nutzer an PC1 den WHS einschaltet, um schnell ein paar Dateien zu kopieren und dann nach ca. einer halben Stunde wieder herunterfahren könnte. Während der Server aber läuft, geht jemand anderes an PC2 (für meinetwegen 2 Std.), der zu der Zeit gar nicht auf den WHS zugreifen möchte, den WHS aber aktiv halten würde, wenn diese Option angehakt wäre (WHS würde also min. 1,5 h umsonst laufen). Nachteil bei meiner Variante ist aber, dass die Schaltfläche bei inaktivem WHS ausgegraut ist und sich so nicht nach Belieben deaktivieren/aktivieren lässt. Die Lösungsmöglichkeit, die mir vorschwebt, wäre soetwas, was in einem anderen Thread schon mal genannt wurde: Es müsste eine Möglichkeit geben, den WHS für X Minuten aktiv zu halten bzw. was vielleicht besser wäre, ist wenn der WHS 5 Minuten bevor er herunterfahren würde die Clients darüber informiert und dass der Benutzer dann noch die Möglichkeit hat zu sagen den Server für weitere X Minuten aktiv zu lassen.

3. Es bringt natürlich nicht viel, wenn nur die VM herunterfährt und der ESX anbleibt, dann könnte ich mir das ganze mit Lights Out auch gleich sparen. Ich habe mir daher überlegt, dass der WHS dem ESX mitteilen müsste, dass er in X Sekunden oder meinetwegen auch sofort herunterfahren soll. Gelöst habe ich das per SSH mittels plink (Putty), das ein shutdown absetzt. Und ihr ahnt es, hier das Problem: Lights Out fährt den WHS ja ohne Probleme in den Ruhezustand, aber der Shutdown müsste natürlich kurz davor noch abgesetzt werden. Dies lässt sich zwar über Tools wie HibernateTrigger eingermaßen lösen, aber funktioniert auch mehr schecht als recht. Besser wäre es also, wenn LightsOut eine Möglichkeit hätte ein Skript/Programm vor dem Herunterfahren/Standby/Ruhezustand auszuführen, ähnlich wie das mit den Diensten gelöst ist, die sich stoppen/starten lassen.

4. Eine Info, an die Clients, wenn der Server schon sagen wir mal länger als 4 oder 6 Stunden läuft wäre auch nicht schlecht (stand aber auch schon in einem anderen Thread).


Das ist ja schon mal eine ganze Menge Text (so viel sollte es eigentlich gar nicht werden :D ), aber mir fällt bestimmt noch mehr ein.
Ich würde mich freuen, wenn jemand einen Lösungsansatz parat hat oder mir einfach nur mitteilt, wie ihr darüber denkt.

Viele Grüße
PSaR
Benutzeravatar
Martin
Moderator
Beiträge: 9948
Registriert: 11. Sep 2007, 10:51
Wohnort: Im wilden Süden

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von Martin »

1. WOL funktioniert nicht mehr, da LO den Clients immer die MAC von der VM mitteilt und nicht die vom ESX. Ich habe die MAC schon in der Registry der Clients und auch in der IPAddressList.xml auf dem Server geändert, aber diese werden immer wieder überschrieben. Ich meine mal davon gelesen zu haben, dass Martin einem User mal eine LO Version bereitgestellt hat, bei der dies nicht der Fall war. Ist da noch irgendwie dranzukommen? Jetzt werden viele sagen, dass ich ja einfach ein Kommandozeilen-Skript auf den Desktop packen könnte, aber da ich einen kleinen Tick habe und alles zu 95% perfekt sein muss :D , würde ich die andere Variante bevorzugen, da mein Desktop schon voll genug ist und LO diese Funktion ja eigentlich schon bietet. Ideal wäre natürlich ein Feld in den Server-Einstellungen, wie etwa das für die Wake-on-WAN Domain, wo sich die MAC des Servers eintragen lässt.
Lights-Out ermittelt selbständig die MAC des Servers um dem Anwender dies zu ersparen. Was du möchtest, ist die MAC des Hosts, die sich natürlich nicht aus Lights-Out heraus ermitteln lässt. Was du mal versuchen kannst, wäre den Dienst zu stoppen und dann die MAC des Hosts mit Komma getrennt hinzuzufügen.
2. Die Option "Überwachung aktivieren und Server aktiv halten" im LO-Client-Kontextmenü missbrauche ich als Möglichkeit, den Server manuell an zu lassen (standardmäßig überall deaktiviert). Die standardmäßige Deaktivierung sorgt dafür, dass der WHS relativ schnell wieder herunterfährt. Das Problem bei mir ist nämlich, dass z. B. ein Nutzer an PC1 den WHS einschaltet, um schnell ein paar Dateien zu kopieren und dann nach ca. einer halben Stunde wieder herunterfahren könnte. Während der Server aber läuft, geht jemand anderes an PC2 (für meinetwegen 2 Std.), der zu der Zeit gar nicht auf den WHS zugreifen möchte, den WHS aber aktiv halten würde, wenn diese Option angehakt wäre (WHS würde also min. 1,5 h umsonst laufen). Nachteil bei meiner Variante ist aber, dass die Schaltfläche bei inaktivem WHS ausgegraut ist und sich so nicht nach Belieben deaktivieren/aktivieren lässt. Die Lösungsmöglichkeit, die mir vorschwebt, wäre soetwas, was in einem anderen Thread schon mal genannt wurde: Es müsste eine Möglichkeit geben, den WHS für X Minuten aktiv zu halten bzw. was vielleicht besser wäre, ist wenn der WHS 5 Minuten bevor er herunterfahren würde die Clients darüber informiert und dass der Benutzer dann noch die Möglichkeit hat zu sagen den Server für weitere X Minuten aktiv zu lassen.
Ok, setze ich mal auf die Wunschliste. Die Option ist deshalb ausgegraut, da die nur bei laufendem Server Sinn macht und direkt kommuniziert wird. Und das ist kein "Missbrauch" sondern genau für diesen Zweck gedacht.
3. Es bringt natürlich nicht viel, wenn nur die VM herunterfährt und der ESX anbleibt, dann könnte ich mir das ganze mit Lights Out auch gleich sparen. Ich habe mir daher überlegt, dass der WHS dem ESX mitteilen müsste, dass er in X Sekunden oder meinetwegen auch sofort herunterfahren soll. Gelöst habe ich das per SSH mittels plink (Putty), das ein shutdown absetzt. Und ihr ahnt es, hier das Problem: Lights Out fährt den WHS ja ohne Probleme in den Ruhezustand, aber der Shutdown müsste natürlich kurz davor noch abgesetzt werden. Dies lässt sich zwar über Tools wie HibernateTrigger eingermaßen lösen, aber funktioniert auch mehr schecht als recht. Besser wäre es also, wenn LightsOut eine Möglichkeit hätte ein Skript/Programm vor dem Herunterfahren/Standby/Ruhezustand auszuführen, ähnlich wie das mit den Diensten gelöst ist, die sich stoppen/starten lassen.
Das sehe ich etwas kritisch, wie lange vorher soll diese Script laufen bzw. anders herum gefragt wie lange nach dem Skript muss gewartet werden bis der Shutdiwn ausgelöst wird? Wenn dann in der Zeit wieder jemand seinen PC startet und den Server braucht, was dann?
4. Eine Info, an die Clients, wenn der Server schon sagen wir mal länger als 4 oder 6 Stunden läuft wäre auch nicht schlecht (stand aber auch schon in einem anderen Thread).
D.h. nach einer einstellbaren Spanne von z.B. 6h kommt wie oft eine Ballonmeldung? Alle 15 Minuten?

Was mir allerdings unklar ist: Warum verpackst du den WHS in ESXi, wenn er als einzige virtuelle Instanz läuft? Sobald andere VMs laufen kannst du dann ja den Host nicht einfach so stoppen, oder ist das so geplant?

Gruß
Martin
Essentials 2016 unter Windows Server 2022 auf HP Microserver Gen 8.
Entwickler von Lights-Out
Benutzeravatar
Martin
Moderator
Beiträge: 9948
Registriert: 11. Sep 2007, 10:51
Wohnort: Im wilden Süden

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von Martin »

Bei WGS gab es gerade einen ähnlichen Vorschlag für das Thema VM: Anstelle den Standardaktionen noch eine weitere Aktion anzubieten, mit der sich ein Programm/Script starten lässt. Das könnte dann die VM herunterfahren. Also nicht zusätzlich zur Standardaktion sondern anstelle. Damit wäre das Timingproblem entschärft.

Gruß
Martin
Essentials 2016 unter Windows Server 2022 auf HP Microserver Gen 8.
Entwickler von Lights-Out
PSaR

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von PSaR »

Martin hat geschrieben:Lights-Out ermittelt selbständig die MAC des Servers um dem Anwender dies zu ersparen. Was du möchtest, ist die MAC des Hosts, die sich natürlich nicht aus Lights-Out heraus ermitteln lässt. Was du mal versuchen kannst, wäre den Dienst zu stoppen und dann die MAC des Hosts mit Komma getrennt hinzuzufügen.
Das habe ich mal versucht, hat aber nichts gebracht. Zumindest steht in der Registry immer noch der alte Wert.
Martin hat geschrieben:Ok, setze ich mal auf die Wunschliste. Die Option ist deshalb ausgegraut, da die nur bei laufendem Server Sinn macht und direkt kommuniziert wird. Und das ist kein "Missbrauch" sondern genau für diesen Zweck gedacht.
Naja, "Missbrauch" ist vielleicht etwas zu scharf formuliert gewesen, aber dieses "Ausgrauen" stört halt, wenn man mal vergisst den Haken vorm Herunterfahren (automatisch oder manuell) herauszunehmen. Wenn z. B. an PC2 vergessen wurde den Haken rauszunehmen und ein paar Tage später nutzt jemand an PC1 den WHS nur kurz, dann würde PC2 den WHS wieder aktiv halten. Gut, in dieser Situation ließe sich der Haken dann wieder herausnehmen, aber wer denkt da schon dran??
Martin hat geschrieben:Das sehe ich etwas kritisch, wie lange vorher soll diese Script laufen bzw. anders herum gefragt wie lange nach dem Skript muss gewartet werden bis der Shutdiwn ausgelöst wird? Wenn dann in der Zeit wieder jemand seinen PC startet und den Server braucht, was dann?
Martin hat geschrieben:Bei WGS gab es gerade einen ähnlichen Vorschlag für das Thema VM: Anstelle den Standardaktionen noch eine weitere Aktion anzubieten, mit der sich ein Programm/Script starten lässt. Das könnte dann die VM herunterfahren. Also nicht zusätzlich zur Standardaktion sondern anstelle. Damit wäre das Timingproblem entschärft.
Ja, genau statt einer Aktion, wie Herunterfahren/Standby/Ruhezustand müsste so ein Skript ausgeführt werden. Irgendwo habe ich das auch schon mal so geschrieben, nur hier nicht mehr dran gedacht (war schon so viel Text ;-)). Am Ende des Skripts könnte man dann ja immer noch für den Shutdown/Standby des WHS sorgen oder man gibt dem ESX einfach den Befehl zum Shutdown, wenn der ESX dann richtig konfiguriert ist, fährt er die VMs dann ja selbstständig herunter und beim nächsten Start auch wieder hoch. Generell bevorzuge ich aber den Ruhezustand, da dadurch die Zeit, bis der WHS läuft minimiert wird. Evtl. könnte man die Maschine auch einfach anhalten, ich weiß aber nicht, wie sauber das funktioniert. Bei Tests musste ich nach dem nächsten Start den LO-Dienst immer erst neu starten.
Martin hat geschrieben:D.h. nach einer einstellbaren Spanne von z.B. 6h kommt wie oft eine Ballonmeldung? Alle 15 Minuten?
Ja, z. B. alle 15 Minuten, wenn man darauf nicht reagiert. Ich stelle mir die Funktion gerade so wie die Meldung nach einer automatischen Installation von Windows Updates vor, wenn der PC einen Neustart anfordert: Es gibt eine Meldung und man kann, um jetzt beim Beispiel zu bleiben, auswählen, wann man als nächstes an den Neustart erinnert werden möchte. Bezogen auf den WHS würde man dann festlegen, wann man als nächstes an den aktivien WHS erinnert werden möchte.
Martin hat geschrieben:Was mir allerdings unklar ist: Warum verpackst du den WHS in ESXi, wenn er als einzige virtuelle Instanz läuft? Sobald andere VMs laufen kannst du dann ja den Host nicht einfach so stoppen, oder ist das so geplant?
Im Moment läuft der WHS noch alleine, das stimmt schon, wird sich aber noch ändern. Ich habe noch einige Dinge, die ich noch testen will (Linux allgemein, IP-Cop Firewall, Squid Proxy, Penetration-Tests mit Backtrack, Server 2008 R2 [speziell Remote Apps und den Network Access Protection Server], WPA2 Enterprise [RADIUS-Server]...), außerdem sind Umzüge etwa von WHSv1 auf v2 usw. dann einfacher zu bewerkstelligen und da bietet es sich halt an. Bis vor einiger Zeit fungierte mein WHS auch noch als VPN-Server (PPP), diese Funktion würde ich gerne wieder bereitstellen, dann aber nicht auf dem WHS sondern in einer anderen VM und entweder mittels IPsec oder OpenVPN.
Die Test-Maschinen würde ich dann wahrscheinlich manuell hoch- und runterfahren. Andere, wie etwa den VPN-Server würde ich automatisch starten lassen (zusammen mit dem WHS nach dem Start des ESX). Wenn der WHS dann den Befehl zum Shutdown an den ESX sendet, fährt dieser erst mal alle VMs herunter und erst dann sich selbst. Das habe ich schon mal getestet, funktioniert wie am Schnürchen.
Ein Argument habe ich für Virtualisierung noch: Mittels der Snapshots lassen sich vorherige Zustände ganz einfach und schnell wiederherstellen.

Gruß
PSaR
rantanplan-dtm
Foren-Einsteiger
Beiträge: 3
Registriert: 28. Nov 2011, 17:24

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von rantanplan-dtm »

Hi,

ich beschäftige mich auch gerade mit dem Problem"virtualisierter WHS". Plattform ist auch ESX 5. Bis jetzt hatte ich auch Lights Out im Einsatz, das klappt natürlich nicht mehr, da es mir nichts nutzt, wenn die WHS-VM herunterfährt und der eigentlich Server weiter läuft. Das Problem lässt sich aber zum Glück erstmal recht einfach lösen. Du kannst am ESX konfigurieren was mit den VMs passieren soll, wenn der ESX heruntergefahren wird, zumindest Shutdown geht -> VM-Ware tools müssen installiert sein! Also konfiguriere ich das der WHS zuvor heruntergefahren werden soll und natürlich später automatisch wieder gestartet werden soll.

@Martin
Jetzt fehlt "nur" noch der part, dass Lights-Out dem ESX sagt, dass er herunterfahren soll:-). Ideal wäre natürlich, wenn zuvor alle existirenden VMs abgefragt werden, in welchem Zustand sie sich befinden, damit dieser wieder hergestellt werden kann. Denn natürlich wird es mehr als nur den WHS geben. Und beim nächsten Start, wenn der WHS dann vom ESX gestartet wurde, werden alle VMs wieder in den vorherigen Zustand versetzt. Also alles was lief wird wieder gestartet und alle anderen VMs bleiben wie sie sind.
Für ESX 5 (4 sollte auch gehen) habe ich mir die benötigte "API" (Abfrage der existierenden VMs, Abfrage des Zustands, Start, Stop, Suspend, usw) habe ich schon (C#, andere Umsetzungen sind möglich), fehlt nur die Integration...
PSaR

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von PSaR »

@rantanplan-dtm
Das mit dem automatischen Starten und Herunterfahren habe ich so auch gelöst. Ich habe einfach alle VMs für den Auto-Start/Shutdown konfiguriert und veranlasse dann per SSH den Shutdown des ESX Hosts. Im Prinzip müsste es in LightsOut zusätzlich zu den Aktionen zum Herunterfahren/Standby/Ruhezustand die Möglichkeit geben ein Skript auszuführen, in meinem Fall eines, das den shutdown-Befehl per SSH ausführt. Außerdem müsste die MAC-Adresse, die den Clients für die Wake on LAN Funktion mitgeteilt wird anpassbar sein. Genaueres dazu steht ja schon oben, auch einige weitere Ideen.

Gruß
PSaR
Benutzeravatar
Martin
Moderator
Beiträge: 9948
Registriert: 11. Sep 2007, 10:51
Wohnort: Im wilden Süden

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von Martin »

Im Prinzip müsste es in LightsOut zusätzlich zu den Aktionen zum Herunterfahren/Standby/Ruhezustand die Möglichkeit geben ein Skript auszuführen, in meinem Fall eines, das den shutdown-Befehl per SSH ausführt
Wie schon geschrieben steht das auf der Wunschliste und wird mit einem der nächsten Updates realisiert.

Gruß
Martin
Essentials 2016 unter Windows Server 2022 auf HP Microserver Gen 8.
Entwickler von Lights-Out
PSaR

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von PSaR »

@Martin
Ich weiß, hattest Du ja schon mal geschrieben, war aber auch mehr für rantanplan-dtm gedacht.
rantanplan-dtm
Foren-Einsteiger
Beiträge: 3
Registriert: 28. Nov 2011, 17:24

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von rantanplan-dtm »

PSaR hat geschrieben:@Martin
Ich weiß, hattest Du ja schon mal geschrieben, war aber auch mehr für rantanplan-dtm gedacht.
Ist auch angekommen. Dann kann ich ja meine Lizenz weiter nutzen, wenn es so weit ist:-).
Benutzeravatar
Martin
Moderator
Beiträge: 9948
Registriert: 11. Sep 2007, 10:51
Wohnort: Im wilden Süden

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von Martin »

Wer eine Version mit Benutzeraktion testen will schreibt mir bitte eine Email an support at homeserversoftware punkt com.

Gruß
Martin
Essentials 2016 unter Windows Server 2022 auf HP Microserver Gen 8.
Entwickler von Lights-Out
PSaR

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von PSaR »

Sooo, nachdem ich die Version mit der Benutzeraktion schon einige Zeit installiert habe, hatte ich gerade etwas Zeit mich mal genauer damit auseinanderzusetzen. Was mir aufgefallen ist:
- Lights Out läuft wie bisher stabil und zuverlässig
- die Benutzeraktion wird anscheinend auch ausgeführt (Erstellen von Textdateien funktioniert),
- das Absetzen von Befehlen per Plink/Putty funktioniert aber leider nicht richtig, weder direkt aus der aufgerufenen Batch-Datei heraus noch aus einer anderen Batch, die über die von Lights-Out gestartete aufgerufen wird

Kann jemand dieses Problem nachvollziehen oder hat eine Ahnung, woran das liegen kann? Bei manuellem Start der Batch-Skripte funktioniert natürlich alles...

Gruß
PSaR
Benutzeravatar
Martin
Moderator
Beiträge: 9948
Registriert: 11. Sep 2007, 10:51
Wohnort: Im wilden Süden

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von Martin »

2 Hinweise:
1. Die Batchdatei läuft im SYSTEM Benutzerkontext.
2. Die Ausgaben der Batchdatei stehen im LightsOutService Log.

Vielleicht kommst du mit dem Log weiter.

Gruß
Martin
Essentials 2016 unter Windows Server 2022 auf HP Microserver Gen 8.
Entwickler von Lights-Out
PSaR

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von PSaR »

Das mit dem SYSTEM-Benutzer wusste ich bereits, aber der Tipp mit Log war echt super nützlich. Ich konnte so herausfinden, dass beim Absetzen des shutdown-Befehls immer eine Abfrage kam, ob ich den SSH-Key akzeptieren möchte, der SYSTEM-Benutzer konnte dies natürlich nicht bestätigen. Ich musste zwar noch die plink.exe austauschen, weil meine Version den Parameter zum automatischen Akzeptieren der Keys nicht unterstützte, aber nun läuft alles.
Eine Frage habe ich aber noch: Im Log kommt nach dem Ausführen der Benutzeraktion immer folgendes:
Time span 00:00:13.3593750 to short for standby? (<30s)
2011-12-31 14:53:11:416 [ 30] DEBUG --- UserAction too short or failed ---
2011-12-31 14:53:11:416 [ 30] DEBUG --- Resuming normal operation ---
Anschließend werden die Dienste wieder gestartet. In der Mail zu der Beta stand ja mit drin, dass die Benutzeraktion mit einem Shutdown/Standby enden sollte, wird auf den Befehel hin irgendwie geprüft und wenn ja, lässt sich das irgendwie umgehen?? Ich habe es schon mit shutdown /a versucht, aber das bringt nichts.

Gruß und einen Guten Rutsch
PSaR
Zuletzt geändert von PSaR am 2. Jan 2012, 00:56, insgesamt 1-mal geändert.
Benutzeravatar
Martin
Moderator
Beiträge: 9948
Registriert: 11. Sep 2007, 10:51
Wohnort: Im wilden Süden

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von Martin »

Hmn, das Problem ist, dass der shutdown ausgelöst wird, dann aber der Aufruf sofort zurückkehrt. Und das wird als zu kurz ausgewertet.
Versuch mal einen shutdown /s /t 0

Gruß
Martin
Essentials 2016 unter Windows Server 2022 auf HP Microserver Gen 8.
Entwickler von Lights-Out
PSaR

Re: Vorschläge (vor allem bei virtuellem WHS, aber nicht nur

Beitrag von PSaR »

Martin hat geschrieben:Hmn, das Problem ist, dass der shutdown ausgelöst wird, dann aber der Aufruf sofort zurückkehrt. Und das wird als zu kurz ausgewertet.
Versuch mal einen shutdown /s /t 0

Gruß
Martin
Genau das wollte ich eigentlich nicht machen, da der ESXi den Shutdown-Befehl senden soll...aber ich habe es jetzt gelöst, indem ich die Ausführung der Batch einfach per sleep.exe für 30 Sekunden verzögert habe. Die Meldungen kommen jetzt nicht mehr.

Gruß und noch mal vielen Dank für die schnelle Umsetzung des Features mit der Benutzeraktion

PSaR
Antworten