Windows DHCP Server per PowerShell migrieren

Auf dem „neuen“ Server muss die DHCP-Rolle installiert sein, alle Schritte werden direkt auf der neuen Maschine durchgeführt. Die Autorisierung in der Domäne braucht noch nicht durchgeführt werden (ist aber auch nicht schlimm).

DHCP Konfiguration exportieren

Die collständige DHCP-Konfiguration einschliesslich aller Bereiche, leases, Severoptionen und so weiter lässt sich in einem Rutsch in einen vorhandenen Pfad exportieren:

Export-DhcpServer -ComputerName <ALTERSERVER> -Leases -File C:\Temp\dhcp-export.xml -verbose
DHCP Server migrieren – Export der Konfiguration

DHCP Konfiguration importieren

Es kann direkt wieder importier werden. Der BackupPath ist Pflicht, muss angegeben werden und enthält hinterher die vorhergehende Konfiguration (also ‚alte‘) des Servers

Import-DhcpServer -ComputerName <NEUERSERVER> -Leases -File C:\Temp\dhcp-export.xml -BackupPath C:\temp -Verbose

Die Ausgabe ist deutlich länger, aber am Ende steht der erfolgreiche Importdes DHCP Servers.

DHCP Server autorisieren, alte DHCP Autorisierung aufheben

Der neue Server sollte sich beim Import automatisch autorisiert haben, wenn nicht muss das nachgeholt werden – sonst verteilt der DHCP keine IP-Adressen.

Die Autorisierung des alten DHCP kann dann auch im gleich Zug zurückgenommen werden, natürlich komfortabel an der PowerShell:

Remove-DhcpServerInDC -DnsName <ALTERSERVER-FQDN>

Ein neuer Server kann genauso einfach als „autorisiert“ hinzugefügt werden:

Add-DhcpServerInDC -DnsName <ALTERSERVER-FQDN>

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’