RobertWi

"Internes Relay" wäre korrekt, solange Du keinen Edgetransport hast. Das kann reichen, eventuell braucht es aber noch einen Sende-Connector. Da der Link von Daniel für Ex 2003 ist und sich da an der Bedienung doch einiges geändert hat, hier einmal für 200/2010/2013: http://exchangeserverpro.com/how-to-share-an-email-domain-between-two-mail-systems/

Und dann stelle ich wieder die Frage: Wozu muss ein Personalratsmitglied in der Lage sein, in fremden Postfächern zu suchen? Je nach dem, ob die private Nutzung erlaubt ist und nicht, darf das genau eine Person (der Chef) oder niemand, ohne Zustimmung des Mitarbeiters. Sorry, ich rechtlichen Gründen ziehe ich mir hier raus, das ist mir zu heikel. Ich habe keine Lust, dass ein Anwalt bei mir steht und mich beschuldigt, ich hätte eine Anleitung zum Rechtsbruch geliefert. Du findest mit dem oben genannten Begriff problemlos dutzende Anleitungen in einer Suchmaschine Deiner Wahl.

Moin, Gegenfrage: Warum? Normalerweise muss man da keine Berechtigungen setzen. Wenn man möchte, dass jemand die DiscoverSearch (auch Mulit-Mailbox-Suche genannt) benutzen darf, dann steckt man ihn in die Gruppe "Discovery Management". Damit darf er suchen und das Postfach öffnen, da diese Gruppe Vollzugriff auf das Postfach hat.

Moin, ist zwar nur ein Workaround, aber dafür kann das Feld "einfacher Anzeigename" im Postfach benutzt werden Aus der Hilfe (Set-Mailbox): Was da drin steht, überscheibt in Mails den "Displayname". Da spielt in den Remote Domänen noch die Einstellung "Name des Absenders in Nachrichten anzeigen" mit rein. Allerdings weiß ich aus dem Kopf nicht, ob man die aktivieren oder deaktivieren muss, damit der SimpleDisplayName angezeigt wird (IMHO aktivieren).

Moin, zum eigentlich Problem zurück: Du obliegst dem Irrtum, dass "schnelles Netz" und "langsames Netz" wirklich was mit "Netz" zu tun hätte. In Wirklichkeit meint das "intern" (=schnell) und "extern (=langsam), aber bezogen auf das Domänennetz. Anders ausgedrückt: Innerhalb des Domänennetzes = schnell, außerhalb des Domänennetzes = langsam. Da Du einen PC hast, der nicht Mitglied der Domäne ist, gibt es kein Domänennetz für diesen Rechner und dieser Rehner betrachtet sich immer als "außerhalb = langsam". Das konntest Du ja mit Deinen Einstellungen auch bestätigen. Das wirklich in Outlook oder auf dem Client zu lösen, halte ich nicht für sinnvoll. Nutz SplitDNS dafür, wie von Alith Anar vorgeschlagen. Dann ist es Dir egal, ob Outlook intern auch Outlook Anywhere macht, oder nicht. Und dann noch der obligatorische Hinweis: Exchange 2003 ist nicht mehr supported (auch beim SBS, obwohl das Windows dort nochsupported) und bekommt daher keine Sicherheitsupdates mehr. Damit etwas sicherheitskritisches wie E-Mail zu machen, ist mindestens mutig. Ändere das, bevor das Kind in den Brunnen gefallen ist, weil Dir dann niemand mehr helfen wird!

Moin, fangen wir mal einfach an: - Welche Exchange-Version? - Server und Client komplett durchgepatch? - ist das Chef-Notebook Domänen Mitglied? Bitte sei so nett, und weise daraufhin, dass die Frage auch in einem anderen Forum gestellt wurde, damit niemand doppelte Antworten geben muss: http://social.technet.microsoft.com/Forums/de-DE/b6d72e3c-c96a-46cd-8f42-0b7ea41cd67c/outlook-anywhere-zur-verbindung-ber-tcp-zwingen?forum=exchange_serverde&prof=required

Mach das, das Ergebnis interessiert mich auch.

Systemsteuerung.

Moin, ein Forum ist ein schlechter Ort, um Grundlagenwissen zu vermitteln. Daher erst mal was zum Lesen: http://www.msxfaq.de/e2010/dag.htm Wichtig ist aber, dass Du beachtest, dass die DAG nur ein Teil eines HA-Konzeptes ist. Da gehört bei Exchange auch eine Betrachtung von CAS und HT rein und DC und DNS sind auch sehr wichtig. Und über Exchange hinaus gibt es auch viele Dinge, die Auswirkungen haben: Internetverbindung, Switche, Stromversorgung, usw. usf. Hier muss der Kunde genau definieren, was er will. Eine HA von 100% von Exchange ist zum Beispiel ziemlich sinnlos, wenn bei einem Stromausfall kein Client mehr läuft. Und schlussendlich musst Du Dir im Klaren sein, dass HA etwas anderes ist, als Desaster Recovery und man diese Dinge zwar koordinieren, aber nicht durcheinander bringen darf.

Wäre mir hier gar nicht erlaubt.

Ich habe ja nicht gesagt, dass das so gewollt ist (oder zumindest habe ich noch keine, sondern nur, dass ich das nachvollziehen kann. Ich könnte Dir Screenshots von einem Nicht-Mitglied und von einem Mitglied zeigen. Beim Mitglied sind die ÖO zu sehen, beim Nicht-Mitglied nicht. Woran das liegt, kann ich nicht erklären. Die ÖO sind korrekt eingerichtet und haben E-Mail-Adresse, die Hierarchie ist aktualisiert, die Postfächer sind da, Exchange ist der Meinung, dass in den ÖO alles schick ist. Für beide Clients funktioniert Autodiscover, die Authentifizierung ist intern und extern identisch, Outlook Anywhere benutzen eh beide. Auch die Artikel, die ich kenne (hier, hier) beziehen sich immer darauf, dass man die ÖO nicht öffnen kann, aber nicht darauf, dass sie gar nicht zu sehen sind. Das einzige, was sich zwischen den beiden technisch unterscheidet, ist der Autodiscover-Prozess. Und das ist der einzige Ort, an dem ich mir einen "Fehler" vorstellen kann. Ob das aber eine Einstellung oder ein Bug ist, konnte ich bisher nicht ermitteln. Na ja, und da das Ex 2013 ist, kommt man dann halt schnell darauf, dass das eher ein Bug als ein Feature ist. :(

Leider läuft Ex 2010 nicht auf Windows 2012 R2, nur auf Windows 2012 ohne R2. Ob man sich den antun will, muss jeder selbst entscheiden. Ich finde den R2 ganz ok und im direkten Vergleich 2012 ohne R2 schrecklich. Dann lieber noch 2008 R2.

Moin, falls die Postfächer per Automapping eingebunden sind, deaktiviere das mal und binde die als natives Exchange-Postfach mit in das Profil ein. Der Regkey für Outlook sollte allerdings auch bei 2013 noch funktionieren (und tut er hier, allerdings mit Ex 2010). Es war auch bei Ex 2010 so, dass normalerweise die Mails im eigenen gesendet-Ordner landen, solange man den Standard ohne Konfiguration benutzt.

Moin, ich habe zumindest die Hoffnung noch nicht aufgegeben, zumal sich die Productgroup dieser Probleme wirklich bewusst ist. Seit dem RTM ist schon viel passiert, aber offensichtlich war damals so viel schief, dass man das nicht mal so eben ausbügeln kann. Wir erleben hier vermutlich Auswirkungen der von Ballmer postulierten "Alles in die Cloud" Strategie, die On-Prem Kunden vernachlässigt hat. Vielleicht beruhigt es, dass Microsoft sich bei der MEC (einer Exchange Konferenz in den USA) offen und verbindlich dazu erklärt hat, auch zukünftig On-Prem Software zu liefern (allerdings haben sie das genaue "wie" offen gelassen). Wiederholt wurde das bei der Teched. Eventuell nimmt man dann Ex 2013 einfach als das "Vista" der Exchange Reihe und wartet auf die nächste Version. Exchange 2010 ist auf jeden Fall eine Version, die äußerst stabil und performant läuft mit der die Entwickler die Latte sehr hoch gelegt haben und an die sich eine neue Version immer messen sollte.

Moin, inhaltlich spricht nichts gegen die Aktualisierung. ABER: Ich persönlich rate meinen Kunden immer noch von einer Aktualisierung ab. Die Gründe dazu sind sehr vielfältig, hier mal ein paar im Überblick: - immer noch schlechte Produktqualität (teilweise wurden CU ungetestet veröffentlicht und die Prio liegt eher darauf, neue Features einzubauen, als vorhandene zu stabilisieren) - deutlich gestiegene Hardware-Anforderungen - komplett geändertes, in der Praxis sehr aufwendiges und fehlerträchtiges Patchmanagement - neues Bedienkonzept - ständige Probleme mit Dritt-Anbieter-Tools (mittlerweile bauen Hersteller von Dritt-Anbieter Monitoring ein, ob Exchange noch läuft und reagieren notfalls darauf) - scheinbar "grundlos" geänderte Funktionen (oder neue Bugs, jedenfalls liefen diese Funktionen bei 2010 noch problemlos) Der Mehrwert, der 2013 bringt, ist relativ gering. Wer Hybrid nutzt, muss sich bei der Bedienung nicht umgewöhnen. OWA ist ein wenig schöner, aber deutlich performancelastiger (ein Kunde von mir hatte bei einer DSL 1000/100 keine Probleme mit OWA 2010, OWA 2013 ist dagegen unbedienbar geworden - Ergebnis: Die PF, die OWA brauchen, sind noch auf 2010). Auch die "modern Public Folder" stellen sich in der Praxis zwar als "modern", aber leider auch noch ziemlich verbugt heraus. Ein paar Tipps für die Praxis: - auf dem Exchange Server NICHTS installieren, was nichts mit Exchange zu tun hat -> viele Probleme, die ich erlebte sind daher gekommen, weil Exchange keine Rücksicht auf andere Software nimmt und nicht findet, wenn eine andere Software z.B. Änderungen am IIS gemacht hat - bei CU immer daraufgefasst sein, dass Exchange danach nicht mehr läuft oder bedienbar ist (Rückfallkonzepte in der Hinterhand haben und diese testen; gute Doku; eventuell das komplette Setup und die Konfiguration automatisieren oder wies es Microsoft in der Cloud macht, nicht updaten, sondern Server rollierend neuinstallieren) - für sehr gute Performance und Redundanz des Exchange Servers, SAN, Netzwerkes und DC sorgen - wenn wichtige Dritt-Anbieter-Tools im Einsatz sind, vor jedem CU ausführlich und intensiv testen, ob die weiterhin funktionieren - Änderungen an vorinstallierten Exchange-Komponenten nur vornehmen, wenn man ganz genau weiß, was man tut (es gibt mehr als einen Admin, die sich ihren Exchange komplett zerlegt haben, weil sie vermeintlich nicht mehr benötigte Zertifikate gelöscht haben) und diese immer gut dokumentieren, damit man notfalls den Ausgangszustand wiederherstellen kann Kurzum: Ich mache Exchange seit fast 15 Jahren intensiv, habe aber kein Release erlebt, dass auch nach über einem Jahr mit so vielen Kinderkrankheiten zu kämpfen hat, so viel Anforderungen an die Umgebung und das Wissen des Admins stellt, wie Ex 2013. Und ja (und die meisten anderen Exchange-MVPs) sind darüber extrem frustriert. :mad: Einfach mal "drauflos" wird garantiert schief gehen.

Moin, die Clients sind also nicht Mitglied der Domäne, in der Ex 2013 steht? Dann kann ich das mehrfach nachvollziehen, sogar in meiner eigenen Struktur. Nicht-Mitglieder sehen keine ÖO, die Mitglieder sehen sie. Eine Lösung dafür habe ich bisher nicht gefunden.

Verwirrung stiftet hier vermutlich einfach nur die schlechte Übersetzung von "Interimsupdate" in "Zwischenupdate". Würde dort Interimsupdate stehen, würde sich den meisten die Frage gar nicht erst stellen, weil der Begriff in der Microsoft-Terminologie feststeht.

Moin, Exchange selbst macht es so: [code}Get-recipient -Filter 'Members -eq DN-DES-USERS[/code] Ein kurzer Blick ins AD geht aber wahrscheinlich schneller.

Hast Du eventuell auf der neuen Karte IPv6 deaktiviert? Das wäre nicht zulässig und wird gerade vom Transportdienst mit Nichtstart geahndet.

Sollte so sein. Wenn es nur um die Anzeige (also keine Weiterverarbeitung) geht, kannst Du das auch gleich in anderen Einheiten anzeigen lassen, in dem Du an "$_.TotalDeletedItemSize.Value" anfügst: "tokb()" oder "tomb()" oder "togb()" usw.

Moin, das wäre eine Möglichkeit: Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select-Object @{e={$_.TotalDeletedItemSize.Value};l="Size"}| Measure-Object -Property size -Sum Das ist aber je nach Anzahl der Postfächer und Datenbanken schrecklich unperformant.

Eventuell wieder so ein Problem bei mehr als einem DC am Standort?

Ja. ;) Wenn alle Deine CAS-Server im gleichen AD-Standort sind, ist das einfacher: Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://remote.kundendomain.com

Ich habe das auch schon bei Ex 2010 erlebt. Manchmal bleibt der Automapping Eintrag als Leiche übrig.

Ein Admin hat standardmäßig keine Berechtigungen auf Postfächer zuzugreifen (aber er kann ihn sich verschaffen). Dann ist das offensichtlich was in den Berechtigungen falsch. Wir wurden die denn vergeben?