Forseti2003

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.

Greift der VPN-User auf eine IP-Adresse zu oder auf den fqdn? Wenn fqdn prüf auch mal die HOST-Datei lokal im Windows-Verzeichnis oder die Routen, wie die eingetragen sind. Eventuell kommt der PC durcheinander. Kann es auch sein das die PC's die es betrifft WLAN und LAN haben oder sind diese nur auf einen Netzwerkweg ausgelegt?

War/Ist das Dein erster Versuch oder hast Du schon davor probiert gehabt? Kann sein das alte Fragmente noch rumliegen? Gibt es Einträge im Fehlerlog? Kann auf den Fileserver zugegriffen werden? Welche OS-Version liegt der Konfiguration zu Grunde?

Da wir nicht die Struktur bei @htb kennen, können wir über Kosten und Geld aktuell wenig sagen. Das eine Geschäftsleitung knauserig ist, ist ja erstmal nichts wirklich neues, heißt aber nicht, das man ohne gute Argumente nicht doch Projekte auch in der IT vorantreiben kann. Mit mehr Informationen könnte man dazu auch was sagen, eventuell kostet das AD gar nicht soviel Geld?