bunfried

Den Freigabeberechtigungen sei Dank. Der erste XP-Rechner hat es übernommen. Die Vista-Rechner wehren sich noch ein bißchen. :D

Hab bei der Freigabe gesehen, daß die Domänencomputer nur bei der Sicherheit eingetragen waren, aber nicht beim Zugriff. Mal sehen was nach gpupdate /force passiert...

Klar. Die Hinweise deuten darauf hin, daß die Netzwerkfreigabe zum Zeitpunkt der GPO-Übernahmen nicht vorhanden ist. Allerdings sind genau dafür die beiden erwähnten Policy-settings.

Ich verteile bei mehreren Kunden diverse Softwarepakete (Acrobat Reader, Flashplayer, etc.) via GPO. Allerdings habe ich bei einem das Problem das beim Client die event id´s 102, 108 und 1085 im Ereignisprotokoll auftreten und die Softwareverteilung nicht ausgeführt hat. Die "Anmeldeskripts gleichzeitig ausführen" und "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" sind inzwischen aktiviert. Trotzdem "überfliegen" alle Domänen-PCs die Sicherheitsrichtlinie. Die Zugriffsberechtigungen sind ok und habe ich testweise auch schon mal auf "Jeder" gesetzt. Erfolglos. Hat wer eine Idee??:cry:

Hier gibt es alles was man braucht: Monitoring/Management, Neuzugänge und Updates, Download bei heise

Hab ich probiert, aber das relay war trotzdem offen. Ich werd mal prüfen welche Routing-Einträge für den "Tag der offenen Tür" verantwortlich sind.

Die Umstellung war gar nicht so ohne. Aber wie gesagt, sogar laut Zyxel war die config einwandfrei. Ich bekomm jetzt sogar eine Teststellung in Taiwan, weil ich die IPsec-VPN-Verbindungen nicht so performen wie gehabt.

Das hab ich überhört.;) Aber mit der ZyWall USG 100 steh ich sowieso auf Kriegsfuß. Der Zywall-Support (!) hat mir zwar bestätigt, daß die config in Ordnung ist. Aber ich hab trotzdem immer wieder Routingprobleme gehabt. Aber was da jetzt los war, weiß ich noch nicht. :nene:

Lösung gefunden: Die Firewall war der Übeltäter. Das Routing hat es scheinbar zu gut gemeint und den externen Traffic direkt ins LAN geroutet. Dort ist das Relay ja zugänglich.

Schon mal ins Ereignisprotokoll geschaut? Wie geht´s dem RAID? Ein paar Infos wären nicht schlecht.... Alles andere ist Kaffeesudlesen. :-)

Die Frage ist eher wo es nicht auftritt.:shock: Mail Relay testing. Connecting to MAILSERVER for test ... <<< 220 DOMAIN Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Mon, 7 Sep 2009 09:58:41 +0200 >>> HELO h.rbl.jp <<< 250 DOMAIN Hello [192.168.1.1] Relay test 0 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@h.rbl.jp> <<< 250 2.1.0 rlychk@h.rbl.jp....Sender OK >>> RCPT TO: <rlytest@rbl.jp> <<< 250 2.1.5 rlytest@rbl.jp relay accepted!! Relay test 1 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk> <<< 250 2.1.0 rlychk@DOMAIN....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 2 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <> <<< 250 2.1.0 <>....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 3 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 4 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@[iP]> <<< 250 2.1.0 rlychk@[iP]....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 5 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <rlytest%h.rbl.jp@MAILSERVER> <<< 250 2.1.5 rlytest%h.rbl.jp@MAILSERVER relay accepted!! Relay test 6 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <rlytest%h.rbl.jp@[iP]> <<< 250 2.1.5 rlytest%h.rbl.jp@[iP] relay accepted!! Relay test 10 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <"rlytest@h.rbl.jp"@MAILSERVER> <<< 250 2.1.5 "rlytest@h.rbl.jp"@MAILSERVER relay accepted!! Relay test 11 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <"rlytest@h.rbl.jp"@[iP]> <<< 250 2.1.5 "rlytest@h.rbl.jp"@[iP] relay accepted!! Relay test 12 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <@MAILSERVER:rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 13 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <@[iP]:rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 15 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <h.rbl.jp!rlytest@MAILSERVER> <<< 250 2.1.5 h.rbl.jp!rlytest@MAILSERVER relay accepted!! Relay test 16 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <h.rbl.jp!rlytest@[iP]> <<< 250 2.1.5 h.rbl.jp!rlytest@[iP] relay accepted!! Relay test 19 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@localhost> <<< 250 2.1.0 rlychk@localhost....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Closing connection ... >>> QUIT <<< 221 2.0.0 DOMAIN Service closing transmission channel Relay test result All tests performed, 14 relays accepted.

Nachdem mir diese Website (Third Party Relay Check RBL.JP????????? RBL.JP) bestätigt, daß ich ein Relay-Problem habe und ein ident konfigurierter Server ohne Probleme diesen Test besteht, glaube ich an ein relay-Problem. Außerdem hab ich seitdem ich SMTP auf der Firewall geschlossen habe, keine SPAM-Mail mehr in der Queue. Und laut Firewall versucht gerade die halbe Welt e-Mails über meinen Server weiterzusenden...:cry: 1 2009-09-07 09:47:32 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:60134 192.168.1.51:25 ACCESS BLOCK 3 2009-09-07 09:47:24 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 209.85.212.177:55896 192.168.1.51:25 ACCESS BLOCK 5 2009-09-07 09:47:23 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 66.135.197.24:33644 192.168.1.51:25 ACCESS BLOCK 7 2009-09-07 09:47:08 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:56706 192.168.1.51:25 ACCESS BLOCK 8 2009-09-07 09:47:07 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 209.85.212.177:62526 192.168.1.51:25 ACCESS BLOCK 9 2009-09-07 09:47:04 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 85.124.152.3:18970 192.168.1.51:25 ACCESS BLOCK 10 2009-09-07 09:47:03 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 195.62.26.18:11615 192.168.1.51:25 ACCESS BLOCK 11 2009-09-07 09:47:03 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 195.62.26.18:11613 192.168.1.51:25 ACCESS BLOCK 12 2009-09-07 09:46:59 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 66.135.197.24:33644 192.168.1.51:25 ACCESS BLOCK 13 2009-09-07 09:46:56 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 80.237.210.104:53695 192.168.1.51:25 ACCESS BLOCK 15 2009-09-07 09:46:47 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 213.4.129.21:54158 192.168.1.51:25 ACCESS BLOCK 16 2009-09-07 09:46:44 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 66.135.197.24:65185 192.168.1.51:25 ACCESS BLOCK 17 2009-09-07 09:46:43 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 209.85.212.177:62526 192.168.1.51:25 ACCESS BLOCK 18 2009-09-07 09:46:42 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 195.62.26.18:11615 192.168.1.51:25 ACCESS BLOCK 19 2009-09-07 09:46:42 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 195.62.26.18:11613 192.168.1.51:25 ACCESS BLOCK 20 2009-09-07 09:46:35 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 80.237.210.104:53695 192.168.1.51:25 ACCESS BLOCK 21 2009-09-07 09:46:31 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:24875 192.168.1.51:25 ACCESS BLOCK 23 2009-09-07 09:46:22 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 209.85.212.177:62526 192.168.1.51:25 ACCESS BLOCK 24 2009-09-07 09:46:17 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=2] 62.179.121.37:5229 192.168.1.51:25 ACCESS BLOCK 25 2009-09-07 09:46:07 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 80.121.153.19:42619 192.168.1.51:25 ACCESS BLOCK 26 2009-09-07 09:46:07 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:36431 192.168.1.51:25 ACCESS BLOCK 28 2009-09-07 09:45:50 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 66.135.197.24:65185 192.168.1.51:25 ACCESS BLOCK 29 2009-09-07 09:45:46 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 213.4.129.21:33823 192.168.1.51:25 ACCESS BLOCK

Ich hab einen fully-patched-SBS 2003 mit Exchange 2003 und ein massives Relay-Problem, obwohl alle relay-Möglichkeiten deaktiviert sind -> siehe attachments!!!!:shock: Das Problem tritt erst seit kurzem auf, aber dafür umso heftiger. Gestern mußte ich über 110.000 Mails eliminieren..... Bin im Moment ziemlich ratlos und hab den SMTP-Port auf der Firewall deaktiviert, damit der Server nicht abschmiert.:confused:

Klingt so als ob Du ihn noch nicht hochgestuft hättest. Server markieren -> rechte Maustaste und zum primären Server machen. Ups. Hab die anderen Antworten übersehen. :-()

Ja, aber warum hab ich das gleiche Problem auch in der virtuellen Maschine? Dort ist das Profil ja neu?????

:cry: Ich hab da ein hartnäckiges und kniffliges Problem und bin für jeden Tip dankbar!!! Mal ein paar Eckdaten zum Aufwärmen: W2k3 64bit DC XP-Client mit Office 2007 (zusätzlich eine virtuelle Maschine auf dem genannten XP client mit Office 2007) (Natürlich alles up-to-date):cool: Mein Problem sieht wie folgt aus: Wenn ich als Benutzer A auf dem XP-Client Powerpoint 2007 starte, bekomme ich eine fehlerhafte Darstellung des Textes "Titel durch Klicken hinzufügen". Wenn ich Text schreibe, sieht er aus als ob ich auf die Tabulator-Taste drücken würde: a b c d e f g h i j k l usw.:schreck: Starte ich Powerpoint 2007 mit "Ausführen als" mit irgendeinem anderem Domänenbenutzer, Admin oder was der Kuck-Kuck, klappt alles wunderbar. Melde ich mich als irgendein anderer Benutzer am PC an und starte Powerpoint, funktioniert es auch einwandfrei. Starte ich mit "Ausführen als" als Benutzer A dieselbe fehlerhafte Darstellung Was mich zum Grübeln bringt: - Es ist egal ob Benutzer A Admin, Domain-Admin od. nur Benutzer ist. Also dürfte es kein Rechteproblem sein. - GPOs für O2k7 gelten für alle Benutzer. Sollte also auch nicht schuld sein. - Mach ich das gleiche auf in der virtuellen Maschine, gibt es genau den gleichen Effekt!!! Also sollte es kein lokales Problem sein. Was zum Henker kann ich noch tun? :confused: Profil löschen und neu anlegen möchte ich nur als Allerletzes tun.

Hab hier einen sehr komischen Fall: Ich habe einen bestimmten Benutzer, der - egal auf welchem Rechner sich anmeldet - Probleme it Office 2007 hat. Z.B. Powerpoint zeigt bei der Eingabe von asdf nicht asdf sonder a s df an. Sehr strange und noch dazu auf allen Rechnern der Domäne!!! Bei jedem anderen Benutzer scheint es zu funktionieren. Wenn ich nun das Profil des defekten Benutzers kopiere und mich mit dem neuen Benutzer (z.B. Testuser) anmelde, klappt alles prima. Auch wenn ich in dem Profil eines beliebigen Users Powerpoint als "Problembenutzer" aufrufe das gleiche Bild. Ich bin grad ziemlich ratlos. Hat wer eine Idee????:confused: :confused: W2k3 Domäne mit R2 64bit DC (W2k3-Domäne, da Exchange 2007)

Es gibt auch eine Lösung. Ein scheinbar defektes Mail hat den Indexdienst gequält. Kaum ist es gelöscht, ist alles Eitel Wonne. :D

Volltextindizierung erfolgreich gestoppt. mssdmn.exe wütet aber weiter. :suspect:

Irgendwie hat mein Server während meines Kurztripps nach Brüssel Schlagseite bekommen.:shock: Der Dienst mssdmn.exe schnaltzt immer auf fast 100% und macht nur kurze Pausen. Im \gthrsvc Verzeichnis legt er laufend eine Mail mit dazugehörigen Attachment ab. Plus ein Temp-file. Die Vollindexierung habe ich schon erfolglos angehalten. Der Index ließ sich einfach nicht löschen. Des ESM reagiert einfach nicht mehr. Brauche dringend einen Tip. Plattform: w2k3, exchange 2k3, sql 2005 alles up to date.