Forseti2003

Ja, das werde ich mal so ins Auge auch fassen, dann kann ich auch gleich das darunterliegende Windows Server 2019 austauschen.

gab es ja nicht wirklich, da der Server nach dem Update nicht mehr gearbeitet hat, war es nichts anderes, als wenn er drei Tage ausgeschaltet worden wäre. Der Server selbst hat ja bei uns keine richtige Funktion mehr, dient ja nur noch als Management für M365.

Aktuelles Update: Wir haben übers Wochenende nun ein Backup eingespielt und den Exchange Server auf seinen unmittelbaren Status vor Update zurückgesetzt. Danach liefen alle Dienste wieder. Bevor wir erneut in das Updat auf SE gehen, werden wir das nochmal alles prüfen und checken, damit wir nicht mehr in diesen Fehler reinlaufen werden. Aber ich bedanke mich bei allen die mit Tipps und Ratschlägen zur Seite standen.

Bisher noch keine.

Das mit dem RAM ist kein Problem, hab es jetzt mal auf 24 GB RAM hochgesetzt. Als OS dient noch ein Windows Server 2019. Da gebe ich Dir Recht, aktuell bin ich da gerade ziemlich ratlos, so hartnäckig hatte ich noch kein Problem am Exchange. Das mit dem RecoverMode hab ich über den setup.exe /Mode: Schalter ausgeführt. das geht auch bei bestehenden Installationen, dann prüft er auch ob alle Komponenten da sind. Ich werde wohl da einen Spezialisten benötigen, der sich das mal wirklich in der Tiefe anschauen kann. Update: Aber mal ein kurzes Feedback, seit der Erhöhung des RAMs auf 24 GByte sind einige Fehlermeldungen weniger im Log. Derzeit hab ich noch die 12014 MSExchangeFrontEndTransport - da liegt noch ein Zertifikatsfehler vor 1033 MSExchange ActiveSync - hier fehlt eine Web.config Ansonsten sind nur normale Meldungen/Informationen jetzt aktiv.

Ja, meinte Exchange Server. Also nicht den Server selbst plätten, sondern erstmal die Anwendung und dann wieder installieren. Wenn das keine gute Idee ist, dann lieber lassen. Den Mode:RecoverServer hab ich schon probiert, der schlägt aber fehl, da er stellenweise die exchangeserver.msi aus dem Installationspfad und nicht von der ISO ziehen will. Hätte nicht geglaubt, dass das Update so eine Welle schlagen kann.

Ja, nach dem Update auf SE hab ich das Dezember CU gleich mit aufgespielt. Würde es eventuell sinnvoll sein die ganze Anwendung zu deinstallieren und danach neu aufzusetzen? Die Konfig selbst zieht er ja später wieder aus dem AD zurück. Oder eventuell einen zweiten Aufsetzen und wenn der stabil läuft den alten ausmustern? Eigentlich ist er nur für ein Hybrides Szenario da um die Postfachrichtlinien auszuteilen und die Remote-Mailbox Daten ans AD zu melden.

4 vCPU, 17 GB RAM, davon derzeit nur 13 GB genutzt.

Nein eigentlich nicht, liegt derzeit bei 17% - werde das aber mal etwas erweitern.

Die machen mich derzeit ziemlich stutzig: ID 5011 WAS : Schwerwiegender Kommunikationsfehler - Anwendungspool MSExchangeServicesAppPool - Prozess ID 10788 ID 1033 MSExchangeActiveSync : The setting SupportedIPMTypes in the Web.Config files was missing ID 12014 MSExchangeFrontEndTransport : Microsoft Exchange Could not find a certificte that contains the domain name mail.internal.domain.de ID 1105 FIPS : Nicht genügend Speicherressourcen verfügbar ID 1007 MSExchangeMailboxReplication ID 4027 MSExchange ADAccess ID 12009 MSExchangeTransport ID 10004 MSExchange Mid-Tier Storage Ich glaube aktuell werden die Fehler eher schlimmer, als besser. Neben dem 503-Fehler auf OWA & ECP startet auch die ExchangeShell nicht mehr. Ich werde mich jetzt erstmal näher mit dem Fehler 12014 beschäftigen, da eigentlich das neue Zertifikat hier laufen sollte, er aber weiterhin auf das entfernte schaut.

Hast Recht, war im falschen Verzeichnis. Die zwei Scripte bringen aber leider auch keine Besserung.

Ja, die IIS-Bindungen sehen gut aus, das neue Zertifikat ist dort hinterlegt, sowohl in der DefaultSite als auch im Backend. Im Exchange-Ordner unter Scripts finde ich diese Scripte nicht. Gibt es das unter SE noch? Ja gebootet hab ich nach jedem Versuch schon. Die Shell reagiert ganz normal. Das Zertifikat ist vorhanden und ist noch bis April gültig, bevor es erneuert werden muss.

Guten Morgen in die Runde, hab mich hier scheinbar ein wenig festgefahren, folgendes Problem: Nach Update von Exchange Server 2019 CU15 auf EX SE kann ich ECP und OWA nicht mehr starten, erhalte Fehlermeldung 503. Vor dem Update war das kein Problem. Während dem Update gab es ein Problem mit einem abgelaufenen Zertifikat auf dem Sendeconnector, dieses hab ich entfernt, danach lief das Update durch. Nach dem Update habe ich ein gültiges Zertifikat wieder hinzugefügt. Wenn ich danach ECP/OWA aufgerufen hatte, fragte er noch nach dem Anmeldedaten und lief dann in den Fehler 503. Während der weiteren Suche, hat sich das aber dann verschlechtert, so das nicht mal mehr die Anmeldedaten abgefragt werden. Was ich bisher alles geprüft habe: IIS - Bindungen AppPools Im Anschluss hab ich von EX SE den Mode:Upgrade nochmal ausgeführt um eine eventuelle fehlerhafte Installation zu bereinigen. Das lief ohne Fehler durch. Aber ohne Ergebnis. Im Ereignislog taucht auch der Fehler ASP.NET 4.0.30319.0 ID 1310 auf, der auf einen Konfigurationsfehler hinweist, im Zusammenhang mit ClientAccess/OWA Hat jemand eine Idee, was da passiert sein kann? Grüße Forseti.

Neustart auch bereits durchgeführt, hab ihn auch mal aus der Sammlung entfernt und neu hinzugefügt und auch in eine andere Sammlung gepackt. Ich hab derzeit den Eindruck das es tatsächlich am Windows Server 2022 liegt, das er ein Problem hat die Verbindung aufzubauen. hm, ob es das Problem jetzt wirklich gelöst hat, bleibt abzuwarten, aber scheinbar hatte ich einen Domaincontroller im Setup der Fehler verursacht hatte. Hab diesen nun herausgeworfen und nun kann ich auf die App zugreifen. Ich bleib mal skeptisch und beobachte weiter.

Die Lizenzierungsdiagnose sagt das alles in Ordnung ist, Lizenzserver wird 1 gefunden und ist verfügbar. Keine Warnung, keine Fehlermeldung.

Servus Jan, der Terminalserver 1 ist ja nicht das Problem (Windows Server 2022) - hier laufen die User ganz normal. Aber sobald ich auf den Windows Server 2019 zugreifen will, kommt der Fehler, aber auch erst seit heute. Der Terminalserver 1 ist derzeit tatsächlich neu und läuft seit knapp 30 Tagen. Die 120 Tage-Frist ist also da nicht das Problem.

Grüße in die Runde, hab hier einen merkwürdigen Fall, der nur Auftritt wenn ich über eine RemoteApp-Verbindung eine Anwendung starte. Dieser Vorgang ist bei uns eigentlich nichts neues und wird seit Jahren praktiziert. Seit heute morgen gibt es dabei aber einen Fehler. Mit dieser Meldung: Getrennte RemoteApp: Die Verbindung mit der Remotesitzung wurde getrennt, da bei der Erstellung des Lizenzspeichers ein Fehler vom Typ "Zugriff verweigert" aufgetreten ist. Führen Sie Remotedesktopclient mit erhöhten Rechten aus. Folgendes Szenario: Domaincontroller mit Rolle Lizenzserver (Windows Server 2019) - Status Lizenzserver ok. Terminalserver1 (Windows Server 2022) - hier melden sich die User ganz normal an, keine Fehler. Terminalserver2 für RemoteApp (Windows Server 2019) - hier hakt es plötzlich seit heute. Ich hab den Server der RemoteApp schon neugestartet, fslogix-Update aufgespielt, Ping-Versuche an Domain, DNS etc, alles erfolgreich. Kann mit einer normalen MSTSC lokal vom PC aus verbinden, kein Problem, sobald ich es aber über den Terminalserver 1 probiere kommt der Fehler - selbst wenn ich MSTSC aufrufe und die IP eintrage, also genauso wie lokal beim PC.

Group-By per se ist kein Problem, außer das in der Abfrage eventuell noch auf einen alten Befehlssatz zugegriffen wird. Du migrierst ja von einer alten auf eine neue Version.

Die Group-BY-Fehlermeldung klingt fast, als wenn das Frontend ACCESS wäre. Die Fehlermeldung kenne ich, wenn Anwender eine Spaltensortierung Gruppieren und im Formular abspeichern - auch wenn diese dann unsinnig ist. Beim starten des Frontend kommt dann auch so eine Fehlermeldung.

Ich hab das Problem gefunden und auch die Lösung. Lag eigentlich nur an zwei Punkten die mir gefehlt hatten: 1) beim SQL-Server in Remoteverwaltungsbenutzer die Brokers mit eintragen 2) den SQL String mit geschweiften Klammern und dem ODBC Driver 18 for SQL Server nutzen und den Parameter TrustedCertificate=yes mit einbauen. Der Fehler mit 15353 und der Sicherheitsgruppe ist nur entstanden, weil ich die neue Datenbank gleich mit der Gruppe anlegen wollte. Wird die Datenbank angelegt und nachträglich auf den dbowner der Gruppe gesetzt ist alles gut.

Gegenfrage, was würde die moderne Cloud-Lösung besser machen oder können, von welcher Lösung sprichst Du explizit?

Guten Morgen in die Runde, wie im Betreff genannt, geht es um den SQL Connection String um einen Verbindungsbroker auf einen SQL Server zugreifen zu lassen. Trotz vieler Versuche, scheitere ich dabei aber immer, wenn ich den Broker ins HA führen will an dieser Fehlermeldung: Die in der Datenbank-Verbindungszeichenfolge angegebene Datenbank ist nicht auf dem Remotedesktop-Verbindungsbroker verfügbar. Hier Testumgebung: 1x SQL Server 2022 auf Windows Server 2022 Standard (aktuell Firewall komplett aus) 1x Windows Server 2022 Standard - mit Rollen zur Remotedesktopbereitstellung Auf diesem sind folgende ODBC-Treiber installiert: ODBC Driver 13 for SQL Server, ODBC Driver 17 for SQL Server Der Broker befindet sich in einer Sicherheitsgruppe "BROKER" und diese ist auf dem Datenbankserver als DBCREATOR, PUBLIC und SYSADMIN hinterlegt. Die Verbindungszeichenfolge lautet so: DRIVER{ODBC Driver 17 for SQL Server};SERVER=tcp:10.100.50.38\REMOTEFARM,1433;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;Database=RDSFarm Auf beiden Servern ist das SMSS installiert und zeigt die Datenbank sauber an. Zugriff ist also auch vom Broker auf den SQL-Server eigentlich möglich. Bisherige Versuche: Anstelle von ODBC Driver 17 auch 13 genutzt, mit und ohne geschweifte Klammern. Bei Server auch ohne TCP und Port-Angabe probiert und auch mit FQDN. Wahlweise die Strings bei der Konfiguration auf Dedizidiert und auch Freigegeben Datenbank gestellt. Habt Ihr eine Idee, was hier die Ursache sein kann, gibt es etwas spezielles, was bei SQL Server 2022 zu beachten ist - außer das es die Nativen Client-Treiber nicht mehr gibt? Grüße Forseti Update: Hab mal den SQL Server auf 2019 aufgesetzt und zusätzlich auch mit dem SQL Native Client probiert. Komme aber immer wieder auf die selbe Fehlermeldung. Was mir noch aufgefallen ist, ich kann die Sicherheitsgruppe der Brokers "BROKER" nicht der Datenbank als db_owner zuweisen, erhalte hier die Fehlermeldung 15353 Level 16. Im Nachgang kann ich aber diese Gruppe für die Datenbank mit anhängen. Ob die Datenbank bereits erstellt ist oder nicht - macht aber an der Fehlermeldung von oben keinen Unterschied.

Anderer Ansatz wäre das VPN-Gateway, hat das vielleicht eine Policy/NAT-Routing aktiv die da ein Problem verursacht?

Hast Du mal Deine DNS-Server geprüft, ob die sich gegenseitig sauber erkennen und die Zoneneinträge übernehmen? Auch mal die Zone prüfen, nicht das versehentlich einige Einträge ins Nirwana führen.

Das mit der Arbeit hab ich ja auch gar nicht gesagt - das ist wirst Du überall antreffen. Du bist Mitarbeiter, bekommst einen Gehalt insofern musst Du dafür arbeiten. Wieviel ist dabei Nebensache. Aber wie schon davor erwähnt, wir kennen Deine Struktur nicht, weder hardware- noch softwareseitig. Insofern ob man hier oder da Stellschrauben hat um das ganze Kostenneutral zu verbessern, können wir also auch nicht sagen. Du wirst nicht drumherum kommen mehr zu erwähnen, einen externen Dienstleister finden der Dir hilft (was aber Deine GF nicht genehmigen wird, vermute ich mal) oder selbst Lösungen finden.