Hope This Helps

Problem:
Ich hatte das Problem, dass unsere .NET Anwendung für das Artikel-Update des Webshops plötzlich nicht mehr funktioniert hat - keine Verbindung zum Server mehr. Nach etwas Recherche hat sich gezeigt, dass es daran lag, dass die Webseite nur noch TLS 1.2 und 1.3 spricht aber unsere Anwendung mit TLS 1.0 die Verbindung herstellen und die Daten hochladen wollte.

Lösung:
Nach etwas Suche habe ich habe TLS 1.1 und TLS 1.2 am Windows-Client per Default aktiviert (TLS 1.3 ist noch nicht Standard). Das funktioniert über Registry-Keys am einfachsten (optional GPO bauen):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client]
„DisabledByDefault“ = dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]
„DisabledByDefault“ = dword:00000000

Sollten die Schlüssel „TLS 1.1“ und „TLS 1.2“ und „Client“ noch nicht existieren, dann bitte anlegen.

Damit aber noch nicht genug, da .NET Framework sich NICHT an den Systemstandard hält, sondern seine eigene TLS-Konfiguration macht.
Man kann das aber ändern, indem man ein paar Registry-Tweaks setzt, damit .NET das Systemdefault-TLS-Protokoll verwendet. Wichtig hier ist zuprüfen, ob die .NET Anwendung 32- oder 64-Bit ist und entsprechend die Keys setzen.

Hier für x64 bzw. Eine 64-Bit .NET-Anwendung

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Und für x86 bzw. eine 32-Bit .NET-Anwendung

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Windows-Client neu starten und damit sollte die Verbindung wieder laufen und die Verbindung zur Webapplikation wieder funktionieren.

Quellen:
Microsoft: So aktivieren Sie TLS 1.1 oder TLS 1.2 als Standard sichere Protokolle WinHTTP in Windows Update
Aktualisieren und Konfigurieren von .NET Framework zur Unterstützung von TLS 1.2.

Problem:
Ich verwende auf einigen Servern Microsoft Defender. Mein Problem ist, dass die Definition-Updates nicht automatisch installiert werden, da ich den Windows Update Dienst auf manuell gestellt habe.

Lösung:
Ich habe ein kleines Powershell-Skript geschrieben, welches die Definitions aktualisiert und die Aktualisierung auch dem WSUS mitteilt, da ich die Definition-Updates vom WSUS herunterladen möchte

Das Powershell-Skript sieht wie folgt aus:

#Definition-Update:
Update-MpSignature -UpdateSource InternalDefinitionUpdateServer
#WSUS Report:
wuauclt.exe /detectnow /reportnow

Sollte man die Updates lieber vom Microsoft-Server herunterladen wollen, dann muss man den ersten Befehl wie folgt anpassen:

Update-MpSignature -UpdateSource MicrosoftUpdateServer

Das Skript habe ich dann in eine Aufgabe gepackt und lasse diese mehrfach am Tag laufen.

Zwei Sachen noch dazu:
- Sollte man die Definitions vom Microsoft-Server herunterladen wollen, dann muss der Server auch die entsprechenden Proxy- und/oder Firewall-Freigaben haben
- Wenn man die Definitions vom WSUS zieht, dann sollte man sich eine automatische Genehmigungsregel für die Definition-Updates einrichten, sonst muss man diese immer manuell freigeben.

Problem : Mein WSUS hat sich immer wieder verabschiedet mit den verschiedensten Fehlermeldungen. Die häufigsten waren hier System.IO.IOException und System.Net.WebException.

Lösung : Nachdem ich dem wsuspool mehr Speicher gegeben habe tritt das Problem nicht mehr auf. Ich hab mich hier für 4GB entschieden.

Da ich mir das nie merken kann, mach ich hier mal einen Eintrag.

Konfiguration auf dem PDC
cmd immer als Administrator starten

w32tm /config /manualpeerlist:"NTP-SERVER,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync

Konfiguration auf einem Member der Domain
Sollte ein Server nach ein paar Std. immer noch die falsche Zeit haben ist evtl. die w32tm falsch konfiguriert. Das kann man zurücksetzten mit

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync

weitere nützliche Befehle
ntp quelle überprüfen kann man mit dem Befehl

w32tm /stripchart /computer:NTP-SERVER

den Status überprüfen kann man mit

w32tm /query /status

die configuration kann man sich mit diesem Befehl anzeigen

w32tm /query /configuration

Quellen :
https://www.anreiter.at/windows-server-2019-zeitquelle-konfigurieren/#Zeit_in_der_Domaene_verteilen
https://docs.microsoft.com/de-de/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings

Problem : Auf einem NPS wird dieser Fehler im Eventlog angezeigt.

Authentifizierungsdetails:
    Name der Verbindungsanforderungsrichtlinie:    Company Wifi - Domain Users
    Netzwerkrichtlinienname:        Company Wifi - Domain Users
    Authentifizierungsanbieter:        Windows
    Authentifizierungsserver:        FQDN-DES-SERVERS
    Authentifizierungstyp:        PEAP
    EAP-Typ:            -
    Kontositzungs-ID:        46xxxxxxxxxxxx30
    Protokollierungsergebnisse:            Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
    Ursachencode:            16
    Ursache:                Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. 
Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.

Lösung : Entweder der NPS oder die Meraki Endgeräte kommen nicht mit dem Wildcard Zertifikat klar. Ich hab die Einstellungen im NPS auf ein AD CA generiertes, direkt auf den FQDN des Servers, ausgestelltes Zertifikat geändert und schon lief alles.

Problem : Bei einem frisch aufgesetzten Windows 2019 Server können als Domain Administrator diverse Einstellungen nicht vorgenommen werden. Ich konnte das bei den Desktop Icons und bei den Einstellungen für das Netzwerk beobachten
( Windows Icon -> Zahnrad -> Netzwerk und Internet -> Ethernet -> Adapteroptionen ändern )

Grund hierfür ist scheinbar die Default Einstellung der UAC

Lösung : Setzen einer GPO auf die Benutzerkontensteuerung

Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen/Benutzerkontensteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto diesen Wert auf "Aktiviert" setzen