Hope This Helps

Problem : Ich möchte das Automapping eines freigegebenen Postfaches bei einem Outlook Client verhindern. Normalerweise ja echt kein großer Akt doch leider habe ich bei den Befehlen

Remove-MailboxPermission -Identity user@company.box -User adminuser@company.box -AccessRights FullAccess
Add-MailboxPermission -Identity user@company.box -User adminuser@company.box -AccessRights Fullaccess -AutoMapping $false

immer nur timeouts bekommen. Deswegen musste ich einen anderen Weg gehen.

Lösung :
Einmal kurz auf den Domaincontroller und Active Directory Benutzer und Computer öffnen. Die Ansicht auf "Erweiterte Features” stellen ! Dann habe ich die Eigenschaften des Benutzers user@company.box geöffnet und in den Reiter “Attribut-Editor” gewechselt. Hier habe ich den Key “msExchDelegateListLink” gesucht und manuell die Zuordnung auf adminuser@company.box entfernt

Skript zum Abfragen der Mitglieder in einer dynamischen Verteilerlisten:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
$DDL = “Name-der-Verteilerliste”
Get-DynamicDistributionGroup $DDL | ForEach {Get-Recipient -RecipientPreviewFilter $_.RecipientFilter -OrganizationalUnit $_.RecipientContainer} | Select DisplayName,PrimarySMTPAddress | Format-Table 

Hinweis: Die erste Zeile braucht man nur, wenn das Powershell-Skript außerhalb der Exchange-Powershell laufen lässt. Diese lädt die Exchange-Verwaltungsmodule!

Problem:
Nachdem ich einen externen Benutzer von Exchange 2007 auf Exchange 2013 umgezogen hatte, hat dieser die Öffentlichen Ordner nicht mehr angezeigt bekommen. Der Zugriff erfolgt in der Migrations-Phase über die Discovery-Mailbox-Methode auf den Exchange 2007 (Erklärung siehe TechNet-Quelle unten). Von den intern Outlook-Clients funktioniert der Zugriff problemlos.
Nach einiger Recherche mittels Fiddler habe ich herausgefunden, dass bei dem Client ein zweiter Autodiscover läuft und hier auf die interne Domäen abgefragt wird (https:\\autodiscover.domäne.intern/autodiscover/autodiscover.xml).
Warum der zweite Autodiscover?

Lösung:
Des Rätsels Lösung ist ganz einfach. Dadurch, dass der Client auf die alten Öffentlichen Ordner auf dem Exchange 2007 über das Discovery-Postfach zugreift, läuft für dieses Postfach ebenfalls noch ein Autodiscover. Da ich dem Discovery-Postfach keine öffentliche Mail-Adresse zugewiesen habe (warum auch??), versucht der Client mittels Domäne der primärer Mail-Adresse (die ja intern ist) auf die Autodiscover-URL zuzugreifen (Erklärung wie der Client die Autodiscover-URL ermittelt finden Sie unten in den Quellen).

Die Lösung ist simpel:
Vergeben Sie der Public-Folder-Discovery-Mailbox eine öffentliche Mail-Adresse als Primäre Mail-Adresse und das Autodiscover wird vom externen Client erfolgreich sein.

Quellen/Hilfen:
Hope-This-Helps: Exchange Autodiscover: Wie wird die Autodiscover-URL ermittelt?

https://technet.microsoft.com/de-de/library/dn690134(v=exchg.150).aspx

Problem:
Für mich hat sich die Frage gestellt, wie der Outlook-Client (gerade außerhalb der Organisation über Outlook Anywhere) den Autodiscover FQDN bekommt, die er anfragt um seine Autodiscover-Informationen zu bekommen.

Lösung:
Der Outlook-Client geht hier nach einem fest definierten Schema vor, dass man wissen sollte, da man sonst nicht versteht, warum der Client keine Autodiscover-Informationen erhält.

WICHTIG VORWEG: Als Mail-Domäne nimmt der Client nicht die Windows-Domäne sondern die Mail-Domäne der PRIMÄREN Mail-Adresse des Benutzers
Das kann Probleme machen, wenn man einem Benutzer nur eine interne Mailadresse gibt oder dieser verschiedene externe Mail-Adresse zugewiesen bekommen hat. Vor allem, wenn der Benutzer per Outlook Anywhere zugreift und keinen SCP erreichen kann und somit die Autodiscover-URLS abklappert.

Folgenden Ablauf durchläuft der Client für das Autodiscover-Ermittlung:
1.) Abfrage SCP (Service Connection Point) aus dem AD (ClientAccessServer AutodiscoverServiceInternalURI)
2.) Anfrage auf https://mail-domäne/autodiscover/autodiscover.xml
3.) Anfrage auf https://autodiscover.mail-domäne/autodiscover/autodiscover.xml
4.) Anfrage auf http://autodiscover.mail-domäne/autodiscover/autodiscover.xml
5.) Abfrage eines SRV-Records
6.) Verwendung der lokalen autodiscover.xml, soweit bereits vorhanden

Quelle: SebastianHetzel.net: Exchange Autodiscover

Problem:
Ich musste ein bereits migriertes Postfach vom Exchange 2013 auf den Exchange 2007 zurück verschieben.
Die Migrationsbatch wurde erzeugt, lief aber niemals los.

Lösung:
Aus mir leider nicht ganz verständlichen Gründen, muss man die erste Migration des Postfaches ZUM Exchange 2013 in der Migrationsübersicht löschen und danach ist eine Rückmigration problemlos möglich.
Sie können diese Löschen in der ECP-Website unter "Postfach" -> "Migration".
Hier die entsprechenden Batches des Postfaches suchen und alle löschen.
Nach der Löschung (kann etwas dauern - immer wieder aktualisieren) kann das Postfach auf den alten Exchange verschoben werden!

Problem:
Während meines Exchange-Server-Swings habe ich temporär ein zweites SAN-Zertifikat benötigt und wollte ein öffentliches haben, da sonst die Smartphones über ActiveSync Probleme machen!

Lösung:
Ich habe bei StartSSL ein kostenloses SAN-Zertifikat bekommen. Der Vorteil für mich, gegenüber von Let'sEncrypt", das Zertifikat ist ein Jahr gültig (nicht nur 3 Monate) und ich konnte eine CSR-Anfrage von meinem Exchange "reinkippen".

Nachteil:
Das Zertifikat ist nur ein Jahr gültig und wird von Apple als unsicher eingestuft (Nicht verwunderlich). Der Internet Explorer hat das Zertifikat als valid eingestuft, da hier noch die Root-CA als vertrauenswürdig gilt.

Als temporäres OWA- und SMTP-SAN-Zertifikat hat es für mich gereicht und hat auch super geklappt!

Franky hat hier eine super tolle Anleitung dazu gemacht (Wie immer!!): Frankys Web: Kostenlose SAN-Zertifikate auch bei StartSSL

...und StartSSL findet Ihr hier: StartSSL.com