Jump to content

RobertWi

Expert Member
  • Gesamte Inhalte

    4.985
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von RobertWi

  1. Moin,

     

    da Du die IP-Adressen und Domänen-Namen rausgenommen hast (was Dein gutes Recht ist), nimmst Du uns leider die Chance, das nachzuprüfen.

     

    Zum Beispiel würde ich sehr stark tippen, dass in dieser Zeile die IP-Adresse von Google steht, und nicht Eure interne.

    10:46:13 (out 68)>>> 250-mx.google.com at your service, [xxx.xxx.xxx.205]

     

    Ich lese aus dem obigen Protokoll, dass ihr eine Mail von einen Google-Account "tester131313131@googlemail.com" geschickt habt, die hat Google abgelehnt, weil es den Account nicht gibt (550-5.1.1 The email account that you tried to reach does not exist. Please try), das ist alles.

     

    Von einer Kommunikation Eurer externen IP-Adresse (was soll das sein, habt ihr im Modem, Router noch einen Mailserver?) kann ich oben nichts erkennen. Alles, was ich sehe, ist das ihr eine Mail an Google schicken wollten, an einen Account, de es nicht gibt.

     

    Aber wie gesagt: Das Verschleiern der IP-Adresse mach es nicht leichter.

  2. Moin,

     

    Meiner Meinung nach funktioniert das CAS-Array mit Windows-NLB nicht so, wie es sollte. Wenn ein MAPI-Client mit der NLB-IP bzw. dem NLB-Namen eine Verbindung zum CAS-Array aufgebaut hat, wird diese getrennt, wenn der entsprechende CAS-Server "ausfällt". Während der CAS-Server dann "down" ist, versucht Outlook eine Wiederherstellung. Dabei kommt es zum Beispiel dazu, dass erneut Anmeldedaten eingegeben werden sollen.

     

    Nun meine Frage: Wie sollte sich Outlook verhalten? Eigentlich dürfte der User doch nichts von einem Ausfall eines NLB-Knotens merken, oder liege ich da falsch?

     

    hier muss ich leider Norbert widersprechen. Was Du erlebst, ist das normale Verhalten beim Windows NLB und einer der zwei Gründe, warum MSFT WNLB nicht mehr empfiehlt für Exchange.

     

    Hintergrund: WNLB macht seine Zuordnung anhand der Client-IP-Adresse fest (Achtung bei NAT, dann geht alles auf einen Knoten - das ist der zweite Grund). Solange die sich nicht ändert, kommt der Client seine Lebzeit also immer beim gleichen NLB raus, was schon mal kein wirkliches Load Balancing ist.

     

    Der Client arbeitet also mit allen Verbindungen (RPC, HTTPS für OAB/EWS) gegen *einen* CAS-Server (wenn die URLs korrekt eingestellt sind) und hat von diesem für den Zugriff das Zugriffstoken, sowie eine SSL-Session bekommen.

     

    Beim Schwenk auf den anderen Knoten stellt der dortige IIS fest, dass ein bisher nicht bekannter Client erscheint, der eine SSL-Session verwendet, die dieser IIS gar nicht kennt - FEHLER. Die Auswirkungen im Client sind je nach Version unterschiedlich.

     

    Gute NLB verwalten daher ihre Session untereinander, in dem sie Cookies oder Sessions States oder andere Verbindungsinformationen untereinander austauschen.

     

    Wenn man diese Einschränkung kennt und damit leben kann, ist WNLB eine Alternative, da kostenlos. Will man es aber perfekt haben, bleibt nur ein Drittanbieter-Produkt.

  3. Moin,

     

    im IIS-Log könntest Du sehen, mit welcher Kennung da gearbeitet wird.

     

    Ich denke es handelt sich um (entweder / oder):

    - ein offenes Relay

    - eine gehacktes Passwort und die Nutzung von EWS/OWA

    - Backscatter

     

     

    1. Würdest Du im SMTP-Log sehen, nicht im MessageTracking.

    2. von einem gehackten und massenhaft verwendeten OWA habe ich noch nichts gehört, aber die EWS-Schnittstelle ist relativ einfach zu nutzen -> IIS-Protokolle sichten

    3. dagegen kannst Du nichts machen, außer einen vernünftigen Spam-Filter vor Exchange betreiben

     

    Halte uns auf den laufenden!

  4. Moin,

     

    das lese ich ja jetzt erst:

     

    Ich kann auch über die Emailadresse von bbb.info senden, allerdings laufen die Emails dann über den Smarthost der ersten Domäne (aaa.de). Wenn ich mir die empfangende Email anschaue, steht dort auch "...(helo=mail.aaa.de)..." - das ist ja falsch, da müsste dann ja auch "...(helo=mail.bbb.info)..." stehen.

     

    Nein, muss es natürlich nicht:

     

    1. Der FQDN muss zum PTR passen (macht er ja)

    2. Deine 1. Domäne heißt "aaa.de" und nicht "mail.aaa.de" - wenn es also ein Problem gäbe, gäbe es das schon lange, oder?

    3. Ich selbst sende ungefähr ein halbes Dutzend Kunden-Domänen über einen Mailserver, dessen FQDN keiner einzigen davon entspricht, aber Punkt 1. stimmt.

  5. Moin,

     

    auch bei MSFT arbeiten nur Menschen und da gibt es fähige und weniger fähige, motivierte und weniger motivierte, gute bezahlte und weniger gut bezahlte, usw.

     

    Auch der Kleinkunde kann zeigen, dass er Kunde ist: Nachhaken und notfalls auf Eskalation bestehen.

     

    In den letzten vier Wochen habe ich bei einem großen Kunden Erfahrungen mit dem Support eines Server/Storage-Herstellers und eines Virenscanner-Backup-Lösung-Herstellers gemacht - dagegen waren die hier beschrieben extrem gut. ;)

  6. Moin,

     

    ich habe ein kurioses Problem. Wir setzen einen Exchange 2010 SP1 (RU3) ein und haben das Phänomen, dass wenn wir eine Verteilergruppe einrichten, diese im Outlook Client (Outlook 2010) nicht auswählbar ist. Weder im Adressbuch noch über "Strg+k".

     

    in allen Clients oder nur in einem?

    Ist die Gruppe in OWA im Adressbuch sichtbar?

    Wie genau legt ihr die Gruppe an?

     

    Habe schon alles probiert: Autovervollständigen Liste geleert, Information Store vom Exchange neugestartet, Offline Adressbuch manuell synchronisiert.

     

    Gibt es beim letzten Schritt irgendwelche Fehler?

    Ungewöhnliche Einträge im Event-Log?

    Fehlermeldungen im ExBPA?

     

    Wenn ich den Information Store vom Exchange neustarte, bekommen alle User die Mitteilung dass sie ein kennwort eingeben müssen. Kann man das irgendwie unterbinden? Es handelt sich um Domänenuser.

     

    Nein, das ist normal. Das Zugriffstoken wird durch den Neustart ungültig. Outlook neu öffnen oder Windows neu starten helfen auch.

     

    DAs Problem ist, wenn ich ein "Send-As" auf ein Postfach oder Kontakt gebe, dauert es zum teil Stunden bis die Berechtigung aktiv ist...

     

    Das ist auch normal. Berechtigungen werden vom IS gecached. Beschleunigt werden kann das mit Neustart des IS, mit dem o.g. Nebeneffekt.

     

     

    Ich kann einfach nicht mehrere Stunden warten bis eine Berechtigung gesetzt ist. Das ist nicht mehr normal.

     

    Leider schon. Erste Tugend des Exchange-Admins: Geduld....

  7. Moin,

     

    das macht Outlook ja beim Client automatisch korrekt, wie der OP schreibt.

     

    Das Problem scheint ein DNS, netzerwerktechnisches oder Routing-technisches zu sein.

     

    Die Bilder von Frank sind dahingehend ein wenig missverständlich, als das er im ersten Bild einen Server hat (nawsv001.netatwork.de), der theoretisch von außen erreichbar sein könnte - es aber sicher nicht ist und auch nicht sein muss.

×
×
  • Neu erstellen...