Bubblegum

vor 16 Minuten schrieb NorbertFe:

Ich kann nicht auf deinen Bildschirm gucken. Du müßtest also ggf. etwas ausführlicher oder mit Screenshot usw. arbeiten, damit man das nachvollziehen kann.

Das wäre im Grunde das was du auch auf dem Bildschirm sehen würdest ;)

Auch wenn im Adressformat was eingeben wurde, erscheint es hier nicht.

Was mir aufällt gerade. Bei Typ steht das Adressformat und Adressformat nix.

Ist der Fehler bekannt? - damit würde die Fehlermeldung auch Sinn ergeben.

Erstmal gebe ich im Abschnitt benutzerdefinierten SMTP Adresstyp "SMTP" an und dann unten drunter E-Mail Adressparameter %g.%s.extern@blabla.com

Dann speichern und wieder zurück und dann kommt der Fehler.

Patchstand ist CU20 - Exchange 2013

Scheinbar funktioniert es nicht. Es wird mir angezeigt, auch wenn ich die lokalen Variable verwende und mit .extern ergänze, dass das Email Adresspräfix mehr als 9 Zeichen lang ist und deshalb nicht funktioniert.

bleibt die bestehe Mail Adresse automatisch als alias? - oder muss ich da nochwas tun.

%g.%s.extern@blabla.com - das als richtlinie mit dem recipientcontainer angeben und thats it?

vor 14 Minuten schrieb ASR:

Ja, mach einfach eine neue RecipientPolicy für die Mailboxen die das bekommen sollen. Die haben bestimmt ein "extern" Attribut das Du verwenden kannst, dann bist Du in 20sec. fertig.

 

ASR

Geht das auch per OU - falls kein Attribut "extern" vorhanden ist?

Nein, es geht nicht um eine neue Domain. Sondern es sollen Mail Adressen von Extern angepasst werden.

Bestehende Mail Adressen bleiben vorhanden und neue Adressen sollen dann vorname.nachnme.extern@blabla.com heißen.

@Dukel Hab ich schon verstanden. Meinte den Inhalt der Adresslisten selbst, weil oben definierst du ja glaub ich DistributionGroups, Securitygroups, Usermailboxen als auch Kontakte, dass der Inhalt in die Adresslist reinkommen.

Das kein matching stattfindet, wegen dem "UND" mit dem Extentend Attribut hab ich verstanden. Aber wenn ich deine Antwort herauslese, kannst du nicht einfach eine leere "Adresslist" herstellen?

@Dukel Bei deiner Vorgehensweise:

#AddressLists
New-AddressList -Name Gaeste01_Mailverteiler -DisplayName "Alle Mailverteiler" -RecipientFilter {((((RecipientTypeDetails -eq 'MailUniversalSecurityGroup') -or (RecipientTypeDetails -eq 'MailUniversalDistributionGroup'))) -and (ExtensionCustomAttribute1 -eq 'G01'))}
New-AddressList -Name Gaeste01_Kontakte -DisplayName "Alle Kontakte" -RecipientFilter {((RecipientTypeDetails -eq 'MailContact') -and (ExtensionCustomAttribute1 -eq 'G01'))}
New-AddressList -Name Gaeste01_Personen -DisplayName "Alle Personen" -RecipientFilter {((RecipientTypeDetails -eq 'UserMailbox') -and (ExtensionCustomAttribute1 -eq 'G01'))}
#RoomList
New-AddressList -Name Gaeste01_Raeume -DisplayName "Alle Räume" -RecipientFilter {((RecipientTypeDetails -eq 'RoomMailbox') -and (ExtensionCustomAttribute1 -eq 'G01'))}
#GlobalAddressList
New-GlobalAddressList -Name Gaeste01 -RecipientFilter {ExtensionCustomAttribute1 -eq 'G01'}
#OfflineAddressBook
New-OfflineAddressBook -Name OAB_Gaeste01 -AddressLists Gaeste01
#Name
New-AddressBookPolicy -Name ABP_Gaeste01 -GlobalAddressList Gaeste01 -OfflineAddressBook OAB_Gaeste01 -RoomList Gaeste01_Raeume -AddressLists Gaeste01_Mailverteiler,Gaeste01_Kontakte,Gaeste01_Personen 

kann man da die Adresslisten nicht auch leer lassen in meinem Fall, ohne das da überhaupt Kontakte hinterlegt werden?

Von der Idee her hätte ich die betreffenden User erstmal als CSV exportiert und dann mittels Import-CSV und for each Schleife die bestehende Adresse als Alias beibehalten und die neue als primary hinzugefügt.

Hält ihr das für die beste Lösung oder gibt es hier bessere Lösungsansätze?

Was mir gerade noch in den Sinn kommt: Falls man "HidefromAdresslist" definiert, würde man in dem Zuge nicht schon den Fall abdecken, dass für die Mitarbeiter die Freelancer nicht einsehbar wären?

@Dukel Käme dann die normale / Standard GAL nicht mehr im Einsatz oder wäre die weitere einfach nur als Filtering zuständig?

@Dukel Das heißt, meine bestehende allgemeine GAL / OAB für die bestehenden Mitarbeiter fasse ich nicht an (also ich ändere da auch nix mit Attributen oder dergleichen).

Danach erstelle ich die Policys und Listen für die Freelancer mit dem Extended Attribute und fülle es bei keinem Nutzer aus.

Und zum Schluss wird diese Policy einfach zugewiesen?

Hab ich damit dann den Effekt:

- Die Mitarbeiter sehen nicht das Freelanceradressbuch

- Die Freelancer sehen nicht das Mitarbeiteradressbuch

- Die Freelancer sehen nicht ihr eigenes Adressbuch (also das Freelanceradressbuch)

Hätte man damit alle Anforderungen abgedeckt?

@Dukel Bevor ich durcheinander komme - fakt ist, es werden aufjedenfall zwei GAL / OABs benötigt. In meinem Fall ist die allgemeine GAL / OAB schon vorhanden für die normalen Benutzer.

Für die Freelancer wird entsprechend eine neue GAL und OAB generiert. Die Freelancer Accounts sind alle in einer eigenen OU.

In deinem Beispiel einige Beiträge vorher, war der Fall so, dass beide verschiedene extension Attribute haben und einfach bei Anlage der Freelancer Accounts dieses Attribut weglassen wird in den Accountattribute, so dass einfach das Adressbuch nicht erscheint und nur die Poliy zugewiesen wird.

Wie geschieht das bei der OU Lösung?

Also im Grunde mit dem gleichen Ergebnis.

Das heißt, solange der AD-Account vom Freelancer das Attribut z.B "G01" nicht gesetzt ist, lässt sich zwar das Gästeadressbuch zuweisen per Policy, aber wird niemals angezeigt.

Der Abschnitt "Personen" bei Dir würde bei mir - mehr oder weniger - wegfallen, da bereits eine GAL und OAB besteht.

Verstehe ich das so richtig?

Was müsste ich bei der OU  statt der Setzunfgdes Attributes beachten?

Dein Abschnitt wo du das Gästeadressbuch erstellst, würde ich ganz normal so machen, nur würde ich statt dem Attribut in irgendeiner Form die OU ins Spiel bringen müssen.

Oder wäre es eleganter einfach bei der bestehenden GAL / OAB, wo derzeit die normalen Benutzer nutzen das extension Attribut nach zu setzen?

@Dukel: Ok, gehen wir mal das Schritt für Schritt durch:

Im ersten Abschnitt "Personen" sind die normalen Benutzer der Organisation. Als Unterscheidungsattribut setzt du da P01.

Im zweiten Abschnitt "Gäste" sind die Gästenutzer der Organisation. Als Unterscheidungsattribut setzt du da G01.

Die Policy für Personen lautet "ABP_Personen01" und für Gäste "ABP_Gaeste01".

Jetzt lege ich im AD einen User an "Freelancer1" innerhalb der OU "externalUser". Diesem User wird eine Mailbox zugeteilt und die Policy "ABP_Gaeste01" im Exchange zugewiesen.

Wo ist der Schritt, dass dieser User nun in seinem Adressbuch nach keinen anderen Freelancer suchen kann bzw. das Adressbuch leer bleibt und sich keiner der User gegenseitig sieht?

Das heißt, wenn man dann weiterdenkt bei der Erstellung von weiteren User, z.B: Freelancer2, Freelancer3 etc..

@Dukel Wenn ich mir deine Umsetzung betrachte, machst du zwar eine separierst du durch das extention Attribute.

Wie lässt sich aber dann lösen, dass du:

a. kein Zugriff zum Durchsuchen von Kontakten haben von z.B anderen Freelancern hast

b. keinerlei Kontakte angezeigt werden

vor 1 Minute schrieb Nobbyaushb:

Dann müsstest du - wie schon geschrieben - für jeden externen eine eigene ABP erstellen - m.E. wenig Zielführend.

 

Der Rest wurde aus meiner Sicht hinreichend erläutert.

Genau, für jeden externen eine eigene ABP zu erstellen macht auch in meinen Augen wenig sinn.

Es sollte dennoch machbar sein, ggf. über ein anderen Weg, dass sich die externen nicht gegenseitig sehen.

Vorzugsweise natürlich mit einem überschaubaren Aufwand

Grundsätzlich ist die Aufteilung in einer OU kein schlechter Ansatz. Diese Aufteilung liegt bei mir schon vor.

Beispiel: Domäne/externalUser

Und das man im Grunde für alle User der OU "external User" dann die Policy anwendet, dass diese in ihre GAL / OAB Zugriff haben.

Der offene Punkt wo ich noch sehe: Sogar wenn die external User OU einer bestimmten GAL zugeordnet sind, wie erreiche ich im Anschluss daran, dass diese:

a. kein Zugriff zum Durchsuchen von Kontakten haben von z.B anderen Freelancern

b. keinerlei Kontakte angezeigt werden

@NilsK Du hast es richtig erfasst. Es geht ebenfalls um User, welche einen AD Nutzer erhalten und als auch eine Mailbox.

Es wäre grundsätzlich zu überlegen, ob man vielleicht das Design für Freelancer, wo im Unternehmen Mailboxen benötigen, anpasst, so dass ausschließlich der Mailboxzugriff auf OWA möglich wäre.

@Dukel Kannst Du dein dargestellten Lösungsweg hier präsentieren, so dass man hier vielleicht bewerten kann, ob das für den Fall anwendbar ist?

Bislang stört mich die Generierung der GAL und OAB. Schlussendlich soll nicht jeder Nutzer oder eine bestimmte Usergruppe ein verfügbares Adressbuch haben, sondern einfach nicht auf das interne Adressbuch zugreifen können.

Wenn es nicht anders machbar ist, wie erreiche ich zumindest, dass der Zugriff so limitiert wird, dass weder eine Durchsuchung im neuen Adressbuch, noch Anzeige dessen möglich ist.

So dass, sich die neuen User nicht gegenzeitig sehen.

vor 1 Minute schrieb Nobbyaushb:

Ohne mindestens eine weitere geht das nicht.

Hat NorbertFe aber schon geschrieben, ansonsten siehe link - und meinen Hinweis beachten 

Das wäre echt doof. Aber um nochmals zu dem Beitrag bei Techieshelp zurück zukommen, weshalb schlägt hier die Umsetzung fehl?

Weil diese Umsetzung im Grunde nicht allzu schwer ist. 

Ich wollte folgenden Ansatz machen:

https://www.techieshelp.com/block-users-seeing-exchange-2010-global-address-list-gal-applies-to-exchange-2007-also/

Oder gibt es noch Optionen, so dass ich hier nicht extra eine neue Adressliste erstellen muss?