Deinstallieren von Software mit PowerShell

Auf einem Windows Server Core, kann installierte Software mit den folgenden PowerShell Befehlen deinstalliert werden.

# Anzeige der installierten Software
Get-WmiObject -Class Win32_Product | Select-Object -Property Name
# Erstellen einer Variablen für die Deinstallation der Software
$App = Get-WmiObject -Class Win32_Product | Where-Object{$_.Name -eq "5nine Manager for Hyper-V"}
# Deinstallieren der Software
$MyApp.Uninstall()

Das funktioniert natürlich nicht nur auf dem Windows Server Core, doch dort ist es die einfachste Möglichkeit Software wieder los zu werden.

Enjoy it, b!

Notepad++ läuft auf Windows Server Core (unter Umständen nicht mehr)

Update 27.08.2021:
Die letzte Version von Notepad++ die auf Windows Server Core (getestet habe ich mit dem 2019er Release) läuft ist Version 7.9.2. In allen darauf folgenden Versionen funktioniert eine Reihe von Dialogen nicht mehr, wie zum Beispiel das Öffnen oder Speichern von Dateien.

Ich habe darum alle mein Windows Server Core Installation mit dieser letzten Version “aktualisiert” und das Auto-Update abgeschaltet.

image

Dazu ist es ausreichend in der config.xml den Eintrag wie oben auf no zu setzen. Aktuell ist seit März 2021 auf Github auch ein Bug (Issue) offen, allerdings mit relativ wenig Aktionen dahinter.

Das Problem hängt mit der comdlg32.dll zusammen, die auf Windows Server Core nicht vorhanden ist und seit Version 7.9.3 und danach verwendet wird.

Ursprünglicher Beitrag:
Für den Windows Server Core war ich schon einige Zeit auf der Suche nach einem ordentlichen Editor um auf Dev-Systemen Scripte etc. an zu passen …

Nun hatte ich neulich auf einem neuen System, wohl mehr aus versehen, ein Paket mit Notepad++ Version 7.x installiert (den Editor nehme ich unter Windows 10 und Windows Server mit GUI) und war überrascht, dass dieser problemlos funktionierte. Ich hatte Notepad++ vor sehr langer Zeit (das kann durchaus unter Windows Server 2008 Core) getestet und aus den Augen verloren – da er dort nicht funktionierte!

image

Here we go Smile

Enjoy it, b!

Supermicro X11SCH-F “other devices”

Nach der Installation von Windows Server 2019 wird für das Supermicro X11SCH-F Motherboard eine Reihe von unbekannten Geräten (other devices) angezeigt, für die kein Treiber installiert werden wurde.

image

Würden wir uns auf einem Windows Server ohne GUI (Desktop Experience) befinden, dann wäre DevManView von Nirsoft die erste Wahl um die korrekte Installation von Treibern und Geräten zu kontrollieren. Das Tool ist kostenfrei und gehört nach meiner Meinung auf jeden Windows Server Core, aber das nur nebenbei.

Die Lösung dieses Problems, habe ich in Teilen in diesem Blog beschreiben. Interessanter Weise hat aber die Installation des aktuellsten Intel Chipset INF Utility nicht alle Geräte korrekt mit Treibern versorgt.

image

Übrig geblieben sind zwei Geräte mit der Bezeichnung PCI Simple Communications Controller

image

Windows Update wollte für die beiden Geräte ebenfalls keine Treiber bereitstellen und so war etwas Recherche notwendig, um hier eine Lösung zu finden. Für mich interessant war, dass Supermicro ebenfalls auf seiner Webseite einen Intel Chipsatz Treiber anbietet, der nicht ganz der aktuellen Version von Intel entspricht, dass Problem aber behoben hat.

image

Dabei gab es aber noch ein kleineres Problem zu lösen. Wenn nun schon das aktuelle Intel Chipset INF Utility installiert wurde, bemerkt das der Installer infinst_autol.exe und bietet ein Downgrade an, was natürlich eine Option sein könnte. Eine Alternative ist aber, explizit mit einem rechten Mausklick und Update driver, den Pfad für den Treiber mit anzugeben.

image

Die Installation muss explizit für jedes Gerät erfolgen:

  1. Rechtklick und Auswahl von Update driver
  2. Auswahl von Browse my computer for driver software
  3. Über die Option Browse den Pfad zum Treiber für Windows 10-x64 angeben und den Treiber installieren

    C:\Users\Administrator\Downloads\Chipset_v10.1.17861.8101\DriverFiles\production\Windows10-x64

Beide Geräte wurden damit erfolgreich erkannt.

image

image

Da es sich um Treiber für die Intel Management Engine handelt, wäre möglicher Weise eine Suche nach einen passenden Treiberpaket dafür ebenfalls von Erfolg gekrönt gewesen. Letztendlich hat es aber so auch funktioniert.

Enjoy it, b!

Sehr langer Shutdown oder Reboot des Microsoft Hyper-V Server 2016

In den Windows Server 2016 haben sich je eine Reihe von Eigenheiten eingeschlichen, die mir immer wieder Probleme bereiten. Kürzlich hatte ich mit dem Microsoft Hyper-V Server 2016, wieder das Problem, dass einige Hosts für den Shutdown sehr lange benötigt haben. Mit sehr lange meine ich, bis zu einigen Stunden!

Daher habe ich mir das Problem genauer angeschaut und dabei die Lokation des Pagefiles als Auslöser ausmachen können. Damit kann die in diesem Blog beschriebene Lösung auch hier zum Einsatz kommen. Da der Microsoft Hyper-V Server keine Benutzeroberfläche hat, muss das Pagefile über WMIC neu konfiguriert werden.

Anzeige des aktuell konfigurierten Pagefiles.

wmic pagefile list full

Umstellung auf ein nicht durch das Betriebssystem konfiguriertes Pagefile.

wmic computersystem where name=”%computername%” set AutomaticManagedPagefile=False

Konfiguration des Pagefiles auf Laufwerk C: mit einer Startgröße von 16GB und einer maximalen Größe von 32GB. Soll das Pagefile mit einer festen Größe angelegt werden, dann ist es notwendig InitialSize und MaximalSize auf den gleichen Wert zu setzen.

wmic pagefileset where name=”C:\\pagefile.sys” set InitialSize=16384,MaximumSize=32768

Die Änderungen werden erst nach einem Neustart des Servers durch WMIC angezeigt, hier sollte man sich also nicht beirren lassen. Insofern WMIC keine Fehlermeldungen zurück gibt, ist die Konfiguration korrekt erfolgt.

Abschließend habe ich mir die Frage gestellt, wieso das Problem eigentlich auftritt. Ich kann dieses Verhalten nämlich nicht bei allen Hyper-V Hosts mit der Version 2016 feststellen. Microsoft selbst liefert in einer Reihe von Artikeln und Blogs Empfehlungen zur Dimensionierung von Pagefiles. Für Hyper-V Systeme, kann man das kurz abfassen.

  1. Geht dem Host der Speicher aus, und ist eine VM mit dynamisch allokiertem Speicher unterwegs dann erfolgt ein Paging in der VM und nicht auf dem Host
  2. Es genügt, dass der Host einen Kernel- oder von mir aus noch Active-Dump schreiben kann. Kernel-Dumps habe ich bisher, auch bei sehr großen Systemen (1TB … und mehr) keinen größer als 20GB gesehen und damit war er für eingehende Analysen immer ausreichend

Darum habe ich auf kleinen Hyper-V Hosts (32GB RAM und 64 bzw. 72GB Systemlaufwerk) keine Probleme gehabt und auch auf zwei meiner größeren Systeme mit 128GB RAM und einem 256GB großem Systemlaufwerk, ist das Problem nicht aufgetreten.

image

Lediglich auf mehreren Hosts mit 256GB RAM und einem 72GB großen Systemlaufwerk, bin ich auf dieses Problem getroffen und habe es wie oben beschrieben gelöst. Dabei ist verständlich, dass das Betriebssystem bei 256GB Hauptspeicher das Pagefile auf ein Laufwerk mit hinreichend viel Platz legt und es dadurch zu dem Verhalten kommen kann.

Enjoy it, b!

Server Core: Eine Alternative zum Resource Monitor

Windows Server Core und auch der Microsoft Hyper-V Server lassen die notwendigen Funktionen vermissen, damit der Windows Resource Monitor auf diesen ausgeführt werden kann.

Ich mag den Resource Monitor sehr, ermöglicht er doch einen schnellen Blick auf die Auslastung des Systems und zusätzlich zum Task Manager die Möglichkeit die Disks im Auge zu behalten.

Eine generelle Alternative zum Taskmanager, auch mit der Option diesen zu ersetzen, stellt der Process Explorer von Sysinternals dar. Dieser bietet eigentlich alles und noch viel mehr als dieser, zeigt aber wiederum die Netzwerkauslastung nicht so schön an.

Da der Versuch den Resource Manager zu starten, auf den Core Versionen des Windows Servers ohnehin nur eine Fehlermeldung produziert, dachte ich mir es wäre praktisch darüber den Process Explorer starten zu können.

Die folgende Abbildung zeigt das Problem …

image

… die Lösung dazu ist relativ einfach. Es muss lediglich ein Hardlink erstellt werden. Dabei wird der Pfad des Process Explorers als Resmon.exe in das Windows System Verzeichnis gelinkt.

:: Erstellen eines Hardlinks mit mklin.exe

C:\Windows\System32> mklink resmon.exe "c:\Program Files (x86)\Windows Sysinternals Tools\procexp.exe" /h
Hardlink created for resmon.exe <<===>> c:\Program Files (x86)\Windows Sysinternals Tools\procexp.exe

Mit diesem Workaround startet der Process Explorer und bietet über seine System Info einen Einblick zur aktuellen Auslastung (I/Os) der Platten.

image

Update 2022-09-12:
Oben wurde fälschlicher Weise auf den Process Monitor und nicht auf den Process Explorer verwiesen. Danke Tobi für den Hinweis!

Enjoy it, b!

Update Avago / LSI 9261-4i Controller auf dem Windows Server Core

Meine Vorliebe für den Windows Server Core und vor allem den Microsoft Hyper-V Server dürfte bekannt sein. Das Arbeiten auf diesen System ist sehr mit der Kommandozeile behaftet, egal ob PowerShell oder die cmd.exe Verwendung finden.

Wenn irgendwie möglich setzte ich in meinen Server immer RAID-Controller von LSI (inzwischen Avago) ein. Der Weg dahin war vorgezeichnet:

  1. Mit den 3Ware Controllern fing alles an und 3ware wurde dann von LSI gekauft
  2. LSI kam bisher immer mit den 92xx-xi Controllern zum Einsatz, also 9240-4i, 9261-8i, 9271-8i, usw.
  3. Dann hat Avago LSI übernommen, führt aber die Controller weiter (im Gegensatz zu LSI, wo die 3Ware Controller nicht mehr weiterentwickelt wurden

Genug der Geschichten … der Update eines LSI Controllers auf Windows Server Core ist kein Hexenwerk, es müssen drei Komponenten aktualisiert werden.

  1. Management (MegaRAID Storage Manager)
  2. Firmware
  3. Windows Treiber

Die entsprechenden Pakete findet man auf der Avago Homepage und können dort herunter geladen werden. Die Links stammen vom Updates eines LSI MegaRAID 9261-8i.

Unter Support Documents and Downloads auf der Avago Homepage (http://www.avagotech.com) folgende Suche absetzen:

image

Alle Downloads entpacke ich in das Verzeichnis c:\temp\lsi – für die jenigen welche auf dem Server Core keine unzip.exe haben, einfach lokal entpacken und auf den Server drauf kopieren.

Das sieht dann wie folgt aus:

image

Wieso LSI den Storage Manager 2x verpackt hat, erschließt sich mir nicht – dennoch, irgendwann taucht mal die setup.exe auf.

Für uns sind hier nun folgende Dateien wichtig:

image

Im ersten Schritt machen wir ein Update des MegaRAID Storage Managers. Dabei werden, in dieser Version zumindest, alle Einstellungen gelöscht (also auch die Benachrichtigung per Email) welche im Anschluss dann wieder gesetzt werden müssen.

Dazu einfach c:\temp\lsi\msm\disk1\setup.exe starten und sich durch den Wizard klicken.

Der Storage Manager läßt sich danach über das folgende Script starten.

C:\Program Files (x86)\MegaRAID Storage Manager\startupui.bat

Diese Datei kopiere ich unter einem anderen Namen (mr.cmd) in folgendes Verzeichnis c:\program files\script (mit diesem ich die Pfad Variable erweitert habe) und nehme dazu folgende Modifikationen vor:

@Echo off

:: mr.cmd

rem %~d0
rem CD %~dp0

pushd "%ProgramFiles(x86)%\MegaRAID Storage Manager"

start JRE\bin\javaw -DVENUS=true -classpath .;GUI.jar;monitorgui.jar;DebugLog.jar;log4j-1.2.15.jar;jaxen-1.1.jar;jdom-1.1.jar GUI.VivaldiStartupDialog ajsgyqkj=71244

popd

Damit kann ich den Raid Manager von jedem beliebigen Verzeichnis aus starten.

Nun kann über den MegaRAID Storage Manager das Update der Controller Firmware vorgenommen werden.

image

Was bei LSI Controllern meistens online – also ohne einen Neustart erfolgen kann.

Zum Ende kommt nun noch die Installation des Windows-Treibers, welches ich über pnputil.exe erledige. Dazu muss ich in das Verzeichnis mit dem richtigen Treiber (win8.1_x64 = Windows Server 2012 R2) wechseln und folgenden Aufruf durchführen:

pnputil -i -a MegaSAS2.inf

Damit der Treiber dann auch geladen wird, ist allerdings ein Neustart notwendig. Mit SigCheck.exe aus den Sysinternals Tools läßt sich dann auch die Version des geladenen Treibers ermitteln.

C:\Temp>"\Program Files (x86)\Windows Sysinternals Tools\sigcheck.exe" C:\Window
s\system32\DRIVERS\megasas2.sys

Sigcheck v2.30 - File version and signature viewer
Copyright (C) 2004-2015 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\windows\system32\drivers\megasas2.sys:
        Verified:       Signed
        Signing date:   12:10 PM 9/10/2015
        Publisher:      Avago Technologies U.S. Inc.
        Company:        Avago Technologies
        Description:    MEGASAS RAID Controller Driver for Windows
        Product:        MEGASAS RAID Controller Driver for Windows
        Prod version:   6.709.12.00
        File version:   6.709.12.00
        MachineType:    64-bit

Falls nicht geschehen, nochmals das Alerting (per Emails) konfigurieren.

Enjoy it, b!