PowerShellAdmin

Stimmt so nicht mit dem -File, er nimmt es als Default Parameter :)

Also hinter das File gehört eine Pipe. Das war auch in der Vorlage bereits so angegeben. VG PSAdmin

da wundert mich der Dialog nicht ...

Soweit es sich um einen lokalen Benutzer handelt, entspricht der Hostname der lokalen Domain. Zu dem Thema ist auch bei MSXFAQ ein umfassender Artikel. https://www.msxfaq.de/code/powershell/pspasswort.htm Schliesse Mal bitte ISE und teste den Aufruf direkt über die PowerShell.exe. Ich nehme an da stimmt was mit den Pfaden und / oder Variablen nicht. Ise ist da leider etwas trügerisch. Entferne bitte den folgenden Auszug, das ist nicht korrekt. Der gewünschte Script wird via Variable Script definiert, das PSC ist eine zusätzliche Erweiterung der Konsole - hatte ich lediglich für die vsphere Erweiterung verwendet. -PSConsoleFile "C:\tools\usv_shutdown\test.ps1

Danke @Testperson für die Ergänzung ;) hing hier gerade noch an andern Themen man nennt es glaube ich Arbeit... bzw. bin jetzt auf'm Heimweg.

Die Datei am besten mit den Zielnamen und Zielpfad initial erzeugen und sicherstellen, dass der Domainnutzer korrekt angegeben ist z.B. domain\sammaccountname. So wie ich es rauslese, wird hier eine Ver- und Entschlüsselung mit dem zusätzlichen Key empfohlen.

Die Passwortcontainer müssen vorab erzeugt werden. Das Auslesen innerhalb 2. sollte hier auch verbessert werden. Das Beispiel ist an der Stelle veraltet. Viel Spaß :) https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/convertto-securestring?view=powershell-6 https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/convertfrom-securestring?view=powershell-6

Also das Thema liegt gefühlte 5 Jahre zurück. Als Leitfaden ... 1. Folgender Skript wird initial getriggert und ruft einen PowerShellSkript auf - shutdown.bat - ich hatte hier direkt die vmware module eingebunden, kannst du bei Bedarf wegehhauen echo Shutdown of all VM’s and ESX hosts is launched at >> C:\tools\usv_shutdown\log\alert.txt echo %date% %time% >> C:\tools\usv_shutdown\log\alert.txt C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "& 'C:\tools\usv_shutdown\runasAdministrator.ps1'" -PSConsoleFile "C:\tools\usv_shutdown\vim.psc1" 2.PowerShellSkript - Initialisierung Powershell: Ich hatte damals Probleme mit den entsprechenden Berechtigungen, die wurden nicht sauber übergeben.Die Aufgabe hiervon ist die PowerShell für den eigentlichen Skript anzustarten. Hinweis: Die notwendigen Credentials müssen vorher angelegt werden. Da gibt es heute auch bessere Methoden. cls #legt Ausführungsbenutzer fest $user= "********" #lädt Passwortdatei $File="C:\tools\usv_shutdown\credentials\*******.pwd" $password = Get-Content $File | ConvertTo-SecureString #erzeugt die Credentials $credential = New-Object System.Management.Automation.PsCredential($user,$password) #eigentlicher PS Skript, der z.B. als Admin etc ausgeführt wird $script = "C:\tools\usv_shutdown\multithread.ps1" #Skript Aufruf Start-Process powershell -Credential $credential $script #-ArgumentList #schließt den Intialisierungsskript 3. Eigentlicher Zielskript - Hier kannst du dann mit deinen Bedürfnissen loslegen. Wie du Emailsverschickst usw, das darfst du gerne recherchieren. Du solltest erstmal in ruhe definieren was du möchtest. Sprich dich nochmal die Anforderungen prüfen. Beispiel: 5 Min Stromausfall danach erfolgt Triggerung. Unter 3. Werden bei mir parallel in mehrere Jobs - je ESXi Host (alle Gäste -VMs) und Bleche heruntergefahren. Hier gibt es sicher mehrere Wege ans Ziel... Man kann auch via Batch-Datei eine Art Triggerfile erzeugen, parallel läuft in der Prozessplanung der alle X Minuten die Datei prüft und bei Befund die Datei verschiebt und anschließend die gewünschten Routinen ausführt.

Was interessieren mich deine Fehler von gestern. Zur Frage - Schau dir mal meinen Vorschlag an... Das müsste eigentlich so noch laufen. Die Umsetzung ist nicht so kompliziert :)

Hallo, eine Idee wäre es eine Batch zu starten, aus der eine PS mit entsprechenden Berechtigungen instanziert wird. Hatte bei einer Dell UPS (gibt es zwischenzeitlich nicht mehr) ähnliche Probleme und mir damals über die Hauruckaktion geholfen. Batchdatei startet PowerShell Skript "Anlauf Skript" "Anlauf Skript" startet separate Instanz von PowerShell mit entsprechenden Credentials - die Credentials wurden verschlüsselt übermittelt. Dahinter liefen dann die eigentlichen Skript der mehrere Shutdown Skripte (Threads) parallel angestartet hat. Edit: Die Batch war sehr einfach: echo Shutdown of all VM’s and ESX hosts is launched at >> C:\tools\usv_shutdown\log\alert.txt echo %date% %time% >> C:\tools\usv_shutdown\log\alert.txt C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "& 'C:\tools\usv_shutdown\runasAdministrator.ps1'" -PSConsoleFile "C:\tools\usv_shutdown\vim.psc1"

Minima Prinzip - ein DC ist ein kritisches System und wir hier mit potentiellen Schwachstellen ausgestattet.

Guten Abend, richtig wurde mit CrystalDiskMark geprüft. Lasse hier morgen nochmal das IOMeter drüber laufen. Die Thematik ist nicht mein täglich Brot aber das ist mein Verständnis: Read Policy: Bei SSD Raids wenig sinnvoll, geht wohl auf die Timings und die Synergie ist hier wenig gegeben. Write Policy:Der Performancegewinn von Zurückschreiben besteht zwar auch bei SSD Raids, allerdings ist der Vorteil hier deutlich überschaubarer. Es ist eine Abwegung des Risikos - auch mit BBU und UPS (beides vorhanden) Strip Size: Mein altes Verständnis war hier, dass der SweetPoint bei 64KB für gemische Umgebungen ist. Die 256KB kamen aufgrund der 4x SchreibSpindeln ( 8 Disk Raid 10) = 1 MB Die Annahme ist aber scheinbar nicht richtig, da die 1MB auch wieder in 4KB Blöcke aufgespalten werden. Fallback auf 64KB ? Disk Cache: Hier hilft weder die BBU und UPS - daher je nach Risikobewertung zu deaktivieren. Zusammenfassend: Da das Risiko in der kleinen Umgebung überschaubar ist, bleibt Zurückschreiben nun aktiviert, eine Risikobewertung zum DiskCache schaue ich mir aber nochmal an. Ein Vorteil vom Zurückschreiben scheint hier auch eine Entlastung der Schreibzugriffe der SSD, da sich diese hier reduzieren. Das Thema Fastpath werde ich mir aber nochmal anschauen, dass ist ausschließlich bei Durchschreiben und keinen Vorauslesen verfügbar. https://www.dell.com/support/manuals/de/de/dedhs1/poweredge-rc-h840/perc10_ug_pub/fastpath?guid=guid-107ce12d-6522-4716-a9a4-ec0a92c1130d&lang=en-us Hier profitieren aber ausschließlich Pakete < Strip Size.

Also write back ist nicht immer in der Konstellation empfohlen und war hier auch nicht die Ursache. Mindestens ein Teil der Ursache ist die Thindisk, die Thickdisk ist beim seq q32t1 und 4 KB q8t8 deutlich gestiegen. Ich werde denke ich nochmal die Stripesize prüfen, die scheint mit 256kb nicht optimal zu sein.

Die Performance der Test-VM war erstmal schlechter als erwartet. Ich gehe davon aus, dass hier ein falsches Alignment und der Thinmodus des Gast Ursache war. Auch der VM Disk Controller ist hier erstmal auch schlecht für einen Test...- womöglich noch Mal auf Paravirtual prüfen. Am Montag gibt's erstmal eine Klärung mit dem Dell Support. Habe hier auch von schlechter Raid10 Skalierung von 8 gegen 4 Disks gelesen.

Guten Abend zusammen, also von der Kapazität haben wir keine Probleme, entsprechend wurde ein Raid 10 ausgewählt. Da sind bereits Puffer und weitere Systeme berücksichtigt. Hinzu kommt der Sachverhalt, dass ich bei Bedarf einfach weitere 8 Disks einbauen kann, da haben wir also genügend Kapazitäten. Grundlegend ist besteht die Frage ob 2xRaid10 mit je 4 Disks oder 1 Raid10 mit 8 Disks. Vor einigen Jahren bin ich mit kleinen Raid1 Clustern gut gefahren - SAS HDD != SSD. Wenn ich mir die Erfahrungen aber so durchlese, macht hier das Splitting aber kein sinn. Raid60 ist bei 8 Disks natürlich auch raus - zwar realisierbar, aber kein mehrwert gegenüber Raid10 bei 8 Disks. VG PSADMIN