VMware vSphere PowerCLI (PowerShell) Portgruppe mit VLAN hinzufügen

Da virtuelle Standard Switches (vSwitches) Hostsache sind und nicht via vCenter „verteilt“ werden können, ist es sinnvoll so eine Aufgabe für mehrere Hosts zu automatisieren. Dank PowerCLI ist so ein Rollout aber verhältnismäßig schnell erledigt.

Neue Portgruppe mit VLAN (tagged) zu vSwitch0 auf einem ESXi hinzufügen

Das PowerCLI importieren und mit dem vCenter verbinden:

PS C:\> Import-Module VMware.PowerCLI
PS C:\> Connect-VIServer vcenter.example.fqdn

Dann kann man direkt die Portgruppe hinzufügen

Get-VMHost -name <ESXHOST> | Get-VirtualSwitch -Name <vSWITCH> | New-VirtualPortGroup -name <PORTGRUPPEN-NAME> -VLanId <ID>

Beispiel: Auf Host „esx15“ Portgruppe „vlan_11“ mit dem vlan tag „11“ zum „vSwitch0“ hinzufügen:

Get-VMHost -name esx15 | Get-VirtualSwitch -Name vSwitch0 | New-VirtualPortGroup -name vlan_11 -VLanId 11

Alle ESXi Hosts im Cluster auf einmal

Alle Host im Cluster kann man mit einer einfachen Schleife erreichen:

$VMHosts = Get-cluster <CLUSTER-NAME> | Get-VMHost

foreach ($VMHost in $VMHosts) {

    Get-VMHost -name $VMhost | Get-VirtualSwitch -name vSwitch0 | New-VirtualPortGroup -name <PORTGRUPPEN-NAME> -VLanId <ID>

}

Event-ID 36871 – Schwerwiegender Fehler beim Erstellen der Client-Anmeldeinformationen für TLS

Im Ereignisprotokll taucht Event 36871 auf: Der interne Fehlerstatus is 10013

Wenn im Ereignisprotokoll das Ereignis 36871 auftaucht, ist Windows irrigerweise der Meinung das ein „Schwerwiegender Fehler beim Erstellen der Client-Anmeldeinformationen für TLS. Der interne Fehlerstatus is 10013“ aufgetreten sei.

Je nach Anwendungsfall ist es warscheinlich, das ein Programm auf den Schlüsselspeicher unter

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

zugreifen wollte. Das scheint fehlgeschlagen zu sein, vermutlich wegen fehlernde Berechtigungen.

Auf diesen Ordner und alle Dateien darin sollten diese Benutzer Vollzugriff haben:

  • Netzwerkdienst
  • SERVICE
  • SYSTEM
  • IUSR

Wenn das neu gesetzt wurde, ist der Fehler in aller Regel sofort verschwunden.

Danke an https://www.der-windows-papst.de/2021/02/02/der-interne-fehlerstatus-ist-10013/ 👍

Windows Update Fehler 80243004

Windows Update Fehler 80243004

Auf verschiedenen Kundensystemem mit Windows Server 2008R2 (ja, die gibt’s noch) sehen wir in letzter Zeit diesen Fehler. Windows Updates lassen sich nicht mehr installieren und die Traybar sieht etwas seltsam aus:

Windows Update Fehler 80243004 - Traybar leere Symbole
Die Traybay sieht bei dem Windows Update Fehler 80243004 etwas komisch aus

Die Suche nach neuen Windows Updates funktioniert zwar, aber es tritt bei der Installation immer wieder der Fehler 80243004 auf.

Es gibt gleich zwei Lösungen für das Problem:

  1. Reboot: Nach dem Neustart funktioniert die Installation ohne Fehler
  2. Ohne Reboot: Eigenschaften der Taskleiste -> Infobereich „Anpassen“ -> Windows Update-Symbol von „Nur Benachrichtigungen anzeigen“ umstellen auf „Symbol und Benachrichtigungen anzeigen“

Danach laufen die Windows Updates auf dem System wieder einwandfrei, der Fehler 80243004 ist behoben.

Windows 7 OneDrive Fehler 0x8004de40 beim Anmelden

Es ist selten geworden, aber ab und zu taucht noch irgendwo ein „superwichtiger“ alter Windows 7 Client auf. Windows 7 mag nicht immer freiwillig TLS 1.2 sprechen und hat eine WinHTTP Standartkonfiguration, die keine „modern services“ zulässt. Daran scheitern OneDrive, Outlook und andere Microsoft 365 Services und auch private Live-Knto („Microsoft-Konto“) Anmeldungen. Der Fehler 0x8004de40 ist aber immer der selbe und meint „Crypto mit der Cloud schlägt fehl“.

Lösung

Unter Windows 7/8, Server 2008R2/2012/R2 hilft folgendes:

Spätestens jetzt sollte OneDrive wieder fehlerfrei laufen. Wenn das nicht der Fall sein sollte ist es mit an Sicherheit grenzender Warscheinlichkeit eine Drittsoftware (Antivirus, personal Firewall, Security-Software …) oder eine Middlebox (Firewall, SSL-DPI, Security-Kram) vor dem Internet.

Zertifikate im Windows Zertifikatsspeicher umbenennen

Bis vor kurzen wusste ich nicht: Man kann den Anzeigename eines Zertifikats im Zertifikatsspeicher ändern. Die ‚certmgr‘ Konsole lässt das zwar nicht zu, aber an der PowerShell ist das durchaus möglich.

Das XBL Zertifikat aus diesem Beispiel soll umbenannt werden.

1. Den Fingerprint (Thumbprint) des Zertifikates ermitteln:

Get-ChildItem -path cert:\LocalMachine\my | Select Subject,Thumbprint,Friendlyname

2. Thumbprint von oben kopieren und den FriendlyName davon direkt ändern:

(Get-ChildItem -Path Cert:\LocalMachine\My\<THUMBPRINT>).FriendlyName = ‘Neuer Name’