Beiträge von BitFlip

    Hallo zusammen,
    ich habe in einer gemischten Ex2k3-Organisation den Effekt, dass Stellvertetungen nicht immer konfigurierbar sind.
    ------------------------------------------
    Umgebung:
    EX
    - 1xEx2k3EE SP2
    - 2xMSX5.5EE SP4
    - verschiedene OL-Versionen
    - Postfächer sind bis auf wenige Ausnahmen bereits vollständig auf Ex2k3 verschoben.
    - Free/Busy funktioniert, OAB auch [->Systemordner sind OK]
    - RUS ist OK


    AD
    - Leere Forest-Root
    - 2 produktive Child Domains
    - AD ist OK


    Mein Client [repräsentativer Standardclient]
    - WinXP SP2
    - OL2k3 SP2
    - Verwendetes Benutzerkonto ist KEIN Domänen-/EX-Admin
    ------------------------------------------
    Problemdarstellung:
    Versuche ich, über Extras -> Stellvertetungen Benutzer hinzuzufügen, bekomme ich eine Fehlermeldung wie im Bild. Berechtige ich im AD-Benutzerobjekt über Exchange - Allgemein -> Zustelloptionen den selben Benutzer für "Senden im Auftrag von", funktioniert dies und der Stellvertreter wird mir auch anschliessend im OL angezeigt.
    :-?
    Ok, ich habe gegoogelt und die MS Premier-KB durchforstet. Ergebnis: 0


    Wo kann ich ansetzen, bin ratlos?



    Danke vorab.

    Zitat


    backdoor schrieb:
    Hi BitFlip,


    Leider kann man in den "Internet-Nachrichtenformaten" keine "Zugriffseinstellungen" vornehmen. :-?
    Wo soll mann denn die Berechtigungen einstellen???


    Hi backdoor,
    du hast Recht, es gibt kein explizites Verwaltungsobjekt "Berechtigungen" für die Richtlinie, aber machst du RMT auf die Standardrichtlinie -> Eigenschaften -> Register "Sicherheit" auf, kannst du dort Berechtigungen definieren. Auf diese Weise werden auch Berechtigungen auf andere Exchange-Objekte und -Container vergeben, z.B. für Backupdienste auf Storage Groups etc.


    Wenn es nur um einen oder wenige Benutzer geht, lässt sich das manuell ändern. Dazu muss das AD-Benutzerobjekt umbenannt werden.
    Benutzer auswählen -> RMT -> "Umbennen" auswählen. Irgendeine Änderung durchführen und mit ENTER bestätigen [Es wird noch keine Änderung vorgenommen!]. Dies öffnet den Dialog "Benutzer umbenennen", in dem Alle Benutzernamen geändert werden können. Hier den Anzeigenamen nach Belieben editieren. Dabei bleibt der vollständige Benutzername, wie er im AD angezeigt wird, erhalten, während der Anzeigename in der GAL wie gewünscht angezeigt wird.


    Zitat


    grblzbx schrieb:
    Oooops... sehe gerade, es ist in den Globalen Einstellungen nicht "Nachrichtenübermittlung", sondern "Internet-Nachrichtenformate", dann Rechtsklick auf "Standard", Reiter "Erweitert"... sorry.


    Hmmm, gibt's vielleicht die Möglichkeit, eine zweite Policy für Internet-Nachrichtenformate zu definieren und die Zugriffsberechtigungen zu filtern?? :idea:
    - Standard-Policy: Standardberechtigungen der JEDER-Gruppe als Deny-Berechtigungen für eine zusätzliche Ausnahmegruppe [z.B. "Ohne E-Mailanzeigename"] definieren.
    - Zusätzliche Policy definieren, in der ausschliesslich die Ausnahmegruppe mit den Standardberechtigungen der JEDER-Gruppe berechtigt ist.


    Habe ich zwar noch nicht gemacht, könnte aber klappen, ähnlich wie GPO-Sicherheitsfilterung. Hat vielleicht jemand gerade eine Testumgebung zum Ausprobieren zur Hand?

    Nobby
    Jau, habe ich schon einige Male beobachtet. NT-Administratoren sind historisch bedingt nicht sensibilisiert für Zeitsynchronisierung. Wenn doch, dann nutzen sie einen eigenen NTP-Server [sprich einen Member-Server oder DC mit Funkwecker ;-)] und AT-Jobs/Geplante Tasks auf den Clients. Sobald dann das AD etabliert ist und die Clients dahin migriert sind, sollten die vorherigen Jobs/schedules sofort deaktiviert werden, sonst kann es Probleme geben. Besonders schick ist die Variante mit einem weiteren NTP-Client auf Servern, gerne auf in-place aktualisierten DCs. Ist schön zu beobachten, wenn DCs mit LSA-Fehlern nicht mehr im AD authentifiziert werden. :P

    Wenn ich das richtig verstehe, möchtest du E-Mails für einen Exchange-Empfänger an ein POP3-Postfach auf einem SMTP-Smarthost weiterleiten. Dann sähe eine einfache Lösung so aus:


    Du erzeugst im AD einen Kontakt [externen Empfänger] mit der externen POP3-Postfachadresse.
    Beim AD-Benutzerobjekt mit dem Exchange-Postfach konfigurierst du dann die Weiterleitung an den Kontakt.
    Benutzerobjekt -> Register Exchange - Allgemein -> Zustelloptionen -> Weiterleiten an. Über "Ändern" wählst du den Kontakt aus.
    Somit werden ab sofort alle an den Exchange-Empfänger gesendeten E-Mails an den externen Kontakt weitergeleitet. Zusätzlich kannst du hier einstellen, alle weitergeleiteten Nachrichten als Kopie im Exchange-Postfach zu belassen. Der Benutzer kann dann wahlweise das Exchange- oder POP3-Postfach abrufen und hat in beiden seine Mails.
    Schick an dieser Lösung ist, dass du serverseitig nicht ferkeln musst. :D

    Hi,
    du solltest sicherstellen, dass neben DNS und WINS auch die Zeitsynchronisierung der W2k3-Domäne funktioniert. Über den Windows-Zeitgeberdienst wird die Systemzeit der gesamten Domäne [des gesamten Forests] synchronisiert. Dies geschieht aufgrund der Verwendung von Kerberos als primärem Authentifizierungsprotokoll innerhalb des AD. Kerberos arbeitet auf Basis eines Ticketsystems, wobei Clients bei Serveranfragen ein Ticket vom Server erhalten, welches nur bestimmte Zeit gültig ist. Da es sich hier um zeitkritische Aktionen handelt, müssen die Systemzeiten der beteiligten Maschinen so akkurat wie möglich synchronisiert sein. Dies erledigt der Windows-Zeitgeberdienst automatisch. Dabei darf die Zeitabweichung in der Standardeinstellung maximal 5 Minuten [300 Sekunden] betragen. Weicht die Zeit des Clients weiter ab, wird dem Client nicht mehr vertraut [keine Kerberostickets ausgestellt] und es können solche Effekte wie in deiner Umgebung auftreten.


    1. Voraussetzung für eine funktionierende Zeitsynchronisierung in der Domäne ist die Synchroniserung des PDC-Emulators der Domäne mit einer authoritativen Zeitquelle. Dies kann eine interne [der Server selbst], besser eine externe Quelle sein. Wie das geht liest du hier: http://support.microsoft.com/kb/816042/de
    Eine gute Empfehlung als externe Zeitquelle ist pool.ntp.org, hier die deutsche Zone


    2. Auf den Clients muss der Windows-Zeitgeberdienst gestart sein [Startart: Automatisch]


    3. Willst du mit einer externen Zeitquelle arbeiten [EMPFOHLEN!], muss auf der Firewall eine Portfreigaberegel definiert werden:
    Richtung: beidseitig [rein + raus]
    Port: 123
    Protokoll: UDP
    Hosts intern: IPs aller W2k3-DCs [für den Fall, dass die FSMO PDC-Emulator mal verschben wird. Man vergisst gern die Firewall ;-)]
    Hosts extern: any [oder die Adressen der verwendeten NTP-Server]

    moin Husi,
    zu deiner Frage e):
    Der bunte Logon im OWA heisst "Formularbasierte Authentifizierung" oder önglisch "Forms-based Authentication". Dies kannst du im ESM auf dem virtuellen HTTP-Server deines Servers aktivieren. Allerdings erfordert FBA zwingend Clienstverbindungen über SSL.
    Die Einstellung findest du im ESM hier:
    Administrative Gruppen -> %DEINE ADMIISTRATIVE GRUPPE% -> Server -> %DEIN SERVER% -> Protokolle -> HTTP -> Virtueller Exchange Server -> RMT -> Eigenschaften -> Einstellungen -> Formularbasierte Authentifizierung aktivieren.
    Ist während des Aktivierens der Option SSL nicht auf dem Server konfiguriert, erhältst du eine Warnmeldung.
    Daher solltest du vorab sicherstellen, dass Clients über SSL auf OWA zugreifen können. Dazu musst du ein Zertifikat auf dem Exchange Server einrichten. Dies kannst du recht einfach mit dem Tool SelfSSL aus dem IIS6.0 Resource Kit durchführen. Wenn du ein selbst erstelltes Zertifikat verwendest, erhalten Clients beim Zugriff eine Warnmeldung des Browsers mit dem Hinweis, dass das Zertifikat von einer "nicht vertrauenswürdigen Stammzertifizierungsstelle" ausgestellt wurde. Um diese Warnung zu verhindern, müsste das Zertifikat im "Zertifikatsspeicher für vertrauenswürdige Stammzertifizierungsstellen" der Clients installiert werden. Dann würden die Clientbrowser dem Zertifikat deines Exchange Servers vertrauen. Dann müsstest du den Zugriff per HTTPS von extern freischalten. Allerdings wird aus Sicherheitsgründen NICHT empfohlen, einen direkten Zugriff aus dem Internet auf ein Backendsystem zuzulassen [ist logisch, oder?].


    Alternativ kann das Zertifikat dann z.B. auf einen ISA-Server installiert werden, über den OWA ins Internet veröffentlicht wird. dann würden Clientverbindungen am ISA terminiertund die Verwendung von FBA somit auch möglich.
    Puuh...viel Text woll? :D Ich hoffe das hilft dir trotzdem.

    Die sauberste Vorgehensweise nach meiner Projekerfahrung ist die Verwendung der Bereitstellungstools [Deployment tools] von Ex2k3 in der aktualisierten Fassung vom 21.09.2004 linky. Sofern die Checklisten entsprechend der Vorgaben abgearbeitet werden, kann das Projekt nur noch ein Erfolg werden. ;)