Ein kleines Snippet, um via Batch-Datei Lenovo Treiber-Pakete zu entpacken.
Die .exe-Dateien einfach auf die Batch-Datei mit folgendem Inhalt ziehen, um sie zu entpacken:
1 2 3 4 5 6 7 8 9 | @echo off :next if "%~1" == "" goto done %~1 /VERYSILENT /DIR=%~n1 /Extract="YES" shift goto next :done exit |
Die Dateien werden in einen Ordner mit dem Namen der Datei (ohne Dateiendung, daher „%~n1“) entpackt.
Quelle zur Idee
Um Single Sign On in Chrome zu aktivieren, wird der Eigenschaftsdialog der Verknüpfung aufgerufen und das Ziel folgendermaßen angepasst:
1 | "path/to/chrome.exe" --auth-server-whitelist="*.domain.tld" |
Wer einen Windows Server mit DirectAccess (DA) sein Eigen nennt und kürzlich auf Windows 8.1 umstieg, wird unter Umständen festgestellt haben, dass keine DirectAccess Verbindung mit Windows 8.1 eingerichtet wird.
Ich kann aktuell nicht sagen, ob ein Patch das Problem beheben- beziehungsweise die Konfiguration anpassen würde, da der mir zur Verfügung stehende Windows Server mit DA-Rolle aktuell produktiv im Einsatz ist.
Windows 8.1 scheint vom Domain Controller schlicht ignoriert zu werden, wenn es um die Verteilung der GPO für die DA-Verbindung geht.
Wird die DA-Rolle mit dem „Getting Started Wizard“ eingerichtet, legt dieser einen WMI-Filter an, welcher automatisch der Richtlinie zum Verteilen der Einstellungen für die DA-Verbindung zugeteilt wird:
Select * from Win32_OperatingSystem WHERE (ProductType = 3) OR (Version LIKE ‚6.2%‘ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 72 OR OperatingSystemSKU = 84)) OR (Version LIKE ‚6.1%‘ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 70 OR OperatingSystemSKU = 1 OR OperatingSystemSKU = 28 OR OperatingSystemSKU = 71))
Der Filter „erkennt“ Notebooks/portable Geräte und sorgt dafür, dass nur für ebendiese eine DA-Verbindung eingerichtet wird.
Außerdem – und das ist der Knackpunkt – werden Geräte disqualifiziert, welche keine Fähigkeit zum Aufbau einer DA-Verbindung mitbringen. Und das betrifft diesem Filter nach auch Windows 8.1.
So banal das Problem klingt, so einfach und logisch ist auch die Lösung. Der Filter wird so verändert, dass auch ein NT 6.3 (Windows 8.1) den Regeln entspricht:
Select * from Win32_OperatingSystem WHERE (ProductType = 3) OR ((Version LIKE ‚6.2%‘ OR Version LIKE ‚6.3%‘) AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 72 OR OperatingSystemSKU = 84)) OR (Version LIKE ‚6.1%‘ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 70 OR OperatingSystemSKU = 1 OR OperatingSystemSKU = 28 OR OperatingSystemSKU = 71))
Einzustellen in der Gruppenrichtlinienverwaltung:
Ausnahmsweise mal ein Windows-Snippet, geschuldet dem iPad, welches mich seit iOS 7 quasi dazu zwingt.
Benötigt wird lediglich ein „static build“ von FFmpeg, welches HIER herunterzuladen ist.
Im .7z Archiv unter „ffmpeg-xy/bin“ befindet sich die Datei „ffmpeg.exe“, welche entweder im selben Verzeichnis wie die spätere Batch-Datei- oder – einfacher – nach „C:\Windows\System32“ kopiert werden darf. Da sich letzterer Pfad in der PATH Variable befindet, ist von jedem Ort aus der Aufruf von „ffmpeg“ möglich.
Die eigentlich Batch-Datei. Abzuspeichern beispielsweise als „convert.bat“:
1 2 3 4 5 6 7 8 | @echo off :next if "%~1" == "" goto done ffmpeg.exe -i "%~1" -vcodec libx264 -f mp4 -acodec libvo_aacenc -b:a 192k -b:v 1100k -ac 2 "%~1.mp4" shift goto next :done exit |
Durch das Ablegen von Dateien auf die Batch-Datei, werden diese konvertiert. Das Quell-Material bleibt erhalten und wird nicht gelöscht. Der neuen Datei wird ein „.mp4“ angehangen.
Die Zeile, in der die Konvertierung statt findet, kann angepasst werden. Im obigen Fall würde ein Video in eine MP4 Datei mit AAC Audio- und x264 Video-Spur konvertiert werden. Die Qualität des Videos entspricht mit 1100k etwa der, die man von den „Urlaubsfilmen“ der Größe 700MB aus dem Internet gewohnt ist. Ein Schelm, der böses dabei denkt. ;)
192k AAC-Audio sind meines Erachtens nach ausreichend. Auf einem mobilen Gerät wird vermutich niemand höhere Bitraten heraus hören.
Für HD-Material würde ich wahrscheinlich auf 2500-3000k hoch gehen, das ist allerdings sehr subjektiv.
Wer einen kostenlosen ESXi Server betreibt und gerne eine virtuelle Maschine auf einen anderen ESXi kopieren oder verschieben möchte, kann dies auch ohne das kostenpflichtige vCenter tun. Die rudimentäre Ausstattung der Server reicht hierfür aus.
Bedient wird sich dabei lediglich an scp, root-Zugriff vorausgesetzt.
1. Überpfrüfen, ob der SSH-Dienst ausgeführt wird, gegebenenfalls starten:
Host auswählen > Reiter „Konfiguration“ > Sicherheitsprofil > Dienste, Eigenschaften > SSH, Optionen > Dienst starten
2. Kann für Frustration sorgen: Auch die ausgehende Verbindung zum späteren Ziel-Server, muss in der Firewall explizit erlaubt werden:
Host auswählen > Reiter „Konfiguration“ > Sicherheitsprofil > Firewall, Eigenschaften > SSH-Client UND SSH-Server anhaken
Auf dem Ziel-Server wird genauso vorgegangen wie auf dem Quell-Server. Jedoch kann auf die Freigabe des SSH-Clients in der Firewall verzichtet werden.
Es kann nun die Verbindung zu Quell- und Ziel-Server geöffnet werden, etwa via PuTTY als SSH-Client.
Vorab sollten die Verzeichnisse auf Quell- und Ziel-Server bekannt sein. Um sich ein Bild der Struktur zu machen, wird „df -h“ ausgeführt, die Ausgabe ist als Beispiel auf der rechten Seite via PuTTY zu sehen.
Meine fiktive VM mit dem Namen „VM01“ liegt in dem Verzeichnis „/vmfs/volumes/ma22385.datastore2“ auf dem Quell-Server.
Ich möchte die VM „VM01“ nun auf den Ziel-Server in das Verzeichnis „/vmfs/volumes/ma33122.datastore1“ kopieren, dazu gehe ich wie folgt vor:
1 | scp -r /vmfs/volumes/ma22385.datastore2/VM01 root@Ziel-Server:/vmfs/volumes/ma33122.datastore1/ |
Nach Ausführung des Befehls, muss mit „yes“ das Vertrauen zum Ziel bestätigt werden; das passiert einmalig. Anschließend das Passwort des Ziel-Systems eintippen.
Da die VM als Ordner auf dem ESXi abgespeichert ist, der einige Dateien wie die Konfiguration, Festplatte und mehr beinhaltet, ist der Parameter „-r“ für die rekursive Übertragung angegeben.
Hinweis: Die VM muss vor dem Kopiervorgang natürlich ausgeschaltet sein, ansonsten wird „scp“ mit einem Fehler abbrechen.
Möchte man das Netzwerk nicht zu sehr belasten, kann mit einem Übertragungslimit gearbeitet werden, das „scp“ via Parameter „-l“ setzt. Das Limit ist in Kilobit/s definiert:
1 | scp -l 80000 -r [...] |
Nach der Übertragung läge die VM mit dem Namen „VM01“ in dem Verzeichnis „/vmfs/volumes/ma33122.datastore1“ auf dem Ziel-Server.
Es empfiehlt sich die übertragene (virtuelle) Festplatte nach dem Gang durch das Netzwerk zu überprüfen:
1 | vmkfstools --fix check /vmfs/volumes/ma33122.datastore1/VM01/VM01.vmdk |
Die Ausgabe sollte „Disk is error free“ lauten. Wurden Fehler gefunden, empfehle ich die Überprüfung der Netzwerkverbindung beider ESXi und eine anschließende Wiederholung der Übertragung. Zwar kann „vmkfstools“ mit der Anweisung „–fix repair“ einen Reperaturversuch unternehmen, jedoch würde ich der Stabilität wegen hierauf verzichten. In einer gesunden Netzwerkumgebung sollten sowieso keine Fehler auftreten. ;)
Nach der Übertragung und Überprüfung der VM, kann diese recht einfach in ihre neue Umgebung eingebunden werden.
Hierzu mit dem vSphere Client auf die Ziel-Maschine verbinden und folgende Schritte durchführen:
Host auswählen > Reiter „Übersicht“ > Unter „Resourcen“ den Datastore der neuen VM rechtsklicken > Datenspeicher durchsuchen > „VM01“ klicken (Name der übertragenen VM) > Rechtsklick auf VM01.vmx > Zur Bestandsliste hinzufügen
Achtung: Beim Einschalten der VM wird der ESXi Server merken, dass es sich um eine bewegte VM handelt und fragen, ob diese kopiert oder verschoben wurde. Durch die Auswahl „I moved it“ wird die VM wie sie war wieder eingeschaltet, MAC-Adresse und UUIDs bleiben erhalten. Diese Auswahl wird getroffen, falls die alte/kopierte VM nicht mehr hochgefahren- und gegebenenfalls gelöscht wird. Die Unterschiede der Optionen werden hier sehr schön erklärt