Hope This Helps

Ich hatte folgenden Fehler bei Outlook-User, die eine größere Ordnerstruktur durchsucht haben


Die User bekommen tatsächlich nur 250 Suchergebnisse angezeigt, was jetzt nicht besonders viel ist, wenn man eine ältere Mail sucht!

Ich dachte erste, dass es was mit den MaxObjects zu tun hat und habe daher die MaxObjects für Folder, FolderView, Message und MessageView auf 2000 gesetzt. Heute besteht das Problem weiterhin. Nach etwas Recherche habe ich doch dann tatsächlich einen Eintrag gefunden, der das Problem schildert und löst.
Dieses Einstellung kann erst seit Exchange 2013 CU11 geändert werden und muss aber manuell angepasst werden.

1.) Öffnen Sie die Datei "%ExchangeInstallPath%/Bin/Microsoft.Exchange.Store.Worker.exe.config"
2.) Suchen Sie hier den Schlüssel /runtime
3.) Fügen Sie danach folgende Zeilen hinzu:

<appSettings>
      <add key="MaxHitsForFullTextIndexSearches" value="1000" />
</appSettings>

Hiermit werden die Suchergbnisse auf 1.000 Elemente erweitert.
4.) Starten Sie den Informationsspeicher durch

Damit aber noch nicht genug, da wir hiermit die Beschränkung auf dem Server aufgehoben haben, aber NICHT am Client.
Hier gibt es noch eine Einstellung im Outlook, die die Suchergebnisse ebenfalls beschränkt:

Scheinbar gibt es aber in den Microsoft-GPOs keine Einstellungsmöglichkeit und somit muss man einen RegKey per GPO ausstreuen. Diese Einstellung gibt es aber erst ab Outlook 2013. Hier die RegKeys dazu:

Office 2013: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Search
Office 2016: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search
REG_DWORD “SearchResultsCap” anlegen
Hier den Wert “0” vergeben (Hier kann auch der gleiche Wert wie auf dem Server eingetragen werden)

Ein scheinbar kleines Problem hat mich gut beschäftigt!

Quelle: somoit: Exchange 2013 – Solved the “Search results limited to 250” bug

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:
Ablauf der PublicFolder-Migration von Exchange 2007 auf Exchange 2013

Lösung:
Hier stelle ich meine Skript-Sammlung und Ablauf-Prozedur für meine Migration da.
Ich habe hier meine öffentliche Ordner von einem Exchange 2007 auf einen Exchange 2013 CU16 erfolgreich migriert.
Dabei gibt es einige Ecken, die man wissen muss, sonst wunder man sich über das Verhalten und die Vorgehensweise.

Vorbereitung:
- Laden Sie sich die Public Folder Migration Scripts von Microsoft herunter (Link finden Sie unten bei den Quellen)
- Kopieren Sie die Skripte auf den alten und neuen Exchange-Server unter "C:\PFMigration\"
- Notieren Sie sich die FQDN des alten und neuen Exchange-Servers
- Sie benötigen einen Exchange-Administrator-Konto
- Alle Postfächer sind bereits auf dem Exchange 2013 migriert
- Es wird eine Downtime für die öffentlichen Ordner geben!
- Holen Sie sich eine Kanne Kaffee, das Szenario kann etwas dauern

Ablauf:

--- START AUF EXCHANGE 2007 ---

1.) Snapshot der "alten Public Folders"
Mit dem nachfolgendem Befehl wird ein Snapshot der PublicFolder-Struktur (Ordner, Struktur und Berechtigungen) angefertigt.

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

2.) Prüfen der Struktur
Mit diesem Befehl werden die Ordner-Namen nach "\" im Namen, da diese nicht migriert werden können und der Prozess hier dann abbricht. Vorher müssen alle entsprechenden Ordner in der alten Struktur umbenannt werden.

Get-PublicFolderDatabase | ForEach {Get-PublicFolderStatistics -Server $_.Server | Where {$_.Name -like "*\*"}}

WICHTIG: Falls es hier zu Änderungen kommt, muss ein erneuter Snapshot (Punkt 1) erstellt werden!

3.) Migrations-Prüfung
Hiermit prüfen Sie, ob bereits eine Migration läuft und noch nicht abgeschlossen ist.

Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete

4.) CSV mit Ordernamen generieren
Hiermit wird eine CSV mit den Ordnernamen und Größen erstellt

.\Export-PublicFolderStatistics.ps1 PFStat.csv 

5.) PFStat.csv auf Exchange 2013 kopieren
Kopieren Sie die gerade erstellt PFStat.csv auf den Exchange 2013 in das Verzeichnis der Migrationsskripte "C:\PFMigration\"

--- WECHSEL AUF EXCHANGE 2013 ---

1.) Erstellen der nötigen PublicFolder.csv
Hier werden die Anzahl an PublicFolders berechnet und eine CSV für die Erstellung erzeugt.

.\PublicFolderToMailboxMapGenerator.ps1 10GB PFStat.csv FolderToMailbox.csv

2.) Umbenennen der PublicFolder-Mailbox (OPTIONAL)
In der gerade erstellten FolderToMailbox.csv heißt die neue PublicFolder-Mailbox Mailbox1, Mailbox2 etc.
WICHTIG: Man kann diese hier anpassen und muss aber dann auch die nachfolgenden Skripte ebenfalls anpassen!
Bitte beachten: Ich habe diese hier zu "PublicFolder01" umbenannte und meine Skripte daran angepasst.

3.) Neue PublicFolder-Datenbank erstellen
Hiermit wird die neue PublicFolder-Datenbank erstellt und für die Migration reserviert.

New-Mailbox -PublicFolder PublicFolder01 –HoldForMigration: $true

4.) Migration starten
Jetzt den Migrations-Prozess starten

New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server ) -CSVData (Get-Content FolderToMailbox.csv -Encoding Byte)

5.) Migrationsstatus prüfen
Hiermit kann man den Migrationsstatus prüfen und eventuelle Fehler analysieren.
Minimale Ausgabe des Status:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics

Status-Ausgabe mit Details

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

ACHTUNG - WICHTIG: MIGRATION LÄUFT NUR BIS 95% UND STOPPT DANN - DAS IST GEWOLLT!
Solange der Parameter PreventCompletion = true ist, wird die Migration nicht vollständig abschließen

ACHTUNG - AB JETZT GIB ES DOWNTIME DER PUBLIC FOLDERS!
NACH DEM NACHFOLGENDEM SCHRITT GIBT ES KEIN ZUGRIFF MEHR AUF LEGACY PUBLIC FOLDER!

6.) Alte Public Folders sperren für endgültige Migration
Mit dem nachfolgendem Befehl werden die alten öffentlichen Ordner für den Zugriff und die endgültige Migration gesperrt.

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

7.) Freigabe für finale Migration (letzten 5% der Migration)

Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false 

8.) Migration wieder starten
Hiermit wird die zuvor gestoppte Migration wieder gestartet um die letzten 5% abzuschließen.

Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

9.) Prüfen des Migrationsstatus mit Details
Nun müssen Sie die finale Migration überwachen:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

Sollte die Migration nicht abschließen, dann prüfen Sie die Fehlermeldungen in der Detailausgabe. Wenn hier etwas mit „StalledDueToMailboxLock“ oder „Relinquishing job because the mailbox is locked“ zu lesen ist, dann müssen Sie den Informationstore auf dem alten Exchange 2007 einfach durchstarten. Danach können Sie die Migration erneut starten mittels:

Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

Nun sollte alles bis 100% durchlaufen!

10.) Zugriff mit einzelnem Benutzer testen
Um den Zugriff zu testen und nicht gleich alle Benutzer umzustellen verwenden Sie den nachfolgenden Befehl:

Set-Mailbox -Identity TESTUSER -DefaultPublicFolderMailbox mailbox1

11.) Finaler Abschluß der Migration
Erst geben wir den neuen Public Folder für alle frei

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false 

Nun schließen wir noch die Migrationsbatch ab

Set-OrganizationConfig -PublicFolderMigrationComplete:$true

Jetzt setzen wir den neuen Public Folder für ALLE Postfächer

Set-OrganizationConfig -PublicFoldersEnabled Local

12.) Prüfen der Migration
Nun prüfen wir noch, ob die Migrationsbatch auch als abgeschlossen angezeigt wird

Get-OrganizationConfig | FL PublicFolderMigrationComplete

Außerdem prüfen wir noch, ob der Public Folder für andere Benutzer als Default angezeigt wird

Get-Mailbox SOMERANDOMUSER | FL DefaultPublicFolderMailbox

13.) Aufräumarbeiten
Jetzt müssen wir noch den RemotePublicFolder-Eintrag wieder löschen

Set-OrganizationConfig -RemotePublicFolderMailboxes $null

Set-OrganizationConfig -PublicFoldersEnabled Local

14.) Clients testen
Nun ist es Zeit die Clients zu testen. Das kann etwas dauern, bis die neuen PublicFolders angezeigt werden - AD-Replikation!
Bei mir hat es teilweise bis zu 30 Minuten gedauert, bis auch die letzten Clients die öffentlichen Ordner angezeigt bekommen haben!

LETZTER HINWEIS: Sollte der Benutzer öffentliche Ordner als Favoriten eingetragen haben, dann muss er diese wieder neu setzen...leider!

Quellen:
ENOW: Legacy Public Folder Migration – Notes from the Field
MSExchangeGuru.com: Public Folders Migration from Exchange 2007/2010 to Exchange 2013
Microsoft: Download Public Folders Migration Scripts

Problem:
Die Exchange-Konfigurations-Website (https://mailserver.domain.tld/ecp) ist ja sowohl extern als auch intern erreichbar, wenn man nicht den Luxus eines Reverse-Proxy besitzt. Ich habe immer ein etwas schlechtes Gefühl, wenn meine Exchange-Konfiguration von extern erreichbar ist. Vor allem, wenn z.B. ein IT-Kollege im Zorne ausscheidet und alle Passwörter hat und mir dadurch theoretisch die Datenbank einfach löschen könnte. Da ich keinen Reverse-Proxy besitze musste ich eine andere Lösung finden.

Überlegungen:
Es gibt ja die Möglichkeit die ECP-Admin-Webseite abzuschalten, was das Ganze zwar sicher macht, aber auch nicht mehr administrierbar!
Zuerst wollte ich einfach auf dem IIS die "Einschränkungen für IP-Adressen und Domänennamen" aktivieren. Das löst das Problem mit dem externen Zugriff, hat aber den Nachteil, dass die Benutzer über OWA auch nicht mehr Ihr Konto verwalten können um z.B. den Abwesenheitsassistenten zu aktivieren (Teil des ECP). Also...nur begrenzt gut.
Microsoft selbst sagt, dass man einen zusätzlichen CAS-Server aufsetzen soll, der nur intern erreichbar ist und auf dem externen den Admin-Zugang deaktivieren soll. Leider fehlen mir hierzu die Ressourcen und in kleinen und mittelständigen Unternehmen ist das "a little bit too much"

Lösung:
Die Lösung liegt darin, dass man eine neue ECP-Webseite anlegt und diese im IIS auf eine zweite Netzwerkkarte im Exchange bindet. Die IP-Adresse der neuen Netzwerkkarte ist nur intern erreichbar, wohingegen die "alte" Netzwerkkarten-IP extern erreichbar ist.

Folgende Vorgehensweise zur Lösung:
1.) Fügen Sie dem Exchange-Server eine zweite Netzwerkkarte hinzu.

2.) Vergeben Sie eine neue IP-Adresse für diese Karte und deaktivieren Sie "Diese Verbindung im DNS registrieren", damit der Exchange nicht über mehrere IP-Adresse im DNS erreichbar ist.

3.) Tragen Sie im DNS-Server den FQDN für die neue Webseite mit der neuen IP ein (z.B. ecp.demo.local) - das wird später Ihre URL für den Aufruf werden.

4.) Erstellen Sie auf dem Exchange-Server eine neues Verzeichnis "c:\inetpub\wwwroot2"

5.) Erstellen Sie im IIS eine neue Website und verweisen Sie auf den zuvor erstellten wwwroot2-Ordner und benennen Sie diese z.B. als "ECPIntern"

6.) Binden Sie die neu erstellte Webseite mit Port 80 (http) und Port 443 (https) an die neue, interne IP-Adresse

7.) Erstellen Sie ein neues ECP Virtual Directory mit dem folgenden Befehl (bitte entsprechend anpassen):

New-EcpVirtualDirectory -Server ServerName -WebSiteName "ECPIntern" -InternalUrl "https://eac.demo.local/ecp"

8.) Jetzt benötigen wir noch ein neues OWA Virtual Directory (bitte entsprechend anpassen):

New-OwaVirtualDirectory -Server ServerName -WebSiteName "ECPIntern" -InternalUrl "https://eac.demo.local/owa"

9.) Jetzt müssen wir noch den Admin-Zugriff auf der "alten" IP-Adresse deaktivieren:

Set-ECPVirtualDirectory -Identity "ServerName\ecp (default web site)" -AdminEnabled $false

10.) Ich habe mir jetzt noch über den Exchange ein neues SSL-Zertifikat ausgestellt, dass den FQDN der neuen ECP-Webseite beinhaltet und dieses im IIS an die neue ECP-Webseite gebunden um SSL-Fehler im Browser zu unterdrücken (Zertifikat per GPO ausstreuen)

HINWEIS AM RANDE: Die neue Konfiguration kann bis zu 30 Minuten dauern, bevor der Admin-Zugriff auf die alte ECP-Webseite nicht mehr funktioniert. Also bitte Geduld haben oder Server neu starten!

Quellen für die Lösung:
anexinet: Disable External Access of the Exchange Admin Center

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