TiTux

So, wir haben den Fehler gefunden. Alle Session Hosts wurden ja mit dem gleichen Host A Eintrag in den DNS Server eingetragen und hier befand sich auch leider der Connection Broker selber. Also passierte es immer wieder, dass der Connection Broker einem Client als Terminal Server angeboten wurde (wegen der Lastverteilung) und darauf konnte sich natürlich niemand anmelden und bekam die oben genannte Fehlermeldung. Viele Grüße TiTux

Hi, beides kommt in Frage, bloß wo genau setzte ich das um? Geht's per GPO oder über die Registry?

Hallo, wir haben hier eine RDPFarm Umgebung mit Windows Server 2012 R2. Die Schattenkopien wurden auf dem Fileserver aktiviert, aber ich möchte gerne den Usern die Möglichkeit nehmen, dass sie selber Ordner/Dateien wiederherstellen können. Entweder dadurch, dass der komplette Reiter "Vorgängerversionen" ausgeblendet wird oder einfach nur die Berechtigung nehmen, dies durchzuführen. In den Gruppenrichtlinien hatte ich unter Windows Komponenten > Datei-Explorer > Vorherige Versionen 6 Optionen gefunden, der erste hatte sich gut angehört: "Wiederherstellung vorheriger Versionen aus Sicherungen verhindern", aber das hatte leider keine Auswirkung. Wer hat das von Euch schon umgesetzt und kann mir einen Tipp geben, an welcher Stelle ich schrauben muss? VG TiTux

Hi, die Clients connecten sich über den FQDN Farmnamen, um einen DNS-Lastenausgleich zu verwenden, also nicht den Hostnamen des Connection-Brokers selber.

Hallo Forum, wir nutzen eine Windows 2012 R2 RDP-Farm und haben derzeit das Problem, dass sporadisch der folgende Fehler auftritt, wenn sich ein Client (Windows 7) an der Farm anmelden möchte: "Die Verbindung wurde abgelehnt, da das Benutzerkonto nicht zur Remoteanmeldung autorisiert ist." Wenn dann am Client ein „gpupdate /force“ ausgeführt wird, funktioniert bei erneutem Versuch die Anmeldung sofort. Alle Server laufen auf Windows 2012 R2, es gibt einen Connection-Broker und fünf Session-Hosts mit Lastenausgleich. Im DNS Server gibt es jeweils einen A-Record, der auf den RDP-Farmnamen verweist, wir melden uns dementsprechend mit diesem FQDN via RDP-Client an. Die Benutzerprofile der Terminal-User verweisen auf einen Freigabe-Pfad, der auf dem Connection-Broker liegt. Ich weiß nicht, ob das ein Problem darstellt. (Der Loopbackverarbeitungsmodus ist aktiviert) Denn es wundert mich, dass die Anmeldung funktioniert, wenn man das gpupdate /force durchgeführt hat. Es werden zwei GPOs bei einer Anmeldung ausgeführt, die eine beinhaltet Einstellungen für die Terminal Server, wie z.B. Office-Einstellungen u. Zugriffsbeschränkungen u. die andere kopiert Dateien vom Server in das jeweilige User-Profil für eine Anwendung. Im Ereignislog vom DC sieht es gut aus, im Log vom Connection-Broker finde ich dann bei einem Fehlschlag den folgenden Fehler: Der Remotedesktop-Verbindungsbrokerclient konnte den Benutzer "Domäne\Benutzername" nicht umleiten. Fehler: NULL Ereignis-ID: 1306 Quelle: TerminalServices-SessionBroker-Client Im Netz hatte ich von Usern mit dem gleichen Problem gelesen, dort hat man dann die folgende GPO auf die Session Hosts angewendet: Computerkonfiguration > Administrative Vorlagen > Windows Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Remotedesktop-Verbindungsbroker: Einstellungen: Remotedesktop-Verbindungsbroker beitreten: Aktiviert Namen des Remotedesktop-Verbindungsbrokerservers konfigurieren: FQDN des Connection-Brokers Lastenausgleich des Remotedesktop-Verbindungsbrokers verwenden: Aktiviert Ich habe die GPO dann von den Terminal-Server ziehen lassen, dies brachte aber leider auch keine Änderung. Jetzt habe ich keinen Ansatzpunkt mehr und frage Euch, ob Ihr noch eine Idee habt, woran das liegen könnte? VG TiTux

Drucker lokal auf die Terminal Server zu installieren brachte mir auch nichts, der Standarddrucker hat sich trotzdem immer wieder geändert. Also diese Druckerthematik ist echt zum schreien, die Probleme hatte ich damals unter Windows 2000/2003 nicht.

Wie kann man das über eine GPP verteilen, wenn nicht alle Mitarbeiter alle Drucker erhalten sollen und dann noch ihren speziellen Drucker als Standard benötigen?

Servus, aber wie umgeht man das Problem dann am besten? In unserem Haus wird viel gedruckt und es gibt auch nicht gerade wenig Drucker. Auf dem PrintServer sind derzeit 71 Drucker freigegeben, es ist also leider keine Option, alle Drucker auf allen 5 Terminal Servern lokal zu installieren, zumal sich die Benutzer dann durch die große Liste scrollen müssten. So wie s Nils geschrieben hat, würde es uns wohl auch nichts bringen, wenn ich den Print Server auf einen 2012R2 umziehen würde?! Grüße TiTux

Hallo, kurz zum Aufbau: Server 2012R2 Domäne (64-Bit) 1 x Connection Brocker 2012R2 (64-Bit) 5 x Server 2012R2 RDP Session Hosts (64-Bit) 1 x Server 2008R2 Print Server (64-Bit) Wir haben hier eine Windows Server 2012R2 RDP Umgebung mit 5 Session Hosts mit Lastverteilung und einem Connection Broker. Im Netz gibt es einen Server 2008R2 Server, der als Printserver fungiert. Die Drucker werden händisch vom Client aus gemappt, es kommt keine GPO zum Einsatz. Seit ein paar Tagen habe ich nun bei mehreren Mitarbeitern das Problem, dass man den Standarddrucker einstellt und nach einer erneuten Anmeldung setzt in der letzten Drucker in der Liste als Standard. Beim RDP-Client ist eingestellt, dass er keinen lokalen Drucker mit mappt. Die Profile der User wurden über eine GPO auf einen Netzwerkpfad abgelegt (Roaming Profiles). Bis jetzt habe ich das Problem nur lösen können, wenn das Profil unbenannt/gelöscht wurde und anschließend automatisch neu erstellt wurde. Aber das kann ja nicht Lösung sein, da das immer wieder passiert u. einige Profile sind recht aufwendig, sie wieder einzurichten. Das Problem scheint es im Netz häufiger zu geben, aber ich habe noch nichts von einem Hotfix oder einer Lösunge gelesen. Mir würde es im ersten Schritt auch helfen, wenn ich wüsste, an welcher Stelle und in welcher Datei im Profil hinterlegt ist, welche Drucker man in seinem Profil hat, dann könnte man nur diese Druckereinrichtung löschen, anstelle des ganzen Profils. Wer kann mir hier bitte einen Tipp geben? Viele Grüße TiTux

@twenty Ihr löscht ja die Registry Keys, auf Empfehlung von MS. Wir haben hier 5 Session Hosts und einen Connection Brocker, bedeutet also für mich, wenn ich das testen möchte, dass ich das Script jede Nacht auf den 5 Session Hosts laufen lassen müsste? Grüße TiTux

Hallo, wir haben hier einen Exchange 2010 mit aktiven SSL-Zertifikat. Autodiscover ist auch mit im Zertifikat eingebunden. Bei einem lokalen Outlook im Netz gibt es keine Probleme. Melde ich mich jedoch mit einem normalen Benutzer über OWA an und möchte dann einen Punkt unter den Optionen wie z.B. "Automatische Antworten", oder "Kennwort ändern" gehen, wechselt der Benutzer dort sofort auf den Administrator. Alle Einstellungen, die ich dann vornehmen, werden also unter dem Administrator Account eingestellt u. nicht unter meinem angemeldeten Benutzer. Gehe ich dann wieder oben links auf den Reiter "E-Mail", befinde ich mich wieder ganz normal im Mailpostfach des Benutzers. Ich weiß nicht, wo ich hier ansetzen muss, was hier verdreht konfiguriert sein könnte. Viele Grüße Rainer

Hallo TheFstX, konntest Du das Problem lösen, ich habe nämlich das gleiche Problem derzeit. Gruß TiTux

Wir belassen es einfach dabei, Hauptsache ich konnte mein Problem fixen ;)

Hat alles seine Vor- und Nachteile, wie's immer so ist :p

Yep, so ist es und das passiert hinter der FW.

Hi Robert, Vielen Dank für den Hinweis! Das war es, was ich nicht verstanden hatte, wie der Spammer Kontakt mit dem Exchange aufnimmt, da ich mir sicher war, dass unser Exchange nicht auf dem SMTP Port lauscht. Den Port habe ich in der Firewall nun dicht gemacht, ein Kollege muss hier vergessen haben (es sind ja immer die Kollegen ;-) das anzupassen, als wir den MX-Record umgestellt hatten. Nun werde ich noch für jeden Benutzer ein neues Passwort setzen, da ein Konto anscheinend kompromittiert wurde. Dann beobachte ich mal, ob jetzt Ruhe im Karton ist. Danke Dir Robert, warst mir ein große Hilfe! :thumb1: Gruß TiTux

Ja, mit der Reihenfolge hatte ich mich vertan, meinte von unten nach oben, mich hatte die 192.168.1.107 irritiert, da es sich ja um eine private IP handelt. Aber bei genauem hinschauen mit einem Analyzer sieht man ja, dass es nur die interne Kommunikation von cesmail.net ist. Aber nochmal für's Verständnis: Wie schafft es jetzt der Spammer, über seine externe IP 41.203.79.249 eine Mail mit einem authentifizierten Benutzer (vorrausgesetzt, er hat Login und Passwort von einem Domänen-Benutzer)?

Hi Robert, aber wie funktioniert das dann von aussen, dass der Angreifer direkt von seinem Netz aus über unseren Exchange raussenden kann? Im oberen Teil findet sich ja das hier: Received: from unknown (192.168.1.107) by filter8.cesmail.net with QMQP; 13 Jun 2012 01:23:53 -0000 Das ist ja der Startschuss beim Versand der Mail gewesen, denn der Weg geht ja von oben nach unten im Header, wenn ich's richtig verstanden habe. Hier steht ja die 192.168.1.107 Wir haben hier auch das Netz: 192.168.1.0 Kann das ein Zufall sein oder verstehe ich was falsch?

Also das Problem besteht immer noch :( Der Exchange Server steht ja nicht direkt im Netz, wir senden über unseren Provider nach draussen und holen per Pop3 die Mails ab. Der Provider hat uns jetzt mal eine typische Spammail zukommen lassen: [ SpamCop V4.6.2.001 ] This message is brief for your comfort. Please use links below for details. Email from 213.216.23.81 / Wed, 13 Jun 2012 03:21:46 +0200 http://www.spamcop.net/w3m?i=z5787600875z026d6e8f8498c759a0eff800810dd21fz [ Offending message ] Return-Path: <info@triburg.co.in> Delivered-To: spamcop-net-x Received: (qmail 27257 invoked from network); 13 Jun 2012 01:23:53 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: ********** X-Spam-Status: hits=10.8 tests=DATE_IN_FUTURE_06_12,FORGED_MUA_OUTLOOK, MISSING_HEADERS,RDNS_NONE,SUBJ_ALL_CAPS version=3.2.4 Received: from unknown (192.168.1.107) by filter8.cesmail.net with QMQP; 13 Jun 2012 01:23:53 -0000 Received: from unknown (HELO fetchmail.cesmail.net) (64.88.168.84) by mx70.cesmail.net with SMTP; 13 Jun 2012 01:23:53 -0000 Delivered-To: x Received: from mail1309.opentransfer.com [76.162.254.102] by fetchmail.cesmail.net with POP3 (fetchmail-6.2.1) for x (single-drop); Tue, 12 Jun 2012 21:25:42 -0400 (EDT) Received: (qmail 17806 invoked by uid 399); 13 Jun 2012 01:21:52 -0000 Received: from unknown (HELO ironport-1.opentransfer.com) (none@76.162.254.109) by mail1309.opentransfer.com with ESMTPM; 13 Jun 2012 01:21:52 -0000 X-Originating-IP: 76.162.254.109 Received: from mail.workss.de ([212.12.32.20]) by ironport-1.opentransfer.com with ESMTP; 12 Jun 2012 21:21:52 -0400 Received: from [212.12.40.178] (helo=mail.workss.de) by mail.workss.de with esmtp (Exim 4.69) (envelope-from <info@triburg.co.in>) id 1SecHK-00085A-3S; Wed, 13 Jun 2012 03:21:46 +0200 Received: from [213.216.23.81] (helo=srv-mail-001.domain.local) by smtp.workss.de with esmtpa (Exim 4.72) (envelope-from <info@triburg.co.in>) id 1SecHJ-00074R-Vc; Wed, 13 Jun 2012 03:21:46 +0200 Received: from User ([41.203.79.249]) by srv-mail-001.domain.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 03:25:44 +0200 Reply-To: <alloyhounso37@e-mail.ua> From: "Jane Baxter"<info@triburg.co.in> Subject: STOP THE JOKE AND WASTE!!! TAKE THE RIGHT CONTACT. Date: Wed, 13 Jun 2012 02:21:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Antivirus: avast! (VPS 120612-0, 06/11/2012), Outbound message X-Antivirus-Status: Clean Bcc: Message-ID: <NI-S___________________14e4@srv-mail-001.domain.local> X-OriginalArrivalTime: 13 Jun 2012 01:25:46.0546 (UTC) FILETIME=[754F1920:01CD4903] X-SpamCop-Checked: X-SpamCop-Disposition: Blocked SpamAssassin=10 Hello Dear, I am Ms. Jane Baxter; I am a US citizen, 48 years Old. I reside at 3213 290 TH Street, Brock ton, Iowa 50836, United States .. usw Mir fehlt irgendwie die Übersicht, wie ich evtl anhand des Headers hier herausfinden kann, wer der Übeltäter sei kann. Auf RBL.JP hat der Exchange Server alle Tests bestanden. Jemand eine Idee? Gruß TiTux

Ah, okay, wieder was gelernt! Er war in der Gruppe der Domänen-Admins, dort habe ich ihn jetzt entfernt, aber das sollte ja nicht unmittelbar mit dem Problem zusammenhängen, denk ich mal. Eben jedenfalls noch einmal getestet, immer noch keine Synchronisation, dann schaue ich morgen nochmal danach.

Hi Norbert, den Haken hatte er nach einem erneuten prüfen nicht mehr gesetzt, jetzt habe ich noch einmal den Standard Button gedrückt und den Haken noch einmal gesetzt, werde mir das in ca. 2 Stunden noch einmal anschauen. Ciao TiTux

Hi Sunny, Danke, das probier ich mal aus, würde es wirklich schon einschränken ;-)

Hallo, wir setzen hier Windows Server 2003 mit Exchange 2003 ein. Nun hat ein Benutzer das Problem, dass Active Sync mit seinem Iphone nicht funktioniert. Die Einstellungen werden erfolgreich auf dem Iphone angenommen, aber beim Versuch, Mails zu synchronisieren, bleibt er immer im Modus "E-Mails empfangen..." stehen, es kommt zu keiner Fehlermeldung. Im Eventlog findet dabei kein Eintrag statt, der auf einen Fehler schließen lässt. Outlook Web Access funktioniert aber einwandfrei mit dem Konto. Teste ich das jetzt mit einem anderen Benutzer (der erst kürzlich frisch angelegt wurde), funktioniert Active Sync einwandfrei mit dem Iphone. Das Problem ist also Kontoabhängig. Nun habe ich die Sicherheitsberechtigungen der beiden Konten verglichen und hier muss der Fehler liegen. Beim dem Konto, welches funktioniert, werden ca. 50 Einträge angezeigt, beim anderen Konto sind es genau die Hälfte. Ich konnte feststellen, dass unter den erweiterten Sicherheitseinstellungen der Haken für Vererbung von oben nicht gesetzt war, den ich dann manuell gesetzt habe, dies brachte aber keine Änderung. Jetzt ist die Frage, wie ich dem Problem auf die Schliche kommen kann. Natürlich handelt es ich bei dem nicht funktionierdem Konto um das Geschäftsführer Konto, wie sollte es auch anders sein, muss hier also vorsichtig vorgehen und darf nichts zerschiessen. Jemand einen Tipp für mich, wie ich die restlichen Sicherheitsberechtigungen in das Konto bekomme? Falls benötigt, kann ich die beiden Berechtigungseinstellungen der Konten hier nachträglich posten. Gruß TiTux

Das Problem war, dass es sich um einen PC handelt, an dem ca. 30 Benutzer arbeiten (viele Kurzzeit-Arbeitskräfte, die auf diversen Seiten wohl unterwegs waren, was über einen Proxy ausschließlich protokolliert wird), Admin Rechte hat da niemand, der Virenclient war jedoch veraltet und das wurde nicht bemerkt.

Hi, sodele, ich konnte es auf ein paar PCs eingrenzen und diese habe ich mit einem Virenscanner geprüft und auf einer der Maschinen 20 Trojaner gefunden. Nachdem diese bereinigt sind, ist das Problem auch nicht mehr vorhanden. Den PC werde ich trotzdem neu aufsetzen, den bei so vielen Einträgen will ich sicher gehen. Vielen Dank an alle und schöne Woche TiTux