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:
Wenn wird unter Windows 8/10 freigegebene Drucker hinzufügen oder entfernen, dann dauert es teilweise mehrere Minuten, bis diese erscheinen bzw. verschwinden.

Lösung:
Nach einer langen Suche der Ursache, haben wir dann doch die Wurzel des Übers gefunden. Windows lädt Metadaten über den Drucker im Hintergrund herunter. Bis das nicht abgeschlossen ist, wird der Drucker nicht angezeigt bzw. schwindet dieser nicht aus der Übersicht. Diesen Download kann man deaktivieren und es scheint keine Nachteile zu geben.

Man findet diese Einstellung verzwickt im System. Entweder man sucht nach "Geräteinstallationseinstellungen ändern" oder man beendet den Spuk mittels einer GPO:
Computerkonfiguration > Administrative Vorlagen > System > Geräteinstallation
Abrufen von Gerätemetadaten aus dem Internet verhindern

Oder auch das Setzen des folgenden Registry-Keys führt zum Erfolg:

Pfad: HKLM\SOFTWARE\Policies\Microsoft\Windows\Device
Valuename: MetadataPreventDeviceMetadataFromNetwork
Valuetyp: DWORD
Vlaue: 0|1

Zusätzliche Informationen für GPO und Registry: admx.help: Abrufen von Gerätemetadaten aus dem Internet verhindern

Nachdem ich ja den Eintrag gemacht hatte wie man das mit Powershell fixen kann gingen komischerweise die Linux und die Mac Clients. Diese konnten Meetings aufzeichnen, jedoch gab es unter Windows 10 weiterhin Probleme das Meetings nicht aufgezeichnet werden konnten. Ich konnte das auf den Punkt "new meetings experience" zurückführen. Im aktuellen Client (11.12.2020) gibt es hier Probleme Meetings aufzunehmen. Wir haben das dann bei den betroffenen Clients deaktiviert und schon lief das recording ohne Probleme.