Mailboxen automatisch einbinden / AutoMapping / msExchDelegateListLink

  • Hallo zusammen,


    wir lieben unsere User und möchten ihnen daher auch komfortabel die Mailboxen zur Verfügung stehen, die sie für ihre Arbeit benötigen. Während der Migrationsphase von unserem bisherigen Mailsystem haben wir daher zunächst (auch dank großer Unwissenheit) den Benutzern auf die sog. Funktionsmailadressen wie z.B. support@domain.tld Vollzugriff gewährt. Das war eine unheimlioch praktische Sache, da die User a) automatisch genug Rechte hatten und b) die Funktionsmailadressen so auch automatisch im Outlook 2007 erschienen sind.


    Das haut natürlich jedwedes Berechtigungskonzept voll über den Haufen. Also wird der Vollzugriff wieder gestrichen und die Berechtigungen manuell mittels ExFolders vergeben und durchgedrückt.


    Feine Sache, bis auf die Tatsache, dass die Mailboxen jetzt nicht mehr automatisch in den MAPI Profilen der Benutzer erscheinen. Und da einige bis zu 10 Funktionsmailadressen benötigen, die sie dann immer manuell einrichten müssten wenn sie den Arbeitsplatz wechseln (keine Roaming Profiles) ist das ein ziemlicher Aufwand.


    Also habe ich mir angesehen warum die Mailboxen beim setzen des Wertes "Vollzugriff" automatisch eingebunden werden. Das hängt mit dem AD Attribut msExchDelegateListLink der jeweiligen Mailbox zusammen. Die Dort aufgeführten Benutzer in kompletter LDAP Schreibweise ( CN=Vorname Nachname,OU=Team,OU=Division,OU=Company,DC=Domain,DC=TLD ) erhalten automatisch die jeweilige Mailbox eingebunden.


    Siehe auch http://www.frankysweb.de/?p=673


    Somit habe ich mittels ADSI Editor das Problem technisch schon einmal gelöst, finde es aber noch recht unschön von der Handhabung her, zumal ich die Kompletten namen immer per Hand eingeben muss, oder aber vorher erst die entsprechende OU exportieren in eine Textdatei, diese dann öffnen, Namen rauskopieren usw.


    Kennt jemand eine elegantere Methode / ein Tool wie sich diese Aufgabe bewältigen lässt? Ich fasse noch einmal die Eckdaten zusammen:


    - Exchange 2010 SP3 Rollup 2
    - Anlegen einer Funktionsmailadresse (Neues Postfach erstellen und AD-Konto deaktivieren)
    - Berechtigungen setzen für "Top of Information Store und Free Busy Data)
    - Automapping für die berechtigten Benutzer aktivieren (msExchangeDelegateListLink)
    - Outlook 2007


    Gruß, MTheis

    • Offizieller Beitrag

    Moin,


    eine elegantere Methode gibt es nicht. Früher oder später wirst Du mit Deinem Konstrukt eh in Probleme laufen, speziell, wenn die Funktionspostfächer etwas größer werden. Dann gibt es so lustige Effekt wie Ordner, die ein User anlegt, die bei anderen aber nicht zu sehen sind (faktisch sind sie nur auf seinem Rechner) oder Elemente, die nicht mehr synchronisiert werden.


    Du kannst die Berechtigungen auf via EMS vergeben und in diesem Zusammenhang auch das AD-Attribute via Shell setzen. Ist nicht so aufwendig und in der Shell hast Du alle Infos (den DN des Users) eh im direkten Zugriff.


    Mit ein wenig Basteln bekommt man darüber auch halb- oder vollautomatische Anpassungen hin.

  • Zitat


    RobertW schrieb:


    Früher oder später wirst Du mit Deinem Konstrukt eh in Probleme laufen


    Du kannst die Berechtigungen auf via EMS vergeben und in diesem Zusammenhang auch das AD-Attribute via Shell setzen. Ist nicht so aufwendig und in der Shell hast Du alle Infos (den DN des Users) eh im direkten Zugriff.


    Hallo Robert,


    danke für die schnelle Antwort. Welcher Teil meines Konstruktes wird das Problem verursachen? Kann ich das ganze sauberer umsetzen, dass ich keine Probleme zu erwarten habe?


    Für die Scripting Geschichte mit dem AD-Modifay werde ich mir wohl mal PowerGUI von Quest ansehen... dürfte nen Powershell Beginner entsprechend unterstützen. Zumal ich vermutlich auch noch das eine oder andere zusätzliche CMDlet wie Set-QADUser gebrauchen kann.


    Gruß, MTheis

    • Offizieller Beitrag
    Zitat


    danke für die schnelle Antwort. Welcher Teil meines Konstruktes wird das Problem verursachen?


    Alles. Outlook stellt sich irgendwann zickig an, wenn die Daten nicht sauber gecacht werden, was sie bei einzelner Ordnereinbindung nicht erfolgt. Gleiche Probleme gibt es irgendwann auch bei "normal" eingebundenen Postfächern.


    Zitat


    Kann ich das ganze sauberer umsetzen, dass ich keine Probleme zu erwarten habe?


    Ich habe bisher nur eine echte, saubere und dauerhaft funktionierende Lösung gefunden: Vollzugriff, Automapping aus und das Funktionspostfach als echtes zusätzliches Exchange-Postfach einbinden. Geht aber erst ab Ol 2010.


    Outlook und Exchange sind halt kein Workflow-System und der Zugriff auf andere Postfächer dient der Vertreter, nicht der intensiven Arbeit.


    Zitat


    Für die Scripting Geschichte mit dem AD-Modifay werde ich mir wohl mal PowerGUI von Quest ansehen... dürfte nen Powershell Beginner entsprechend unterstützen. Zumal ich vermutlich auch noch das eine oder andere zusätzliche CMDlet wie Set-QADUser gebrauchen kann.


    Quest-Tools brauchst Du nicht unbedingt, sie schaden aber nicht. Die GUI ist aber nur ein besserer Editor. Um richtig in der PowerShell zu arbeiten, braucht man das Grundlagen-Wissen, wie die Shell funktioniert (was komplett anders ist, als andere Scripting-Sprachen und eher einer echten Programmsprache ähnelt).


    Ohne das Wissen, was Objekte sind, wie man an die Eigenschaften rankommt und wie man sie richtig verwendet, wirst Du kein Spaß haben. Dann solltest Du zuerst mit einem guten Buch oder einem Kurs beginnen.

  • Zitat


    RobertW schrieb:
    Alles. Outlook stellt sich irgendwann zickig an, wenn die Daten nicht sauber gecacht werden, was sie bei einzelner Ordnereinbindung nicht erfolgt. Gleiche Probleme gibt es irgendwann auch bei "normal" eingebundenen Postfächern.


    Motivation ist nicht so deine Stärke, oder? ;) Wir haben Caching deaktiviert (außer Notebooks) und die Mailboxgrößen beschränkt in der Hoffung dem damit etwas entgegensetzen zu können.


    Zitat


    Ich habe bisher nur eine echte, saubere und dauerhaft funktionierende Lösung gefunden: Vollzugriff, Automapping aus und das Funktionspostfach als echtes zusätzliches Exchange-Postfach einbinden. Geht aber erst ab Ol 2010.


    Das mit OL2010 ist uns "leider" bekannt. Allerdings ist der Grund nicht schwerwiegend genug, dass ich Gelder für ein Update auf 2010/2013 bekommen würde. Das muss leider warten.


    Die Sache mit dem Vollzugriff macht mich stutzig, denn damit hast du doch 2 weitere Probleme. Erstens hebelst du damit das komplette Rechtemanagement aus und zweitens war es nicht so, dass wenn du "FullAccess" und "Send As" vergibst der Server da automatisch ein "Send on behalf of" daraus macht?


    Zitat


    Outlook und Exchange sind halt kein Workflow-System und der Zugriff auf andere Postfächer dient der Vertreter, nicht der intensiven Arbeit.


    Da hast du leider recht. Aber das ständige Outlook schliessen, wieder öffnen und in einem anderen MAPI Profil anmelden macht die User nicht gerade glücklicher.


    Zitat


    Ohne das Wissen, was Objekte sind, wie man an die Eigenschaften rankommt und wie man sie richtig verwendet, wirst Du kein Spaß haben. Dann solltest Du zuerst mit einem guten Buch oder einem Kurs beginnen.


    Kurs ist für Q1/2014 geplant :)


    Gruß, Michael

    • Offizieller Beitrag
    Zitat


    Motivation ist nicht so deine Stärke, oder? ;) Wir haben Caching deaktiviert (außer Notebooks) und die Mailboxgrößen beschränkt in der Hoffung dem damit etwas entgegensetzen zu können.


    Die Realität ist halt manchmal ernüchternd.


    Größenbegrenzungen sind eine Sache, die man im Unternehmen festlegen muss und solange das praktikabel bleibt, auch ok.


    Cache Mode deaktivieren hat aber eigentlich nur Nachteile, solange man nicht auf einem TS arbeitet. So steigen z.B. die Server- und Storage-Anforderungen massiv und das, was man vermeindlich beim Client spart, zahlt man doppelt und dreifach in performante Server ein.


    Zitat


    Das mit OL2010 ist uns "leider" bekannt. Allerdings ist der Grund nicht schwerwiegend genug, dass ich Gelder für ein Update auf 2010/2013 bekommen würde. Das muss leider warten.


    Es gibt zwar noch ein paar andere nette Verbesserungen, aber das mit den mehreren Exchange-Konten ist das Killer-Feature ab Ol 2010.


    Zitat


    Die Sache mit dem Vollzugriff macht mich stutzig, denn damit hast du doch 2 weitere Probleme. Erstens hebelst du damit das komplette Rechtemanagement aus


    Definiere "Rechte"! In den meisten Firmen sieht das so aus, dass die Leute mit dem Funktionspostfach arbeiten sollen. Und echtes Arbeiten geht halt nur mit Vollzugriff.


    Zitat


    und zweitens war es nicht so, dass wenn du "FullAccess" und "Send As" vergibst der Server da automatisch ein "Send on behalf of" daraus macht?


    Definitiv nicht. "Send As" und "Send an behalf" sind zwei unterschiedliche Dinge. Man darf zwar nicht beides Konfigurieren, aber einzeln funktionieren sie wie erwartet.

  • Zitat


    RobertW schrieb:


    Definiere "Rechte"! In den meisten Firmen sieht das so aus, dass die Leute mit dem Funktionspostfach arbeiten sollen. Und echtes Arbeiten geht halt nur mit Vollzugriff.


    Da sind wir bei dem Punkt. Wenn ich Vollzugriff gebe, können die MA selbst die Berechtigungen und Freigaben innerhalb der Mailbox ändern. Nach unseren Richtlinien dürfen solche Änderungen aber nur schriftlich nach Genehmigung der jeweiligen Abteilungsleitung erfolgen. Diese Genehmigungen gehen an die IT, werden umgesetzt und entsprechend abgeheftet. Wir werden alle 1 - 2 Jahre extern stichprobenartig kontrolliert, ob die Berechtigungen im System mit denen der schriftliche fixierten übereinstimmen.


    Zitat


    Definitiv nicht. "Send As" und "Send an behalf" sind zwei unterschiedliche Dinge. Man darf zwar nicht beides Konfigurieren, aber einzeln funktionieren sie wie erwartet.


    Ich bezog mich auf diese Aussage hier:


    http://blogs.technet.com/b/ehl…nd-on-behalf-send-as.aspx


    Gruß, Michael


    P.s. Zum Thema Vollzugriff werde ich gleich noch einen anderen Thread eröffnen, da das dortige Problem nicht ganz in diesen Thread passt

    • Offizieller Beitrag
    Zitat


    Da sind wir bei dem Punkt. Wenn ich Vollzugriff gebe, können die MA selbst die Berechtigungen und Freigaben innerhalb der Mailbox ändern. Nach unseren Richtlinien dürfen solche Änderungen aber nur schriftlich nach Genehmigung der jeweiligen Abteilungsleitung erfolgen. Diese Genehmigungen gehen an die IT, werden umgesetzt und entsprechend abgeheftet. Wir werden alle 1 - 2 Jahre extern stichprobenartig kontrolliert, ob die Berechtigungen im System mit denen der schriftliche fixierten übereinstimmen.


    Mit Exchange kannst Du die Änderungen nur protokollieren.


    Zitat


    Ich bezog mich auf diese Aussage hier:


    http://blogs.technet.com/b/ehl…nd-on-behalf-send-as.aspx


    Du sagtest: " dass wenn du "FullAccess" und "Send As" vergibst der Server da automatisch ein "Send on behalf of" daraus macht?"


    Also: Send As soll zu Send on Behalf werden.


    Im Artikel ist aber genau vom umgekehrten Fall die Rede: "...You would expect that User C receives an Email from “User B on behalf of User A ... This means that User B actually Sent an Email As User A."


    Aus "Send on behalf" wurde also "Send As." Und es ist dort auch beschrieben, wie so das so ist -> weil der Benutzer über Vollzugiff quasi zum Inhaber wurde und als dieser fungiert. Dies Verhalten ist IMHO auch in 2013 so enthalten.


  • Jepp genau, ich hatte das verwechselt und zu dem Zeitpunkt den Artikel nicht mehr gefunden. Ich hatte nur noch im Kopf, dass in einer Konstellation mit FullAccess aus der einen Variante automatisch die andere wird ;)

    • Offizieller Beitrag

    OK. Ja, das ist so. Wenn man Fullzugriff hat, reicht es aus, OWA zu starten und man kann auch unter dem Namen des anderen Users senden. In dem Augenblick ist man quasi der andere Benutzer. Gleiches, wenn man sich ein neues Profil anlegt und dort die fremde Mailbox nimmt.


    Oder anders: "Send As" bedeutet nur, dass ich mit MEINEM Profil für jemand anders senden darf, ohne das Profil ändern zu müssen.