ChrisRa

Die Problematik tritt bei uns immer noch auf. Hat noch jemand eine Idee? Oder zumindest eine Idee an wen wir uns wenden können?

Kennt jemand einen DL, der sich mit der Materie RDS sehr gut auskennt?

Gerne auch via PN.

Noch eine Ergänzung:

Die Screenshots kommen vom Client, nicht vom Sessionbroker. Auf dem ist nach wie vor nichts zu finden.

Hatte ich vergessen zu erwähnen

Ich habe noch mal ein wenig im Eventlog gewühlt und folgende Events gefunden:

gefolgt von:

Für Google und die Nachwelt:

EventID 1042 und Fehler: 0x800700B7

Fehler beim Starten der Remoteanwendung ("RemoteApp") in RemoteApp- und Desktopverbindung ("Sessionbroker"). (Fehler: 0x800700B7)

EventID 1041 

Die Remoteanwendung ("RemoteApp") wird in RemoteApp- und Desktopverbindung ("Sessionbroker") gestartet, es werden jedoch keine gespeicherten Anmeldeinformationen für einmaliges Anmelden verwendet. (Grund: Es wurden keine Anmeldeinformationen in RemoteApp- und Desktopverbindung gespeichert.)

Ich konnte es nun nachstellen. Der Sessionbroker loggt nichts. Es scheint also auch gar nichts anzukommen.

Ja, ist alles korrekt. Aber das initiale Problem ist ja, dass manchmal keine zwei Remote-Apps gleichzeitig geöffnet werden können. 

Ich glaube du hast da was falsch verstanden. Ich kann dir gerade nicht folgen. 

Es sind nur die Remote-Apps freigegeben. Es wird auch nur damit gearbeitet.

Ja, korrekt. Das funktioniert so nicht. Aber das ist ja auch ein anderes Thema.

Hat jemand zu meinem genannten Problem noch eine Idee?

Nein, wenn die Server sich innerhalb der Farm befinden ja sowieso nicht.

Das ist in der Sozialbrache definitiv zu viel verlangt. 

Der Eintrag ist gar nicht vorhanden. Sollte also vermutlich der default genutzt werden.

Wir  haben es vor vielen Jahren schon alles als Remote-App veröffentlicht. Das hat sich im ganzen Unternehmen nun so etabliert. Ist für die User irgendwie einfacher, das Prozedere würde ich deshalb also nur ungern an den Nagel hängen. 

Edit: Gibts eigentlich irgendwie eine Möglichkeit bei MS ein Supportticket zu öffnen, wenn man keinen laufenden Servicevertrag hat?

Niemand eine erste Idee?

Guten Morgen zusammen,

wir haben seit der Umstellung der Terminalserver auf Server 2022 das Problem, dass manchmal keine zweite Remoteapp geöffnet werden kann. Bei Klick auf die zweite Applikation passiert einfach nichts. Kappt man die Verbindung zum gesamten Broker über das Symbol der Taskleiste "Alle Verbindungen trennen", öffnet sich innerhalb von Sekunden nach Klick die zweite Remoteapp. Die Verbindung zur ersten App wird getrennt. Die erste Remoteapp lässt sich nun aber wieder starten und es können beide Apps genutzt werden.

Ich finde keine Lösung und irgendwie fehlt mir auch ein wenig die Kreativität, wie ich das Problem angehen soll. Hat jemand von euch eine Idee oder schon mal etwas ähnliches gehabt? Das Problem scheint nicht mit einem einzelnen Sessionhost zusammenzuhängen, da das Problem bei allen Sessionhosts auftritt. Es könnte also auch mit dem Broker zusammenhängen?

Grüße!

Das Problem hing tatsächlich mit der Firmware eines eingesetzten Routers zusammen. Wie auch immer das zustande gekommen ist. Nach Austausch des Routers lief die Authentifizierung wieder problemlos.

Guten Morgen zusammen,

ich habe ein wenig den Überblick über PrintNightmare verloren.

Gibts inzwischen einen Patch, der es ermöglicht, dass man die Richtlinie "Annahme von Clientverbindungen zum Druckerspooler zulassen" wieder aktivieren kann?

Ich habe hier noch eine Software, die einen Etikettendrucker via gemapten LTP1 über einen freigegebenen Etikettendrucker anspricht.

Aktuell löschen wir vor dem drucker immer den Registryeintrag der Richtlinie und lassen den anschließend via eines gpupdate neu erstellen. Das nervt auf Dauer aber ziemlich...

Für den Rechner würde ich bei Behebung der Problematik eine Ausnahme machen und die Richtlinie generell deaktiviert lassen.

Firmware kann ich auch ausschließen.

Klassische Anbindung über ein RED-Device von Sophos. Das ist aber an allen Standorten gleich. Damit kann es nicht zusammenhängen.

Cipher Suites sollten passen:

ClientHello:

ServerHello:

Wir haben jedoch gerade rausgefunden, dass die Firmware der besagten nicht funktionierenden APs eine andere ist.

Wir machen mal ein Firmwareupdate und schauen weiter.

Hallo zusammen,

ich habe aktuell an einem Standort ein merkwürdiges Problem, bei dem wir nicht weiter kommen. Vielleicht hat jemand von euch ja noch eine Idee.

Wir richten an Außenstandorten immer ein WLAN über 802.1x ein. Die Standorte sind mittels SSL angebunden. An den Außenstandorten gibt's dann meistens die Firewall (Sophos RED), einen Switch und die APs. Auf den APs hinterlegen wir unseren Radius aus der Zentrale. Das Ganze funktioniert auch über alle Standorte hinweg. Das Regelwerk der Firewalls ist immer gleich. 

Nun haben wir einen neuen Standort dazwischen, der Probleme macht. Ich habe das Ganze mal mit dem Netmon mitgeschnitten.

Hier das Beispiel von einem anderen Standort, an dem alles ordnungsgemäß funktioniert:

Und hier das Beispiel von dem Standort, an dem es nicht funktioniert:

Warum kommt der Handshake nicht zustande? Der Radius hat ein offizielles, von einer Zertifizierungsstelle gekauftes Zertifikat. Das ist auch gültig und wird vom Client nicht abgelehnt. Zumindest wenn ich es mir anschaue nicht.

Das Zertifikat unterscheidet sich ja auch nicht zu den anderen Standorten, an denen es funktioniert. Mit dem Client kann es auch nicht zusammenhängen. Mit dem komme ich am anderen Standort ins WLAN.

Hat jemand von euch eine Idee, wo ich ansetzen kann?

Firewall und Routing ist 1000x geprüft. Das kann ich ausschließen.

Grüße!

Edit: die Screenshots stammen vom Radius.

Super! 1000 Dank, genau das habe ich gesucht!

Alles klar, verstehe! 

Kennst du/ihr eine Lösung um diesen Prozess (die Adressänderung) in erster Instanz zu vereinfachen? Dies kann auch gerne ein kleines Modul eines IM-Systems sein, darf also auch gerne ein bisschen Geld kosten. Ich würde mich dann als nächsten Schritt ein wenig einlesen wollen um dann vielleicht einen ext. Dienstleister mit ins Boot zu holen. Vielleicht lassen sich durch ein solches System auch andere Prozesse (die ich jetzt spontan noch nicht auf dem Schirm habe) vereinfachen.

Ich habe das Skript gerade mal getestet. Scheint aktuell leider nicht mehr zu funktionieren. 

"Die Sicherheitseinstellungen dieses Computers lassen den Zugriff auf eine Datenquelle in einer anderen Domäne nicht zu."

Kenne ich bisher nur von den Sicherheitsoptionen der einzelnen Zonen im IE...

Genau sowas suche ich. Wir möchten gerne unsere Signaturen mithilfe von CodeTwo Email Signatures for Office 365 automatisieren.

Dafür müssen wir anfangen, unser AD ordentlich zu pflegen. Diese Pflege soll aber nicht innerhalb der IT vorgenommen werden.

Warum ist es aus deiner Sicht keine Lösung?

Guten Morgen zusammen!

Wir möchten gerne das Identity Management unseres ADs (Pflege von Telefonnummern, Adressen, Stellenbezeichnung, etc.) an eine andere Stelle delegieren. Ich hatte mir kurzfristig überlegt, via PrimalForms selber ein kleines Programm zu basteln und den entsprechenden Personen zur Verfügung zu stellen. Und nun frage ich mich... Gibt's dafür eventuell schönere, vorhandene und bezahlbare Lösungen?

Grüße!

Okay, Server waren vielleicht ein denkbar schlechtes Beispiel. An den kleineren Standorten stehen keine Server.

Nehmen wir z.B. die Managementschnittstelle von einem Accesspoint, die sich in einem anderen Subnetz als die Clients Vorort befindet. Diese möchte ich aus der Zentrale erreichen können. Das Routing übernimmt nach meinem Verständnis dann die lokale UTM. Warum sonst sollte man VLANs auf dem RED einrichten können. 

Ich glaube die Frage ist ziemlich RED-spezifisch. Bei je einer Firewall pro Standort wäre das klar... Dann könnte ich in jedem Standort die gleiche VLAN-ID verwenden.

Nein, die RED-Devices können nicht routen.

Der Durchsatz reicht, es sind wirklich kleine Standorte. 

Die RED50 haben einen Durchsatz von 850 MBit/s.

Am sinnvollsten wäre natürlich eine eigene Firewall je Standort. Aber da kommen wir an die Grenzen des machbaren und administrierbaren.