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

WSUS-Server: Content-Bereinigung und Optimierung - WSUS-Reset

Problem:
Ich habe versehentlich eine verraltete Kategorie im WSUS hinzugefügt und die Synchronisation hat dann alle Patches für diese Kategorie heruntergeladen und mir dabei auch noch die Platte vollgeschrieben. Da meine WSUS-Content NICHT Auf der Systemplatte liegt, war das für den Server kein Problem, aber ich wollte die überflüssigen Patches wieder von der Platte haben und gleichzeitig für die Zukunft das Problem lösen

Lösung:
Zuerst einmal musst der Content berreinigt werden. Das habe ich wie folgt gemacht:
- Als erstes alle unerwünschten Patches ablehnen bzw. nicht genehmigen
- In den Einstellungen unter "Dateien und Sprchen aktualisieren" wechseln
- Hier den Punkt "Updatedateien auf diesem Server nur herunterladen, wenn Updates genehmigt" aktivieren
- WSUS-Dienst stoppen
- Content-Ordner z.B. D:\WSUS\WsusContent\ leeren (nicht löschen)
- WSUS-Dienst wieder starten

Durch das vorherige Ablehnen der ungewünschten Patches und der Download-Einstellung nur für genehmigte Updates werden beim nachfolgenden Befehl nur noch die genehmigten Updates heruntergeladen (Die Einträge in der DB bleiben erhalten):

- Wechseln Sie in das Verzeichnis "C:\Program Files\Update Services\Tools\"
- Führen Sie hier den folgenden Befehl aus: WsusUtil.exe reset
- Nach eingien Minuten wird sich der Content-Ordner wieder mit Patches füllen

Mit dem RESET-Befehl prüft der WSUS-Dienst, welche Patches er haben sollte und verifiziert, ob er diese auf der Festplatte korrekt vorfindet. Wenn nicht, wird der Patch neu heruntergeladen.

HINWEIS:
Sollten sie Drittsoftware mittels Drittanbieter-Software über den WSUS verteilen (WSUS Package Publisher o.ä.), dann müssen Sie diese Patches ebenfalls noch mal neu erstellen, da diese ebenfalls im Content-Ordner liegen und gelsöcht wurden.

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

WSUS-Server : Server meldet ständig "Verbindunsgfehler: Serverknoten zurücksetzen" (Server 2016)

Problem:
Ich habe auf einem Server 2016 einen neuen WSUS-Dienst installiert. Nachdem sich der Server mit Patches gefüllt hat, ist mir die Anwendung ständig abgestürzt mit dem Hinweis "Verbindungsfehler: Serverknoten zurücksetzen".
Erst habe ich dem Server fleissig RAM gegeben, aber der Fehler blieb bestehen!

Lösung:
Das Problem ist eine Speicherbegrenzung im IIS beim Anwendungspool

- Öffnen Sie den IIS-Manager
- Navigieren Sie zum "Anwendungspool"
- Suchen Sie den "WsusPool"
- Öffnen Sie die "Erweiterten Einstellungen"
- Scrollt nach runter in den Bereich Wiederverwendung
- Setzt Sie den Wert “Limit für den privaten Speicher” auf 0 (unbegrenzt)
- Führen Sie einen iisreset durch und das Problem soltle behoben sein

WSUS Server: Komplett zurücksetzen und löschen ohne Deinstallation

Problem:
Ich habe meinen WSUS fehlerhaft konfiguriert und er hat sich Patches gezogen, die ich so nicht wollte.
Gleichzeitig wollte ich den Dienst nicht deinstallieren und neuinstallieren, da ich den Server nicht neu starten wolte.

Lösung:

- Den Dienst WSUSService und W3SVC beenden
- Mit dem SQL Server Management Studio auf die Internal Database verbinden
- Sicherheitshalber die WSUSDB vorher sichern
- WSUSDB löschen
- WSUS-Content-Verzeichnis löschen oder umbenennen
- WSUS-Content-Verzeichnis wieder erstellen (WICHTIG, Sonst startet der Dienst nicht mehr)
- WSUSService und W3SVC wieder starten
- Ins Verzeichnis C:\Program Files\Update Services\Tools wechslen
- Hier den Befehl Wsusutil.exe postinstall ausführen

Hinweis für SQL-Verbindung zur Internal Database
Der Verbindungsstring ist bei den Betriebssystemen unteschiedlich:

Server 2012/2012 R2/2016:
\.\pipe\MICROSOFT##WID\tsql\query

Server 2003/2008/2008R2:
\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query


Terminalserver/RDS 2016: Falscher Standarddrucker bei manchen Anwendungen

Problem:
Wir haben seit längerem das Problem, dass auf Terminalserver basierend auf Server 2016 der Standarddrucker nicht korrekt gesetzt wird. Das passiert aktuell inicht bei allen Anwendungen sondrn nur bei älteren Applikationen. Nach etwas Recherche hat sich herausgestellt, dass sich beim Server 2016 bzgl. des Standarddruckers in der Registry etwas geändert hat und einige ältere Applikationen den neuen Pfad nicht abfragen bzw. mit einer alten Routine hier den Standarddrucker ermitteln.

Ursache:
Früher war der Standarddrucker hier gesetzt:
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Devices

Neu seit Server 2016 ist es dieser Pfad, der sich immer wieder ändert:
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices\S-1-5-5-0-xxxxxxxxx

Lösung:
Da wir die problematischen Anwendungen nicht selbst ändern konnten und der Hersteller das Problem nicht lösen wollte/konnte, mussten wir uns etwas einfallen lassen. Ich habe hierzu ein Skript gefunden, welches den Standarddrucker aus dem neuen Pfad ausliest und dann im alten Pfad setzt.
Folgendes habe ich dazu eingerichtet:

1.) Das Skirpt zum Auslesen und Setzen des Standarddruckers:
Option Explicit
 On Error Resume Next
 Const HKCU = &H80000001
 Dim strComputer, objReg, strOrigPath, strNewPath, arrKeys, strKey, strPrinter

strComputer = "."
 Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _ 
  strComputer & "\root\default:StdRegProv")
 strOrigPath = "Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices"
 strNewPath = "Software\Microsoft\Windows NT\CurrentVersion\Windows"

objReg.EnumKey HKCU, strOrigPath, arrKeys
 For Each strKey In arrKeys
     objReg.GetStringValue HKCU, strOrigPath & "\" & strKey, "Device", strPrinter
     If strPrinter <> vbNull Then
      objReg.SetStringValue HKCU, strNewPath, "Device", strPrinter
     End If
 Next

Set strComputer = Nothing
 Set objReg = Nothing
 Set strOrigPath = Nothing
 Set strNewPath = Nothing
 Set arrKeys = Nothing
 Set strKey = Nothing
 Set strPrinter = Nothing


Ich habe dann die Applikation über eine Batch-Datei starten lassen und darin das VBS zusätzlich laufen lassen:

REM Startskript für Applikation
start \\server\freigabe\anwendung.exe

REM Kurze Wartezeit um RDS-Session aufzubauen und Drucker zu mappen
ping 127.0.0.1 -n 10 > nul

REM Setzen des Default-Printers im Legacy Registrykey
start \\server\freigabe\set_printer.vbs


Quellen zur Lösung:
RemoteApp Default Printer Redirection Not Working in Server 2016
Default Printer not Mapped Properly within ICA Session
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz