Montag, 12. November 2018

Geekmania 2018 - Meine Exchange 2019 Session ist online

Letzten Freitag war die Geekmania 2018. Meine Session über Exchange 2019 könnt ihr euch online ansehen:
About Exchange 2019 - Geekmania 2018

Alle Sessions an der Geekmania der iTrain Mitarbeiter findet ihr hier:
Alle iTrain Sessions - Geekmania 2018

Viel Spass damit!

Mittwoch, 6. Juni 2018

Externer OAB Download benötigt 30 Minuten

Ich hatte gerade bei einem Kunden den Fall, dass der manuelle Download des OAB in Outlook nach einer Migration auf Exchange 2016 30 Minuten benötigte. Nachdem wir den Download des OAB in Outlook manuell gestartet haben, blieb das Fenster, welches den Vorschritt des Downloads anzeigt, einfach ohne Reaktion stehen:


Irgendwann haben wir dann auch genug lange gewartet und bemerkt, dass der Download nach 30 Minuten startet und auch erfolgreich ist.

Nach längerer Suche haben wir dann das Problem gefunden. Der Download des OAB läuft über BITS. BITS hat einen Standard-Timeout von 30 Minuten, wenn eine URL nicht erreichbar ist. Dies passt ja genau zur Wartezeit beim Download des OAB...

Im Eventlog "Bits-Client" (Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> Bits-Client) habe ich dann den Event mit der ID 61 (Quelle: Bits-Client) gefunden und gesehen, dass Outlook versucht das OAB auf der internen URL herunterzuladen. Erst nach 30 Minuten wird die "alternative" URL kontaktiert.

Wir haben das virtuelle Verzeichnis für OAB mit einer internen URL (FQDN/oab) und einer externen URL (mail.mydomain.ch/oab) konfiguriert. Nun scheint es so zu sein, dass Outlook nicht wirklich weiss, ob es intern oder extern ist und verwendet für das OAB zuerst die interne URL, welche aber von Extern nicht erreichbar ist.

Die Lösung in meinem Fall: Auf dem virtuellen Verzeichnis für OAB für interne und externe URL die externe URL eintagen. So kommt Outlook gar nicht erst in Versuchung, die interne URL zu probieren.

Der Grund für das Problem kann nur ein Bug sein.

Dienstag, 5. Juni 2018

Exchange Log Partition läuft voll

Grundsätzlich sollte dies nicht passieren. In einer produktiven sorgt das Backup dafür, dass die Logfiles der Datenbanken nach jedem erfolgreichen Backup gelöscht werden. Dies verhindert, dass die Log-Platten eines Exchange Servers voll laufen.

In einer Testumgebung wird eher selten ein funktionierendes Backup eingerichtet. Daher kann es vorkommen, dass die Laufwerke mit den Logfiles der DBs gefüllt werden. Um die Logs wieder los zu werden, gibt es einen simplen Trick.


  1. Starte auf dem Exchange ein CMD mit erhöhten Rechten
  2. Tippe "Diskshadow" und drücke Enter
  3. Tippe "add volume x:" und drücke Enter (das "x" mit dem Laufwerksbuchstaben ersetzen, auf welchem die Logs liegen)
  4. Tippe "begin Backup" und drücke Enter
  5. Tippe "create" und drücke Enter
  6. Wenn der Vorgang abgeschlossen ist, tippe "end Backup" und drücke Enter
Nach kurzer Zeit kann man zusehen, wie sich die Logfiles "in Luft auflösen".

Die Verwendung dieser Prozedur geschieht auf eigene Gefahr ;-)