Forseti2003

vor 4 Minuten schrieb Nobbyaushb:

Den RDS einfach mal neu starten - hilft meist…

(wir hatten unsere stark ausgelasteten RDS alle 48 Stunden per Task nachts neu gebootet..)

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.

vor 4 Minuten schrieb Nobbyaushb:

Was spricht denn die Lizensierung auf dem 2019 er RDS, wenn du dich als Administrator anmeldest?

und nebenbei verbindet man sich immer mit dem Namen des Servers…

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

vor 7 Minuten schrieb testperson:

Hi,

 

die Terminaldienste Lizenzierung läuft auf dem Domain Controller und dieser läuft unter Windows Server 2019?

 

Dann dürfte der Terminalserver unter Windows Server 2022 gar keine Terminaldienstelizenzen ausgestellt bekommen, da du dafür den Lizenzserver mindestens unter Windows Server 2022 betreiben musst. Ob das aber jetzt mit deinem Problem zusammenhängt, kann ich dir nicht sagen. :)

 

Ist die Installation vom Windows Server 2022 Terminalserver ca. 120 Tage her?

 

Gruß

Jan

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.

vor 30 Minuten schrieb stefannsv:

OK danke für den Hinweis. Bei der Anwendung handelt es sich allerdings nicht um ein Access Frontend.

Die Daten des Frontends stehen in einer SQL Server Datenbank. Von daher ist eine Group-By bzw. Group-By Klausel in einer Abfrage gegen die SQL Engine eigentlich völlig ok.

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. 

vor 2 Minuten schrieb q617:

Warum keine moderne Cloud-Lösung?

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.

vor 23 Minuten schrieb htb:

Das Argument dass es weniger Arbeit ist interessiert die GF nicht
da es ja nicht ihre Arbeit ist, sondern meine für die ich schließlich bezahlt werde.
Und weswegen plötzlich nicht mehr funktionieren soll, was bisher immer so funktioniert hat

meine Frage nach einer weiteren Server Lizenz wurde mit Kopfschütteln beantwortet
und mir gesagt, ich sei der IT Experte ich müsse wenn eine Lösung finden wie man es mit vorhandenen Mitteln umsetzen kann

die einzige Möglichkeit wäre das ADDS als weitere Rolle auf ein vorhandenes System zu installieren
was mir jedoch aufgrund meines Backgrounds komplett wiederstrebt
Obendrein befinden sich die einzigen die dafür in Frage kämen in der DMZ
was es alles nicht besser macht

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.

Am 8.6.2021 um 11:24 schrieb Vinc211:

Da das Problem immernoch besteht habe ich diesen Thread nochmal ausgegraben.

 

Es ist so das dies nur beim klicken aufs Laufwerk etc. passiert. Das Eingeben des FQDN funktioniert immer.

 

Manchmal funktioniert es nach einem Neustart wieder. Vor und nach dem Neustart sind ping auf dom.loc und alle ipconfig/all einstellungen gleich.

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?

Am 13.6.2021 um 11:03 schrieb TAM:

Klar. Ne Domäne kostet erst mal mehr Geld.

 

Vereinfacht aber die Administration um Welten...

 

Du musst nicht mehr direkt jedes Gerät einrichten für die Benutzer und jeder Benutzer kann sich da anmelden wo er grad will. Spart sehr viel Zeit und kosten.

 

 

 

 

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?

vor 4 Minuten schrieb NorbertFe:

Afair funktioniert das nicht. 

naja, Kernfrage ist jetzt wie stark er überhaupt OWA nutzt - wenn es nur wegen den Notizen ist, dann würde ich prüfen ob die PS das hinbekommt, wenn ja, still ruht die See, wenn nein, tja, notfalls einen Server neu aufsetzen und die Datenbanken neu einhängen.

Am 5.6.2021 um 20:40 schrieb massaraksch:

Hi,

 

siehe: Attributes synchronized by Azure AD Connect | Microsoft Docs

 

msExchExtensionCustomAttribute1..5 -> This attribute is currently not consumed by Exchange Online

 

Scheint also nicht supportet in EXO.

Ja das scheint wohl so ....... komisch das man über die PowerShell auf den EXO die Felder angezeigt bekommt, aber nicht befüllt werden. Aber gut, dann mal warten bis MS das korrigieren wird.

eventuell auch den lokalen DNS prüfen ob die Zone gesetzt und der Verweis auf den Mailserver vorhanden ist.

Hast Du mal geschaut ob der Server auch andere Windows-Updates durchgeführt hat? Oder mal schauen ob das Framework zu der Exchange CU-Version passt? Eventuell hast Du mit dem neueren CU einen Stand erreicht, wo auch das Framework geupdatet werden muss. Eine andere Idee wäre es, das CU nochmal sauber runterzuladen und erneut drüber laufen zu lassen.

Wenn es Dir nur um die Abwesenheitsnotiz geht und die ECP sauber läuft, dann setz doch die Abwesenheit über die PowerShell?

vor 44 Minuten schrieb MrCocktail:

Dafür muss der AAD Sync Server > einer bestimmten Version sein, frag mich jetzt aber nicht nach welcher.

 

und was deine Abbau Pläne angeht, bitte berücksichtige, solange du ein lokales AD hast und die Identitäten gesynct werden, brauchst du aus Support gründen auch einen lokalen Exchange.

Okay, den AAD Sync Server hab ich geprüft, war noch version 1.5.45, ist jetzt geupdatet auf 1.6.4. Hab beim User eine Änderung gemacht und dann nochmal den Export angeworfen, gleiches Ergebnis Daten kommen nicht an. Wenn ich mir aber das Log anschaue, hat lokal das System richtig reagiert:

Die Änderung wurde erkannt und angeblich ohne Fehler übertragen. Aber in der PS vom EXO kommt nichts an. Frustrierend.

vor 1 Minute schrieb Dukel:

Dann sollten die Attribute synchonisiert werden (ohne Rules anzupassen!).

Evtl. greifst du falsch darauf zu, da diese, meines Wissen, OnPrem und in MS365 anders heissen.

 das wiederum glaub ich sofort - aber wenn ich die Mailbox eines Users mit FL auslesen lasse, taucht da kein weiteres Attribut mit den entsprechenden Werten auf. Hier mal ein Auszug:

Mir würde es ja schon reichen, wenn ich die von lokal auf Online auf die ExtensionCustomAttribute1 umgebogen bekomme, dann muss ich zwar die dynamischen Verteilergruppen über die PS anlegen, aber das wäre das kleinste Problem.

Ja, die Hybridstellung ist ausgewählt:

vor 44 Minuten schrieb mikro:

Hast du im Syn tool unter Filterung auch die MS Exchange System Objects im Sync? 

 

Gruss Mirko 

Ist diese Option nicht nur für die Monitor-Mailbox gedacht?

Ich behaupte mal jetzt: Ja. Die Migration wurde problemlos durchgeführt, der lokale Exchange ist bereits geräumt und wird in den nächsten Tagen auch zurückgebaut, eventuell sogar komplett aufgelöst. Ich gehe daher aktuell nicht von einem Konfigurationsproblem der Hybridstellung aus - wenn glaube ich eher das der AzureADsync das Problem ist. Auch läuft der Mailverkehr absolut sauber.

Grüße in die Runde,

MS treibt mir mal wieder die Schweißperlen ins Gesicht. Folgendes Szenario:

Ich möchte bei einem User im lokalen AD Daten pflegen und nutze dazu u. a. die msExchExtensionCustomAttribute da diese die Werte als Array führen,  damit ich einen dynamischen Verteiler aufbauen kann.

Nun möchte ich einfach in Exchange Online (Hybridstellung mit EX13 und über ADsync gekoppelt) auf diesen Wert zugreifen. Dieser wird aber nicht Synchronisiert und direkt editieren geht nicht, weil ADsync aktiv ist.

Wenn ich in die PS beim EXO reinschaue, sehe ich das es ein Attribut ExtenstionCustomAttribute gibt - aber über den RuleEditor hab ich keinen Erfolg das ich den Wert aus der msExchExtensionCustomAttribute dahin biege, da ich den Wert als Target-Attribut nicht auswählen kann.

Jetzt die Frage, gibt es da einen anderen Trick oder nennt sich das Feld im RuleEditor noch anders? 

Grüße Forseti

vor 3 Minuten schrieb NorbertFe:

Du stellst aber hohe Anforderungen ;)

okay, das nur hätte ich in Anführungszeichen setzen sollen