ActiveDirectory: Clients in Domäne können keine biometrische Anmeldung einrichten (Fingerabdruck, Gesichtserkennung)

Problem:
Sobald ein Client der Domäne joined sind die Biometrie-Einstellugnen deaktiviert, außer man arbeitet mit Microsoft-Konto und Hello for Business! Der Benutzer kann keinen Fingerabdruck oder Gesichtserkennung zur Anmeldung aktivieren - Es kommt immer die Meldung: "Da hat etwas nicht geklappt" und der Button "Einrichten" ist ausgegraut.

Lösung:
Um die Biometrie-Anmeldung zu aktiviern muss man folgende vier Gruppenrichtlinien setze UND es darf keine "Hello for Business"-Richtlinei aktiv sein bze. aktiv gesetz werden:
1. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Verwendung von Biometrie zulassen > aktivieren
2. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Benutzeranmeldung mithilfe von Biometrie zulassen > aktivieren
3. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Domänenbenutzeranmeldung mithilfe von Biometrie zulassen > aktivieren
4. Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Anmelden > Komfortable PIN-Anmeldung aktivieren > aktivieren

Nach Aktivierung dieser GPOs und einem Reboot konnte der Fingerabdruckssensor verwendet werden.
Quelle der Lösung:
Windows 10 Anmeldung mit Fingerabdruck in Active-Directory Domäne via GPO erlauben

Server 2016: VSS-Sicherung erzeugt Event 513 - Microsoft-Windows-CAPI2

Problem:
Ich habe eine unschöne Anzeige im Eventlog meiner Server 2016. Immer wenn ein VSS-Backup gezogen wird, erhalte ich folgende unschöne Fehlermeldung, die zwar nichts macht, aber unsauber aussieht:
Protokollname: Anwendung
Quelle: Microsoft-Windows-CAPI2
Ereignis-ID: 513
Aufgabe Kategorie: keine
Ebene: Fehler

Beschreibung
Fehler im Kryptografiedienste beim Verarbeiten der OnIdentity()System Writer-Objekt aufrufen.

Details:
AddLegacyDriverFiles: Nicht binäre Microsoft Link Layer Discovery Protocol Bild zurück.

Systemfehler:
Zugriff wurde verweigert.


Ursache:
Das NT AUTHORITY\SERVICE (Dienstkonto) hat keinen Zugriff auf das VSS Writer System

Lösung:
Man kann dem Dienstkonto diese Berechtigung zukommen lassen:

Öffnen Sie ein administratives Eingabeaufforderungsfenster, und führen Sie den folgenden Befehl zum Überprüfen der aktuellen Berechtigungen:
sc sdshow mslldp

Kopieren Sie die Ausgabe aus Schritt 1 und hängen dahinter noch den Zusatz "(A;;CCLCSWLOCRRC;;;SU)". Führen Sie den folgenden Mslldp-Befehl aus, um die Berechtigung hinzuzufügen:
sc sdset mslldp MSLLDP-STRING

Beispiel:
sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)

Bei erfolgreicher Durchführung erhalten Sie folgende Meldung:
[SC] SetServiceObjectSecurity ERFOLG


Quelle:
Microsoft Support: Event ID 513 when running VSS in Windows Server

Windows 10 und Server: SMBv1 wieder aktivieren/deaktivieren

Problem:
Ab Windows 10 1709 wird das SMBv1-Protokoll nicht mehr standardmäßig installiert. Es stehen nur noch SMBv2 und v3 zur Verfügung. Da ich noch Drucker und NAS-Systeme habe, die leider außschließlich SMBv1 verwenden, musste ich das übergangsweise aktivieren.

Lösung:
Hier die Powershell-Befehl um SMBv1 abzufragen, zu akivieren und wieder zu deaktivieren:
Status abfragen:
Get-WindowsFeature FS-SMB1

Deaktivieren:
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Aktivieren:
Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol

ACHTUNG: ES WIRD NICHT EMPFOHLEN SMBv1 DAUERHAFT ZU AKTIVIEREN AUFGRUND VIELER SICHERHEITSLÜCKEN IN DIESEM PROTOKOL!!!

Quelle: Microsoft Support: Erkennen, Aktivieren und Deaktivieren von SMBv1, SMBv2 und SMBv3 in Windows und Windows Server

Netzwerk: Umstellung der IP-Range in einem ActiveDirectory-Netzwerk

Ich musste die IP-Range eines Standortes komplett ändern, da dieser an unser Netzwerk gekoppelt werden sollte und hier die gleichen IP-Ranges vorlagen. Somit wäre ein Routing zwischen den Standorten nicht möglich gewesen.
Die nachfolgende Liste zeigt meine Gedanken und Vorgehensweisen bzw. Lösungen und ist wahrscheinlich nicht vollständig?!

Vorbereitung für IP-Bereichs-Änderung
- Reverse-Lookup-Zone für neuen Bereich im DNS anlegen
- Replikation der neuen Zone auf DNS-Server prüfen
- DCDIAG erstellt und gespeichert
- DC-Replikation geprüft
- Statische DNS-Einträge dokumentieren
- Eventuelle Skripte oder Dienste auf statische IP-Einträge prüfen (Backups, Netlogon, SMTP etc.)
- Wenn möglich statische IP-Einträge gegen DNS-Einträge tauschen und testen
- Geräte mit festen IPs dokumentieren (z.B. Drucker, Terminals etc.) -> manuelle Anpassung nötig
- DHCP-Optionen dokumentieren
- DHCP-Reservierungen dokumentieren
- Liste mit allen aktiven IP-Adressen und dazugehörigen Geräten erstellen
- Firewall-Regeln dokumentieren
- Routing in der Firewall dokumentieren
- Virenscanner oder anderen Dienste dokumentieren, die IP-Adressen zur Standort-Erkennung verwenden

Umstellung am ersten DC mit FSMO-Rollen
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS sich selbst eintragen
- WINS- und DNS-Dienste starten um Dienstbindung durchzuführen
- ipconfig /flushdns (löscht DNS Cache)
- nbtstat –RR (löschte WINS Cache)
- ipconfig /registerdns (DNS neu registrieren)
- dcdiag /fix (Fixt Probleme im DC und schreibt einige Einträge neu)
- DNS-SRV-Einträge im DNS prüfen ggf. alte löschen (Wichtig sind _GC)
- Restart netlogon

Umstellung der anderen Domain Controller
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS korrekt eintragen (sich selbst als 2. Server eintragen)
- WINS- und DNS-Dienste starten um Dienstbindung durchzuführen
- ipconfig /flushdns (löscht DNS Cache)
- nbtstat –RR (löschte WINS Cache)
- ipconfig /registerdns (DNS neu registrieren)
- dcdiag /fix (Fixt Probleme im DC und schreibt einige Einträge neu)
- DNS-SRV-Einträge im DNS prüfen ggf. alte löschen (Wichtig sind _GC)
- Restart netlogon
- Replikation der DCs testen über "AD Standort und Dienste"
- dcdiag ausführen und speichern
- Ereignisanzeige prüfen

Umstellung DHCP-Server
- Alten DHCP-Scope löschen
- Neuen DHCP-Scope eintragen und Optionen festlegen
- Vorherige DHCP-Reservierungen wiederherstellen
TIPP: Zum Umzug des DHCP-Servers habe ich eine gute Anleitung geschrieben, in der man auch die IP-Range anpassen kann:
DHCP: Einfacher Umzug DHCP-Dienst auf neuen Server mit Anpassung Scope, allen bestehenden Leases und Reservierungen

Umstellung der Memberserver, Clients und sonstiger Geräte
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS korrekt eintragen
- ipconfig /flushdns (falls möglich)
- nbtstat –RR (falls möglich)
- ipconfig /registerdns (Falls möglich/nötig)
- Prüfen der DNS-Einträge auf den DNS-Servern
- eventuellen Restart der Maschinen, Dienste oder Geräten

Sonstige Anpassungen
- Statische DNS-Einträge auf neue IPs ändern
- Dienste und Geräte ggf. anpassen, die nicht auf DNS-Einträge geändert werden konnten
- Firewall-Regeln anpassen
- Routing in Firewall und Netzwerk anpassen
- Virenscanner und andere Dienste anpassen für Standort-Erkennung

Abschlusstests Active Directory
- DCDIAG prüfen
- Eventlogs prüfen
- Alle wichtigen Dienste prüfen (Mail, Fileshares, Datenbanken etc.)
- externe Zugriffe (z.B. VPN) prüfen
- Backup prüfen
- Wichtige Geräte prüfen auf Erreichbarkeit (USV, Switche etc.)

Hier einige Quellen, die mir bei der Lösung geholfen haben:
Microsoft: Change the static IP address of a domain controller
Yusuf: Die IP – Adresse eines Domänencontrollers ändern
ACE FEKAY: So you want to change your IP range?

Windows 10 / Server 2016: Client bezieht seine Updates direkt von WU und nicht mehr vom WSUS (Dual Scan)

Problem:
Alle Windows 10 Clients und Windows 2016 Server haben sich plötzlich Ihre Updates nicht vom WSUS sondern direkt von Microsoft geholt. Da ich die Kontrolle über meine Updates haben wollte, habe ich mich mit dem Problem beschäftigt und fand auch die Ursache "Dual Scan". Hierbei handelt es sich um einen Update-Mechanismus von Microsoft, der mit Windows 10 1607 bzw. dem Cumulative Update KB4034658 vom August 2017 eingeführt wurde. Wie kann ich jetzt meine Updates wieder selbst kontrollieren?

Lösung:
Dualscan wird immer dann aktiviert, wenn man per GPO einen WSUS-Server den Clients zuweist und gleichzeitig Qualitäts- oder Feature-Updates zurückstellt.
Um das "Problem" zu kontrollieren benötigen Sie die GPOs von Windows 10 1607 und das obengenannte Update KB4034658 für Windows 10 und Server 2016. Wenn Sie die Updates und GPOs (zentrale GPOs bei einer AD) eingespielt haben
Danach finden Sie in den GPOs unter
"Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows Update" den Punkt ""Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" Diesen aktivieren Sie und danach wird der Client wieder seine Updates vom WSUS beziehen.
Sollte eine GPO nicht möglich sein, dann können Sie das Ganze auch über die Registry steuern:
Registry Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Value Name: DisableDualScan
Value Type: REG_DWORD
Values: 1 (Enabled) oder 0 (Disabled)

Quelle: Tchnet: Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed



“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz