Beiträge von MarcelF

Zitat von RobertW

Aber dann ist doch das Postfach nicht per Automapping verbunden, oder wie soll das gehen?

Doch, in Outlook kann ich ja das Profil des AD-Users entsprechend händisch anlegen. Bzw. die notwenidgen Daten für das Autodiscover eintragen. (Name, E-Mail, Passwort)
Die 2. Mailbox wird dann automatisch mit "gemappt"

Zitat von RobertW

Dann schalte Vollzugriff aus, lösche das Postfach in Outlook warte zwei Stunden und richte dann alles noch mal neu ein.

Auch schon gemacht .. hab sogar ne Nacht lang gewartet.

Ich konnte das Problem weiter eingrenzen.

Die jeweilige 2. Mailbox wird in Outlook 2010 zwar automatisch eingehängt, kann aber nicht geöffnet werden.
Fehler: "Cannot expand the folder. The set of folders cannot be opened. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance"
oder
Fehler: "CAnnot expand the folder. The set of folders cannot be opened. The attempt to log on to Microsoft Exchange has failed"
Man nutzt auf dem Client, auf dem Outlook geöffnet wird, einen Account welcher keiner AD-Benutzer des Forests ist in dem sich der Exchange befindet.

Die Aussage "Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance" stimmt nicht

Wenn ich dem User Vollzugriff auf diverse andere Mailboxen gebe, funktioniert das ohne Problme (auch in Outlook 2016)

Wenn ich Vollzugriff auf die 2. Mailbox via EMS gebe mit dem Zusatz -Autoapping $false vergebe und die Mailbox manuell einhänge (sowohl Outlook 2010 als auch 2016) klappt es ebenfalls.

Im OWA kann ich alle Mailboxen öffenen, egal welche und wie der Vollzugriff gegeben wurde.
Cached Mode hab ich auch ausgeschaltet, bringt nix.
outlook.exe /resetnavpane habe ich auch schon probiert, bringt nix.

Ja, Autodiscover funktioniert soweit.
Auch in der Test E-mail AutoConfiguration Funktion von Outlook passt alles. Im XML-Tab steht die 2. Mailbox unter "Alternative Mailbox"
Das Autodiscover läuft in dem Fall via SRV-Record.

Zitat von RobertW

Das wundert mich. Normalerweise muss man nur seine Mail-Adresse und sein Passwort eingeben. Eventuell kommt dann später noch mal ein Username/Kennwort-Fenster, aber mehr braucht es eigentlich nicht.

So wie ich das verstanden habe ist das bei Outlook 2016 so.. und ja, es kommt nochmal ein extra Fenster in dem ich den AD-Account und das Passwort eingeben muss.

Ok, das war vielleicht missverständilich. Habe es ausgebessert.

Die Clients von Firma 2 sind AD-Mitglied von Firma 2, jedoch nicht von Firma 1.
Bei Firma 1 steht ja die Exchange-Infrastruktur.

Alle MA's von Firma 2 haben einen AD-Account bei Firma 1 bekommen, da früher oder später, nur noch die neue E-Mail-Domain und auch die AD-Umgebung (von Frima 1) verwendet werden soll.

Firma 2 hat jetzt noch eine "Schwester-Frima".
Die E-Mail-Domain dieser "Schwester-Firma" wurde bereits komplett auf den Exchange von Firma 1 umgezogen.

Somit haben 6 MA's 2 Mailboxen im Exchange von Firma 1.
Ihr Haupt-AD-Account bei Firma 1 hat Vollzugriff auf die 2. Mailbox

Wie gesagt, Firma 2 hat keinen eigenen Exchange-Server. Das wird alles bei Firma 1 gemacht.

Was mir auch noch aufgefallen ist.
Logge ich mich nun mit einem der Accounts auf einem Client von Firma 1 ein, funktioniert alles wie gewünscht.

Logge ich mich auf einem Client von Firma 1 mit einem lokalen Benutzeraccount ein und konfiguriere Outlook mit einem der Accounts habe ich dasselbe Verhalten wie auf den Clients von Firma 2.

Hallo zusammen,

als erstes die Umgebung

- Exchange 2010 SP3 RU9
- Windows 7 64 bit - Outlook 2016

Firma 2 wurde von Firma 1 übernommen.
Firma 2 hat eine AD-Struktur, jedoch keinen Exchange Server
Firma 2 migriert langsam in die komplette Infrastruktur von Frima 1.
Es besteht keine Vetrauenstellung zwischen beiden AD's (ist auch nicht geplant)
Die beiten Netzwerke sind physikalisch gekoppelt, jedoch logisch getrennt. Firma 2 kommt auf alles von Firma 1. Firma 2 schränkt jedoch den Zugriff von Firma 1 mittels Firewall ein.
Die relevanten DNS-Zonen von Firma 1 werden von Firma 2 mittels AXFR gezogen.
Alle Clients von Firma 2 sind AD-Mitglied von Firma 2. (jedoch nicht von Firma 1)

Firma 2 hat eine neue E-Mail-Domain bekommen welche auf dem Exchange Server von Firma 1 gehostet wird.
Entsprechend werden auch AD-Accounts bei Firma 1 angelegt.

Das Autodiscover funktioniert soweit mittels SRV-Record korrekt.
Man muss zwar logischerweise im Outlook, beim Anlegen seines neuen Profils, alle Daten händisch eingeben, aber das ist ja m.E. in dem Fall normal.

So, jetzt zum Problem

Einige MA's von Firma 2 bekommen einen 2. Mailaccount (AD-User) mit einer anderen E-Mail-Domain, für welche ebenfalls der Exchange Server von Firma 1 zuständig ist.
Die MA's bekommen mit ihrem AD-Account von Firma 1 Vollzugriff auf die 2. Mailbox (welche ja ebenfalls bei Firma 1 liegt).
Allerdings taucht die 2. Mailbox nicht automatisch in Outlook bei den entsprechenden MA's auf.

Die "Test E-mail AutoConfiguration"-Funktion von Outlook läuft soweit ohne Fehler durch.
Sprich im XML-Tab steht die 2. Mailbox unter "Alternative Mailbox". Auch im AD-Objekt steht der AD-Account unter "msExchDelegateListLink"

Wenn ich das ganze nun mit einem Test-User von Firma 2 auf einem Test-Notebook von Firma 1, welches auch Mitglied der AD von Firma 1 ist, ausprobiere klappt alles ohne Probleme.

Ich hoffe ich hab das einigermaßen verständlich geschrieben

Jemand eine Idee warum die 2. Mailbox auf den Clients von Firma 2 nicht auftaucht??

VG
Marcel

PS: Ja, ich weiß das die Situation nicht optimal ist, aber daran kann ich im Moment nichts ändern ... ausserdem wärs ja sonst auch langweilig ;-)))

Zitat von NorbertFe

Du versuchst Kalender abzurufen, das geht aber nicht.

Naja, es geht schon, nur wird der Inhalt von privaten Terminen für nicht beteiligte Personen dargestellt (über EWS). (Und MS mag das nicht fixen ;-))
Das war der Ausgangspunkt von diesem Post

Zitat von NobbyausHB

Moin,

wäre es nicht eine Möglichkeit, den Kalender den anderen Leuten direct per ics Link zur Verfügung zu stellen?

Dazu muss man einmal am Server eine globale Einstellung machen und dann kann jeder User seinen Kalender mittels
OWA selber freigeben und die Rechte setzen.

Alles anzeigen

Danke für den Tipp.
Ich probier das mal aus.

Zitat von NorbertFe

Naja, einmal wird "Free Busy" abgefragt und einmal Kalenderdaten. Und ich könnte mir vorstellen, das beides grundsätzlich per Webservice abrufbar ist. Bin aber auch kein Entwickler.

Glaub ich jetzt eher nicht.
Der erste Schritt den z.B. das PS-Script macht ist zu versuchen sich mit dem Kalender-Ordner des anderen Benutzers zu verbinden, und das schlägt dann fehl mit dem erwähnten Fehler.

Was ich jetzt so gelesen habe im großen weiten Internet ist, das man "Leserechte" benötigt um über EWS Kalender-Informationen zu bekomen.
Und so wie ich das verstanden habe hat man diese Leserechte erst ab Reviewer.

Zitat von NorbertFe

Schade ist eigentlich, dass Lightning nicht mit "weniger" Rechten klarkommt. Da solltest du ansetzen und nicht darauf setzen, dass ein MAPI Flag von Webservices ausgewertet wird.

Das ist kein Lightning Problem sondern ein EWS Problem.
Der Fehler kommt ja vom EWS.

Ich kann das alles auch mit einem kleinen PS-Script nachstellen.

LimitedDetails hab ich schon ausprobiert.
Es verhält sich dann aber so, dass der EWS sagt das der Order nicht existiert (The specified folder could not be found in the store).
Dieses Verhalten bekomme ich mit AvailabilityOnly & LimitedDetails.
Das heißt sowohl Lightning, als auch z.B. Evolution können dann keine Exchange Kalender von anderen Personen anzeigen.

Erst wenn man das wieder umstellt auf (mindestens) Reviewer sieht man Kalender von anderen Personen.

Ich pers. finde es ein bischen schade dass EWS das Handling des "private"-Flag den Clients überlässt und einfach alle Termin-Infos rausschickt.