RobertWi

Doch, das "wie" hängt nur mit der Outlook-Version zusammen, was uns der OP aber leider verschweigt. Sehr komfortabel ist Ol2010, Ol2007 und Ol2003 sind etwas weniger komfortable. Aber eigentlich braucht man das in Outlook gar nicht. Es reicht einfach, den anderen Benutzer im VON:-Feld auszuwählen - fertig.

Moin, kann ich annehmen, dass Du ein deutsches Windows hast? Wenn ja, dann brauchst Du bei Export-CVS noch den Schalter -Delimiter ";" - sonst exportiert Export-CSV genau so, wie es der Name sagt: Comma-Separated Value. Und Komma mag ein deutsches Windows nicht, es möchte dort das Semikolon. (Alternativ kannst Du Dir auch die regional Einstellungen umstellen.)

Moin, ist die Mail sichtbar, wenn Du den Cache-Mode ausschaltest oder per OWA reinschaust?

Moin, schau mal, ob das bei Dir zutrifft: https://blogs.msdn.com/b/pepeedu/archive/2010/08/26/how-to-upgrade-a-universal-distribution-group-to-a-universal-security-group.aspx

Moin, ach Mist, wer lesen kann ist klar im Vorteil. Ja, das geht erst ab 2010 in der Shell, bei 2007 nur mit Outlook (oder anderen externen Programmen). Ist die Gruppe E-mail-aktiviert?

Moin, das ist aber kein Sache bei Dir, sondern beim Server mx51.mymxserver.com. Viele Relay-Server haben so eine "Spam-Sperre". Dir bleibt nichts anderes übrig, als die Mail mit weniger Empfängern zu schicken oder über einen anderen Mail-Relay zu gehen, der mehr erlaubt.

Könntest Du den kompletten Abschnitt mal rauskopieren und hier posten (am besten in CODE-Tags)

Moin, wenn das nur ein Postfach ist, ist es leichter mit Outlook gemacht. Ansonsten: Add-MailboxFolderPermission ALIAS:\Posteingang -User USER -AccessRights Reviewer ALIAS = Postfach, auf das lesend zugegriffen werden soll USER = Deine Gruppe Eventuell muss Du das noch eine Ebene weiter oben wiederholen, also nur "ALIAS:\", ohne das Posteingang.

Moin, AD-Permission ist das falsche CMDLET, dafür brauchst Du "Add-Mailboxfolderpermission", da es mit den AD-Berechtigungen nicht möglich ist, Nur-Lesen zu vergeben. An der Stelle funktioniert nur Vollzugriff. Allerdings ist das sehr mühselig, da es innerhalb eines Postfaches keine Vererbung gibt und daher mit Hilfe einer PowerShell-Schleife selbst rekursiv durch die Ordner gegangen werden muss (und bei jedem neuen Ordner muss die Berechtigung wieder eingetragen werden).

Dann warten wir auf die Fehlermeldungen im SMTP-Protokoll.

Anonym, Standard und Windows ist normal bei Autodiscover-Verzeichnis. Hat der Client einen Proxy eingestellt? Wenn ja, bitte die Exchange-Server als Ausnahme aufnehmen. Sonst wird das aus der Ferne schwer, dazu sind zu viele Variablen im Spiel.

Moin, die Bilder vom Fehler hat ein freundlicher Mod wieder entfernt, bitte kopiere die Fehlermeldung in Textform. Der Mailübergabe Dienst gehört zur Mailboxserver-Rolle und sorgt dafür das Mails von dort auf den Hub-Transport-Server gelangen. Ich würde also mal prüfen, was zu der fraglichen Zeit läuft und Mails via MAPI verschicken will. Virenscanner vielleicht oder ein Archivierungssystem? Off-Topic: Na ja ganz ehrlich: Wenn dieser Fehler genau einmal am Tag in der Nacht eintritt, würde ich ihn beobachten, aber sonst gar nichts weiter tun.

Moin, wenn es alle Benutzer betrifft, ist ein Fehler in einem Postfach unwahrscheinlich. Hier würde ich das MessageTracking aktivieren und mich vor allem um Dritt-Produkte kümmern. Ansonsten wäre das wohl ein Fall für den Support.

Moin, natürlich geht bei mir die OWA-Seite nicht, denn ich vertraue der PKI ja nicht. Macht aber nichts. Also zum nächsten Teil, der aus der Ferne aber schwierig zu finden sein wird. Wie ist denn der IIS, speziell die Authentifzierungseinstellungen, auf der "Autodiscover"-Webseite eingestellt?

Ergänzung: Dann ruf doch im Client mal die OWA-Seite auf im MSIE auf. Gibt es Fehler dabei? Wenn ja, welche?

Moin, im Prinzip reicht es, um ein Zertifikat zum Verschlüsseln zu bekommen (denn das tut es). Die Mache haben aber auch eingebaut, das der Herausgeber den Anfordernden überprüft und damit garantiert, dass das Zertifikat auch vom richtigen angefordert wurde. Das nennt man dann "Vertrauenswürdigkeit". Du hast eine eigene PKI aufgebaut. Als Konzequenz vertraut der niemand, denn sonst könnte ja jeder eine PKI einfach so aufbauen. Normalweise werden alle internen Clients über Gruppenrichtlinien in den nächsten Stunden Deiner PKI vertrauen. Falls das nicht passiert, musst Du, wie oben schon beschrieben, über die CA-Verwaltung das Zertifikat der Stammstelle aufrufen, exportieren (ohne privaten Schlüssel), auf den Client kopieren und dort wieder importieren (in vertrauenswürdige Herausgeber).

Moin, jetzt wo ich mir das Zertifikat selbst noch mal ansehe: Du hast eine eigene PKI benutzt (na ja, wie auch im Link oben beschrieben). Setz bei der Prüfung mit ExRCA mal den Haken "Vertrauensstellung für SSL ignorieren", denn geht wenigstens der Test. Damit Deine Clients das Zertifikat akzeptieren, musst Du den öffentlichen Schlüssel aus der PKI exportieren und bei den Clients als vertrauenswürdige Zertifizierungstelle wieder importieren.

Moin, ermahnt vermutlich nicht, aber eventuell wurde Dir gesagt, dass es sicherer wäre sie nicht zu nennen. Ist es meistens ja auch und meistens auch nicht notwendig - außer bei DNS-Problemen. :) Autodiscover hat übrigens einen CNAME (ich habe es jetzt mal verschleiert, ein Mod kann das gerne bei Dir oben jetzt tun): > set type=cname > autodiscover.xxxxagrar.de Server: server04.sm-rw.local Address: 192.168.11.234 Nicht autorisierende Antwort: autodiscover.xxxxagrar.de canonical name = ssl.xxxxagrar.de ssl.xxxxagrar.de internet address = 217.86.yyy.zzz Dein Zertifikat hört übrigens auf die richten Namen, aber laut Firefox ist die Zertifikatskette nicht komplett: Dem Zertifikat wird nicht vertraut, weil [b]keine Zertifikatsausstellerkette angegeben[/b] wurde. Das Zertifikat gilt nur für folgende Namen: owa.xxxxagrar.de , ssl.xxxxagrar.de , autodiscover.xxxxagrar.de , autodiscover.xxxxagrar.local , server-exch.xxxxagrar.local , server-exch Das steht auch oben im Fehler: The certificate chain couldn't be built. You may be missing required intermediate certificates.

Na ja, ich gebe zu, ist schon ein bisschen her und eventuell habe wir auch ein Zusatzprogramm fürs Aufräumen benutzt.

Moin, DIG ist ja nur ein Anzeigeprogramm, kein Konfigurationsprogramm. Da Du leider die Domänen verschleierst, können wir nicht mal nachsehen, was da im DNS zur Zeit eingestellt ist. Dem DNS-Admins sagst Du das, was ich Dir oben geschrieben habe: Eine A-Eintrag für Autodiscover mit Deiner IP zusätzlich oder einen CNAME-Eintrage für Autodiscover. Wenn der damit nichts anfangen kann, solltest Du den Anbieter wechseln. :)

Moin, über welche Exchange-Version reden wir eigentlich? Betrifft das alle Benutzer oder nur einen/wenige? Vielleicht hilft ein Blick mit MFCMAPI in das Postfach (MSXFAQ.DE - Out of Office, kurz vor dem Ende). Eventuell spielt auch eine Dritt-Anbieter mit rein.

Off-Topic: Wieso? Auch bei E2003 gab es SMTP- und Diagnose-Protokolle und auch bei 2003 wurden die SMTP-Logs im "Roll-Over"-Verfahren wieder entfernt. Nur war hier der IIS für zuständig und nicht Exchange.

Nö, das geht auch beim SBS nicht. Der bringt nur diesen vollkommen überflüssigen POP3-Connector mit, um Mails aus dem Internet abzuholen und auf den Server zu bringen - aber nichts zum Senden und nichts zum Auswählen für den Benutzer.

Das ist nicht nur unsupported, sondern für nach Aussagen der Entwickler sogar zu Fehlern, bis zum Totalversagen von Exchange.

Da verwechselst Du SMTP-Logging mit der Diagnose Protokollierung. Es gibt keinen Grund, warum man SMTP-Protokollierung wieder abschalten sollte, da Exchange die Festplatten-Belegung wunderbar überwacht und man im nach hinein sonst nichts mehr sieht. @Rincelot: Die komplette Fehlermeldung ist bestimmt länger, hierfür muss man nur die Spalte größer machen oder die Maus über die Meldung halten.