Archiv der Kategorie: Microsoft

Dynamic Disks mit Windows RAID mit PowerShell verwalten

Veröffentlicht am von — Keine Kommentare ↓

Wie kann man die Windows PowerShell verwenden, um dynamische Datenträger zu verwalten, wie zum Beispiel den Status eines RAID zu untersuchen?

Nicht.

Die „dynamischen Datenträger“, die seit Windows 2000 integraler Bestandteil von Windows und Windows Server, sind „veraltet“ und werden irgendwann entfernt. Obwohl die dynamischen Laufwerke weiterhin verfügbar sind und relativ viel genutzt werden, stellt Microsoft keine PowerShell-Cmdlets zum Verwalten der dynamischer Datenträger zur Verfügung.

Das einzige Cmdlet das helfen könnnte (das wir kennen) ist Get-Volume, das immerhin auch dynamische Volumes anzeigt. mit Get-PhysicalDisk und Get-StorageAdvancedProperty kann man dann noch den Status der Physischen Disks ansehen, aber damit war es das auch schon.

Hinweis: Das selbe geschieht auch im ServerManager. Der kann dynamische Laufwerke auch schon nicht mehr anzeigen.

Es bleibt wohl nur die Migration in Richtung StorageSpaces …

Schade 😑

AADConnect synchronisation manuell starten oder erzwingen

Veröffentlicht am von — Keine Kommentare ↓

Dies ist wieder so ein „Schnipsel den man ständig braucht“ Beitrag.

Der ActiveDirectory Admin möchte nach einer Objektänderung diese „sofort“ ins Azure AD synchronisiert wissen und nicht die üblichen 30 Minuten warten.

Synchronisation starten

An der PowerShell auf dem AADConnect-Server ist das in zwei Zeilen (ausgeführt als Admin) erledigt:

Start-ADSyncSyncCycle

Gegebenenfalls ist vorher noch der Import des ADSync Moduls erforderlich (sollte ab PowerShell 3.0 aber automatisch erfolgen.)

Das Cmdlet stößt den Sync nur an, daher sollte die Rückmeldung Success recht schnell erfolgen.

Der eigentliche Prozess dauert (je nach Objekt- und Änderungsmenge) etwas länger, kann aber einfach im Synchronization Service überwacht werden. (Auch ersichtlich an der CPU-Last der Maschine 😉)

Neue Vollsynchronisation starten

Das Cmdlet startet standardmäßig nur einen „Delta“ Sync (-PolicyType Delta). In seltenen Fällen ist allerdings eine neue „Vollsynchronisation“ notwendig. Auch diese lässt sich „sofort“ via PowerShell starten:

Start-ADSyncSyncCycle -PolicyType Initial
Hinweis:

Dieses Vorgehen sollte ausschließlich als manuelle „Ausnahme“ des herkömmlichen Intervalls dienen und sollte nicht verwendet werden um automatisiert das „AllowedSyncCycleInterval“ des AADConnect schedulers zu unterschreiten. Dies könnte bei zu häufiger verwendung dazu führen, dass Microsoft weitere Sync-Vorgänge vorübergehend nur in *noch größeren* Abständen zulässt um einer Überlastung der AAD Dienste vorzubeugen.

TLS 1.2 via PowerShell aktivieren

Veröffentlicht am von — 1 Kommentar ↓

TLS-Protokoll (Transport Layer Security) liegt in der Version 1.2 vor. TLS hat zwar schon viele Iterationen hinter sich, wobei Version 1.2 in RFC 5246 definiert ist, aber die meisten Programme heute setzen mindestens TLS 1.2 voraus. Vor allem PowerShell Scripts und AADConnect (Azure AD Connect) benötigen ein .NET Framework 4, bei dem TLS 1.2 explizit aktiviert (und als Minimum erzwungen) ist.

Unter Server 2016 und 2019 geht das natürlich via Registry-Gehacke oder für faule Admins mit diesem simplen PowerShell-Script (ausgeführt als Administrator).

New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force

New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force

New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force

    New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force

New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force

New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force
    
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force
    
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
    
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force

New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force
    
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force

Windows DHCP Server per PowerShell migrieren

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓
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/ 👍