Beiträge von exocheck

Hi,

wenn du intern ein von Exchange selbst ausgestelltes Serverzertifikat verwendest, dann musst du es auf jedem zugreifenden Client in die Liste "Vertrauenswürdige Stammzertifizierungsstellen" aufnehmen.

Auf dem Server selbst funktioniert es schon, denn bei Erzeugung des Zertifikats nimmt er dieses natürlich in seinen eigenen Zertifikats-Store auf und selbstverständlich "vertraut er sich selbst"

Also:
Speichere das Zertifikat als *.cer Datei und importiere dies dann in eine Gruppenrichtlinie, die alle Clients deiner Windows-Domäne erhalten. Und zwar unter:

Computerkonfiguration - Richtlinien - Windows-Einstellungen - Sicherheitseinstellungen - Richtlinien öffentlicher Schlüssel - Vertrauenswürdige Stammzertifizierungsstellen

Rechtsklick - Importieren - die gespeicherte CER-Datei des Exchange auswählen

Siehe auch:
http://www.gruppenrichtlinien.…el/zertifikate-verteilen/

Dort unter:
b) Verteilung des Zertifikats mittels Gruppenrichtlinie

mfg, exocheck

Hi,

meinst du, der Vollzugriff klappt nicht oder nur die automatische Einbindung im Outlook (das sogenannte Auto-Mapping)?

Wenn du in der Konsole oder in der Shell (Add-MailboxPermission) Vollzugriff auf eine Mailbox für einen User vergibst, dann fügt Exchange u.a. dem AD-Attribut "msExchDelegateListLink" der Mailbox den DN (distinguishedName) des berechtigten Users hinzu.
Gleichzeitig wird bei dem berechtigten User im Attribut "msExchDelegateListBL" (ein sog. AD-Backlink) der DN der Mailbox hinzugefügt.
Diese AD-Attribute veranlassen dann Outlook (über die Autodiscover-Funktion), die entsprechende Mailbox automatisch einzubinden.

Bei Gruppen funktioniert dies nun nicht (by design). Wäre auch aufwendig, da sich Gruppen ja laufend ändern können (Mitglieder hinzu/weg) und Exchange müßte die Attribute ständig aktualisieren.

Es gibt wohl im Netz diverse Ansätze, um dies zu "teilautomatisieren", also z.B. die Mitglieder der berechtigten Gruppe(n) auszulesen (Get-DistributionGroupMember) und deren DNs dann per Script in die entsprechenden Attribute zu schreiben. Naja, sollte man aber genau aufpassen, was und wie man das macht... Und sie würden ja auch nicht automatisch entfernt, wenn man die Rechte der Gruppe wieder wegnimmt -> Verwirrung ist die Folge.

Ich sage den Leuten bei Gruppenberechtigungen lieber, bindet euch die Mailbox selber im Outlook ein

PS:
Bei Add-MailboxPermission in der Shell gibt es übrigens auch den Parameter "–AutoMapping $false" um diese Automatik zu verhindern, falls nicht gewünscht.

mfg, exocheck

Man kann auch den Zeitplan der OAB-Aktualisierung nach eigenen Wünschen anpassen (z.B. mehrmals am Tag).
Zu finden in der Exchange Verwaltungskonsole unter "Organisationskonfiguration - Postfach - Offlineadressbuch".

Ach und... Vielleicht auch mal im Ereignisprotokoll nachschauen, ob da Fehler bezüglich der Offlineadressbuch-Aktualisierung zu finden sind.

mfg, exocheck

Nachfrage:
Ich lese gerade "öffentlichen Ordner"... Geht es etwa um einen Kontakteordner in der Öffentlichen Ordnerstruktur (Public Folders)?
Dann hätte es natürlich nix mit dem Adressbuch zu tun...

Hi,

deine Outlook 2010 Nutzer werden wohl im Cache-Modus arbeiten (und greifen auf das von Outlook heruntergeladene Offline-Adressbuch zu) während die Terminalserver-User sicher im Online-Modus arbeiten (also direkt mit der globalen Adressliste).

Entweder das auf dem Exchange Server veröffentliche Offline-Adressbuch ist nicht aktuell (er aktualisiert das IMHO normalerweise nur einmal täglich in der nächtlichen Wartung) und Outlook lädt das OAB auch nur einmal pro Tag (irgendwann nach Outlook-Start) herunter.

Aktualisierung des OAB auf dem Server:

Get-OfflineAddressBook | Update-OfflineAddressBook

Verteilung:

Get-ClientAccessServer | Update-FileDistributionService -type OAB

Dann im Outlook:
Senden/Empfangen - Senden-Empfangen-Gruppen - Adressbuch herunterladen...

mfg, exocheck

Du schreibst, daß du dazu die gegenteilige Einstellung gefunden hast? Welche denn?

Meinst du den DWORD-Wert "DeleteFromServer" in diesem Schlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer\Network\POP3Connector

Wie wär's, wenn du den entsprechenden Eintrag genau umkehrst? Die Logik sagt mir, daß der Wert 1 die Mails löschen sollte.

PS: Ich selbst kenne mich mit dem POP-Connector nicht aus. Nie genutzt.

mfg, exocheck

Hast du denn nun die "Automatischen Weiterleitungen" überhaupt aktiviert oder nicht?

Abfrage:
Get-RemoteDomain | fl name,a*

Ist "AutoForwardEnabled" True? Wenn nicht, dann:

Set-RemoteDomain NAME –AutoForwardEnabled $true

Wobei NAME wahrscheinlich "Default" sein sollte.

PS: Und solange nur an "fremde" Maildomains weitergeleitet werden soll stellt sich die Frage nach irgendwelchen "Relay Domains" u.ä. nicht.

mfg, exocheck

Hi,

irgendwann von Ex2003 migriert? Dabei hatte ich damals auch ein paar dieser defekten Ordner-Objekte.

Geh in die AD-Benutzerverwaltung und aktiviere "Ansicht - Erweiterte Features". Dann siehst du die OU "Microsoft Exchange System Objects". Dort sind u.a. die AD-Objekte für die mailaktivierten öff. Ordner zu sehen (aber leider keine Eigenschaften).

Am besten, nochmal den betreffenden Ordner "Mail-deaktivieren". Dann sollte das ihm zugeordnete AD-Objekt normalerweise verschwinden. Das tut es in diesem Fall wahrscheinlich nicht (und behält diese "versteckte" Adresse im proxyAddresses-Multistring - anzeigbar z.B. mit dem ADExplorer von Sysinternals).

Egal, entferne einfach dieses "kaputte" Objekt in der AD-Benutzerverwaltung (keine Angst, der eigentliche öff. Ordner ist davon nicht betroffen).

Dann den Ordner wieder im Exchange mailaktivieren. Nun sollte das Objekt auch wieder erscheinen und "korrekt" sein.

mfg, exocheck

Hi,

ich kann nur sagen, dass ich hier u.a. einen Server 2012 (also mit Powershell 2 und 3) habe und Exchange 2010 SP3 (alle RUs) problemlos läuft. Ist ja auch offiziell supportet.

Wie RobertW schon sagte, nutzt Exchange dabei die Powershell 2.

Einen "Schönheitsfehler" gibt es: Out-GridView funktioniert nicht mehr in der Powershell 2 (also auch nicht in der EMS). Ist bekannt und wohl "by design".

Allerdings habe ich keine Erfahrung mit nachträglicher Installation des WMF 3 z.B. auf Server 2008.

Nachtrag:
Beim Download des WMF 4 steht sogar die Unterstützung von Ex2010 SP3 mit Update Rollup 5 explizit drin. Siehe unter System Requirements:
http://www.microsoft.com/en-US…oad/details.aspx?id=40855

mfg, exocheck

Hi,

das ist wohl ein Bug, der irgendwann behoben werden soll. Siehe:

"ObjectClass: Unknown" is returned when you use the Get-MailboxStatistics cmdlet

Du könntest aber vorher mit get-mailbox filtern, z.B. sollte sowas in der Art gehen:

Get-Mailbox -Server name -RecipientTypeDetails UserMailbox | Get-MailboxStatistics

mfg, exocheck

Doch-doch, OST-Dateien gibt es schon seit Outlook 97.

Ansonsten gilt natürlich, was ihr vorgeschlagen habt: OST-Datei umbenennen/entfernen.

mfg, exocheck