Marco-M

Warum virtualisiert Ihr den RDSH-Server? Hardware, OS, Applikationen/Programme, in dieser Konstellation sind bei uns zeitgleich unter Windows Server 2025 Standard um die 110 Benutzeranmeldungen bei voller Performance ohne irgendwelche Einbussen möglich. Nebst Office Programmen wird mit Branchenprogrammen (Kalkulation, Buchhaltung, ERP usw.) gearbeitet. Dies unter Voll-Desktop oder auch einzelne Programme als RemoteApp. Optimierungen wurden im Bereich des IP-Protokolls, NTFS, SMB, System Dienste, Aufgabenplanung, Server- und Arbeitsstationsdienst usw. vorgenommen. Unnötige Windows Apps wurden deinstalliert, Server läuft ohne Auslagerungsdatei.

Danke Dir mikro, DelegateSentItemsStyle funktioniert wenn Outlook im Cache Modus läuft, wir verwenden Outlook im online Modus (eigene Exchange Server im Hause, sorry hatte ich vergessen zu erwähnen). Gruss Marco

Hallo zusammen Hat jemand Erfahrung mit MessageCopyForSentAsEnabled? Wir verwenden diese Einstellung, funktioniert tadellos mit Shared Mailboxen wenn das "im Auftrag von" E-Mail ohne "Nachricht digital signieren" gesendet wird. Ohne digitale Signatur wird wie gewünscht eine Kopie der gesendeten Nachricht in "Gesendete Elemente" abgelegt. Wenn die Nachricht digital signiert ist, wird keine Kopie erstellt. Kennt jemand von Euch dieses Problem, respektive eine Lösung hierzu? Beste Grüsse, Marco

Cloud Lösung: MFA for Remote Desktop - Rublon On-Premise: ManageEngine ADSelfService Plus - An identity security solution with adaptive MFA, enterprise SSO, and self-service password reset. Wir kennen beide Lösungen schon länger, Rublon etwas einfacher zu managen, nutzten selber aber ADSelfService Plus.

Vergleiche mal Datum und Uhrzeit auf Seiten der Windows Clients und Server.

Danke Dir Norbert für Deine geschätzte Rückmeldung. Ich darf kurz voraussenden, Exchange ist mit an und für sich nicht unbekannt, meine erste Installation war die Version 5.5 Gerne darf ich Dir bestätigen, dass der Exchange Server 2019 CU14 15.02.1544.009 auf Windows Server 2019 sonst tadellos läuft, auch ein Befall kann ausgeschlossen werden. Ich finde im IIS und EWS Log auch keine Einträge für SoapAction, Subscribe usw. da der FQDN ja nicht aufgelöst werden kann. Stehe im Moment an, welches Postfach diesen Fehler verursacht. Kenne den vollständigen Endpoint, wenn ich den FQDN korrekt (https://app.smartmailcloud.com/api/.....) eingebe funktioniert dieser auch.

Hallo zusammen, vielleicht kennt von Euch jemand einen Lösungsansatz wie man herausfinden kann, welches Exchange E-Mail-Postfach den Ereignisanzeige Fehler: MSExchange Web Services 5, 6 dann 7 generiert. Die Fehlerursache ist bekannt: A notification for subscription [Esdfsgdgsdfge564564564564dfsdEqPqUuB3q5ZbmAx3gGvWN34sdfsdgsdfsae43sfsdW0=] against endpoint [https://app.smartmailcloud.comapi/v2/calendar-push/receive-ews?app_token=3dftZhd424345345345euSNrtWebException: Der Remotename konnte nicht aufgelöst werden: 'app.smartmailcloud.comapi' Status: NameResolutionFailure Der FQDN wurde nicht korrekt eingegeben, jedoch der unbekannte Anwender merkt den Fehler nicht. Wie finde ich nun heraus wem dieses Postfach gehört? Für Eure geschätzten Bemühungen bedanke ich mich im Voraus recht herzlich, Marco