Windows Treiber via PowerShell installieren (Windows Server Core)

Treiber unter Windows an der Kommandozeile erstellen

Unter Windows Server 2012R2/2016/2019/2022 Core oder dem (kostenfreien) Hyper-V-Server gibt es bekanntlich keine GUI und konsequenterweise daher auch keinen Gerätemanager. Selbiger lässt sich auch nicht immer, vor allem wenn man noch „alleine“ ist, remote ansprechen. Wie kann man also da jetzt Treiber installieren/aktualisieren/entfernen? Also wie bekommt man Treiber auf einen Core Server?

Das kann man zum Glück ganz gut mit der PowerShell machen; genauer gesagt mit den guten alten CMD-Werkzeugen pnputil und devcon. Selbige kann man aber aus PowerShell-Schleifen heraus komfortabel starten.

Einen Treiber installieren

Man fügt einen bestimmten Treiber mit pnputil zum Windows-Treiber Repository hinzu.

pnputil.exe -i -a <PFAD>\oemdriver.inf

Alle Treiber aus dem aktuellen Verzeichnisses (mit Unterverzeichnissen) installieren

Zum Beisipel aus HPE oder DELL Repositories kann man so „mal eben“ alles in einem Rutsch zu Windows hinzufügen:

Get-ChildItem -Filter *.inf -Recurse | Select-Object FullName | ForEach-Object {pnputil -a $_.FullName}

Auflisten aller 3rd Party Treiber im Repository

Zeigt, auch unter einem „normal“ laifenden Windows, alle Dritt-Treiber an.

pnputil.exe -e

Entfernen eines Treibers aus Windows

Der <NAME> des Treibers findet sich in der Ausgabe von pnputil -e unter „Veröffentlichter Name“.

pnputil.exe -d oem<NAME>.inf

Aufgaben „XblGameSaveTask“ und „XblGameSaveTaskLogon“ von Windows Server entfernen

Es ist zwar irgendwie nett zu wissen, das man mit den aktuellen Windows Updates nun endlich auch auf seinem Windows Server (und auf Windows Server Core) vernünftig mit seinem X-Box Live Account spielen kann, aber notwendig ist das für den Unternehmensbetrieb eher nicht.

Windows Server brauchte DRINGEND unterstützung für XBox-Games

Wir wissen nicht was Microsoft dazu bewegt hat die Xbox „GameSaveTasks“ aus Server zu verteilen, zumal der Konzern selbst eher das genaue Gegenteil empfielt.

Lösung

Zum Glück kann man die entsprechenden Tasks schnell mit der PowerShell entfernen.

Hier ist die Copypasta:

Unregister-ScheduledTask -TaskName XblGameSaveTask -Confirm:$false
Unregister-ScheduledTask -TaskName XblGameSaveTaskLogon -Confirm:$false

PowerShell Connect-SPOService Fehler „Current site is not a tenant administration site.“

Beim Verbinden mit einer SPO (SharePointOnline) Site gibt die PowerShell unerwartet diesen Fehler zurück:

PS C:\> Connect-SPOService -Url https://<MYTENANT>.sharepoint.com
Connect-SPOService : Current site is not a tenant administration site.

Lösung

Man muss die Fehlermeldung nur genau lesen, dann merkt man das die URL zur admin Site tatsächlich so nicht stimmt …

PS C:\> Connect-SPOService -Url https://<MYTENANT>-admin.sharepoint.com

Und ja, ich habe grade auch viel zu lange gesucht … 😶‍🌫️

Kalender einer Ressource zeigt keinen Betreff an, sondern den Namen des Organisators

Ein Ressourcenpostfach (z.B. Shared Mailbox) ist in Exchange Online mit „AutoAccept“ (automatische Zusagen, AutomateProcessing) konfiguriert, damit der Kalender Besprechungsanfragen bestätigt.

Die Besprechungsanfragen werden auch korrekt automatisch angenommen. Der Besprechungsbetreff wird im Postfach des Organisators auch angezeigt.

Aber alle anderen Benutzer (mit Berechtigungen auf dem Postfach) sehen statt des Besprechungsbetreffs nur den Namen des Organisators.

Lösung

Dies ist das Standardverhalten von Exchange Online (und Exchange seit 2010) und seither irritierend. Das passiert immer dann, wenn AddOrganizerToSubject und/oder DeleteSubject auf True festgelegt sind.

Aktuelle Einstellung anzeigen:

Get-CalendarProcessing -Identity <RESSOURCE> | fl *subject*

Einstellungen ändern:

Set-CalendarProcessing -Identity <RESSOURCE> -DeleteSubject $false -AddOrganizerToSubject $false

DeleteSubject: Soll der Betreff entfernt werden? (true=ja)

AddOrganizerToSubject: Soll der Name des Organisierenden den Betreff ersetzen? (true=ja)

Outlook „Offline Adressbuch kann nicht heruntergeladen werden“ Fehler 0x8004010F

Outlook versucht im Cache Modus immer das Offline Adressbuch (OAB) zu synchronisieren. Der Prozess bricht aber gerne mal mit dem wenig hilfreichen Fehler 0x8004010F ab.

Das Problem tritt gerne nach Migrationen auf, wenn ein Exchange Server auf ein anderes System (oder neue VErsion) migriert wurde. Dabei wird nämlich ein neues OfflineAddressBook (OAB) generiert, welches auch die Verteilung der Adresslisten übernimmt.

Die Adressliste auf den Clients ist dann meist auch nicht mehr richtig (veraltete Inhalte), allerdigns ist im OWA alles korrekt und aktuell.

Lösung

Zuerst: An der EMS prüfen ob das Adressbuch als „Default“ markiert ist:

Get-OfflineAddressBook | select Name, IsDefault

Hier sollte ein IsDefault: True zurückkommen.

Dann kann man mit prüfen, ob das OAB auch korrekt via Autodiscover verbreitet wird:

Get-OfflineAddressBook | select Name, VirtualDirectories, *web*

Und hier passiert gerne der Fehler. Exchange kennt zwei verschiedene Varianten, um dem Client den Zugriff auf das OAB zu wemöglichen:

  1. Man gibt an welche (IIS-) Virtual Directories vom Client abgefragt werden können um das OAB herunterzuladen
  2. Man erlaubt allen Virtual Directories den Download anzubieten

Microsoft (und wir) raten natürlich zur Variante Nummer 2:

Set-OfflineAddressBook "Standard-Offlineadressbuch" -GlobalWebDistributionEnabled $true

Der Name „Standart-Offlineadressbuch“ ist hier exemplarisch, alle existierenden Offline-Adressbücher listet man mit Get-OfflineAddressBook auf.