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:
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

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