Hope This Helps

Hier meine Anleitung zur Installation eines Exchange CU auf einen einzelnen Exchange Server(kein DAG) - ist wahrscheinlich nicht vollständig, aber für mich steht hier das Wichtigste drin.

Vorher eventuelles Schema-Update prüfen und ggf. durchführen. Für ein sicheres Schema-Update habe ich auch bereits eine Anleitung geschrieben:
HTH: ActiveDirectory: Sicheres Schema-Update (ADPREP) mittels Replikations-Pause

Danach geht es mit den Vorbereitungen und Installation weiter:

- Benutzerspezifische Konfigurationsdateien sichern (z.B. Microsoft.Exchange.Store.Worker.exe.config)
- Backup-Zeiten prüfen und ggf. anhalten
- NAT für SMTP deaktivieren - Keine Mails kommen mehr herein, keine Client-Verbindungen mehr von extern
- HTTPS in NAT auf Firewall deaktivieren - Keine externen Client-Verbindungen mehr (nur wenn kein Reverse Proxy vorhanden)
- Reverse Proxy deaktivieren, falls vorhanden - kein OWA, ActiveSync und Outlook Anywhere
- Server herunterfahren und Snapshot erstellen (Sicherheit)
- Server neu starten - schließt auch alle eventuellen Installationsroutinen ab (Updates etc.)
- Virenscanner deaktivieren bei Installation (z.B. Defender: Set-MpPreference -DisableRealtimeMonitoring $true)
- Powershell Restriction deaktivieren: Set-ExecutionPolicy Unrestricted
- Server neu starten - zur Sicherheit
- AV-Status prüfen erneut prüfen: Get-Mppreference
- ISO mounten
- CMD als Administrator öffnen (Wichtig, wegen UAC)
- Setup aus CMD starten und erfolgreich durchlaufen lassen – kann dauern... (ca. 1 Stunde)
- Zuvor gesicherte, benutzerspezifische Konfigurationsdateien prüfen und ggf. wiederherstellen (Filedate prüfen)
- Serverneustart durchführen um Installation abzuschließen und wiederhergestellte Konfiguration zu aktivieren
- ReverseProxy bzw. HTTPS im NAT auf der Firewall wieder aktivieren
- NAT für SMTP wieder aktivieren - Testmail schicken!!
- Nach Update Funktionen prüfen: OWA, ActiveSync, Outlook Anywhere
- Backup ggf. wieder aktivieren
- Virenscanner aktivieren (z.B. Set-MpPreference -DisableRealtimeMonitoring $false)
- Snapshot löschen

Problem:
Auch wenn der Server 2003R2 schon extrem angestaubt ist, hat man manchmal doch noch damit zu tun. Ich hatte einen 2003R2 Domain Controller, den ich gegen ein aktuelles System getauscht habe aber vorerst als Memberserver weitergetrieben musste. Auf dem 2003R2 Server liefen einige geplante Aufgaben. Nachdem ich den Server die Domain Controller Rolle entfernt hatte, liefen alle Aufgaben auf den Fehler "0x8007000d: Die Daten sind ungültig". Beim manuellen Starten der Aufgabe habe ich folgenden Fehler erhalten:

Fehler beim Initialisieren der Seite "Allgemein".
Der genaue Fehler ist: 0x8007000d: die Daten sind ungültig.
Abrufen der Taskkontoinformationen ist ein Fehler aufgetreten. Sie können weiterhin das Task-Objekt bearbeiten, aber nicht ändern.

Lösung:
Das Problem scheint wirklich durch das Herunterstufen des DCs zukommen. Es gibt einige Lösungsansätze im Internet, aber folgender Workaround hat bei mir geholfen:

- Öffnen Sie den Pfad "C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Microsoft\Crypto\RSA"
- Dort finden Sie einen Ordner "S-1-5-18"
- Ich habe mal eine Sicherheitskopie des Ordners angelegt
- Dann löschen Sie die Dateien in diesem Ordner, aber nicht den Ordner selbst
- Starten Sie den Taskplaner-Dienst neu
- Danach öffnen Sie die Eigenschaften der Aufgaben und geben die Anmeldedaten im Task erneut ein
- Danach laufen die Aufgaben wieder ohne Probleme

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

Problem:
Ich habe eine Published App für die Benutzer zur Verfügung gestellt und veröffentlich diese entweder über die RDWeb-Webseite des Terminalservers oder ich hänge die Apps direkt bei den Windows-Clients unter "Remote-App zugreifen" ein. Dabei wird beim Starten immer folgende Fehlermeldung angezeigt:


Lösung:
Zur Lösung müssen zwei Sachen umgesetzt werden:
1. Man muss das Zertifikate des RDS-Servers als "Vertrauenswürdige Stammzertifizierungsstelle" und als "Vertrauenswürdige Herausgeber" veröffentlichen (z.B. mittels GPO)
2.) Man muss den Thumbprint des veröffentliche Zertifikates als vertrauenswürdig einstufen (z.B. mittels GPO)

Also bauen Sie sich eine Zertifikats-GPO, soweit noch nicht vorhanden. Hierin importieren Sie das RDS-Zertifikat unter "Computerkonfiguration" -> "Windows-Einstellungen" -> "Sicherheitseinstellungen" -> "Richtlinien für öffentliche Schlüssel" unter den Punkten "Vertrauenswürdige Stammzertifizierungsstellen" und unter "Vertrauenswürdige Herausgeber".
Jetzt öffnen Sie das Zertifikat und kopieren sich den Thumprint unter den Eigenschaften heraus.
Diesen Thumprint fügen Sie dann in folgender GPO ein, um das Zertifikat vertrauenswürdig zu machen:
"Computerkonfiguration" -> "Administrative Vorlagen" -> "Windows-Komponenten" -> "Remotedesktopdienste" -> "Remotedesktopverbindungs-Client" ->"SHA1-Fingerabdruck von Zertifikaten angeben, die vertrauenswürdige RDP-Hersteller darstellen".

HINWEIS:
Der Thumbprint muss OHNE Leerzeichen eingegeben werden und mein 2016er-Server wollte unbedingt die Buchstaben als Großbuchstaben.

Problem:
Ich habe eine Published App auf einem Server 2016 mit RDS. Für das Starten der App ohne Fehlermeldung benötige ich ein Zertifikat. Wenn ich das über die GUI erstelle, dann ist dieses immer nur 1 Jahr gültig. Das ist zwar sicherheitstechnisch korrekt, aber für eine Applikation für 10 Mitarbeiter jedes mal ein größerer Aufwand.

Lösung:
Ich erstelle auf dem RDS Server der Published App einfach ein Self Signed Certificate mittels Powershell mit entsprechenden Namen und angepasster Gültigkeitsdauer.

Hier der Befehl:

New-SelfSignedCertificate -Subject “server.domain.local” -DNSName “server.domain.local”, “rds.domain.local”, "Netbiosname Server" -CertStoreLocation “cert:\LocalMachine\My” -KeyAlgorithm RSA -KeyLength 2048 -KeyExportPolicy Exportable -NotAfter (Get-Date).AddYears(5)

Erklärungen:
DNSName: Hier geneben Sie alle FQDNs kommegetrennt an, über die der Server erriechbar sein soll. Nettes Feature...ich kann hier auch IP-Adressen und NetBIOS-Namen angeben, da ich nicht den Restriktionen einer öffentlichen Zertifikatsstelle unterliege.

-KeyExportPolicy: Das Zertifikat bzw. der private Schlüssel sollte exportierbar sein, falls man diesen sichern möchte.

-NotAfter: Hier kann man ein Gültigkeitsdatum des Zertifikats angeben. Ich selbst nehme immer den heutigen Tag (Get-Date) und Addiere x Jahre dazu (hier z.B. 5 Jahre).

Das Zertifikat verteile ich dann per GPO an alle Clients und setze noch den SHA1-Thumbprint als vertrauenswürdig um die unschöne Fehlermeldung zu unterdrücken.
Das habe ich hier erklärt: RDS Terminalserver: Published App meldet beim Starten "Unbekannten Hersteller"