geekmania 2019: Hyperconverged! Die Mitmachsession - Part I

geekmania 2019: Exchange Troubleshooting

Page File auf einem Windows Server 2019 CORE anpassen

Wir betreiben einen Hyper-Converged Cluster mit 2 Nodes unter Windows Server 2019 CORE. Jeder Node verfügt über 192 GB RAM. Da unsere OS Laufwerke aber eine Grösse von 220 GB haben, wurde der freie Speicherplatz auf dem OS Laufwerk knapp, denn die Page Files haben eine Grösse von 192 GB.

Daher habe ich die maximale Page File Grösse angepasst, was gar nicht so einfach ist. Es gibt ja keine Grafische Oberfläche, um die Konfiguration des Page Files anzupassen. Doch wenn man mal herausgefunden hat, wie es gemacht werden muss, ist es gar nicht mehr so schwer.

Zuerst einmal schauen wir uns die momentane Konfiguration an:

wmic.exe pagefileset

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!

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.

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 ;-)

Autodiscover langsam?

Wir haben bei unseren Kunden oft das Problem, dass das Outlook sehr lange braucht, um seine Konfiguration über Autodiscover zu erhalten. Oft liegt es daran, wie der Autodiscover Prozess in Outlook abläuft.

Grob gesagt, nimmt Outlook zuerst was hinter dem @ der Mailadresse steht und versucht darüber den Autodiscover Service zu erreichen.

hans.muster@itrain.ch = https://itrain.ch/autodiscover/autodiscover.xml

Genau dies schlägt meist fehl, denn entweder zeigt diese URL auf den Webserver. Noch schlimmer wird es, wenn die URL dem Domänen Namen entspricht, dann zeigt "itrain.ch" auf alle Domänen Kontroller in der Domäne. Dies hat dann zur Folge, dass jeder Domänen Kontroller kontaktiert wird und keiner dieser DCs kann Autodiscover Informationen liefern. Dies kann sehr lange dauern, denn standardmässig ist ein Timeout von 25 Sekunden hinterlegt.

Der nächste Schritt im Autodiscover Prozess ist, dass Outlook nimmt was hinter dem @ steht und autodiscover. davor setzt.

hans.muster@itrain.ch = https://autodiscover.itrain.ch/autodiscover/autodiscover.xml

Dies ist dann meist erfolgreich.

Um nun die Wartezeit für https://itrain.ch/autodiscover/autodiscover.xml zu umgehen, kann ein Registry Eintrag erstellt werden, welcher das Outlook anweisst, diese Schritt zu überspringen.

Dazu wird unter

"HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover"

ein DWORD Eintrag mit Namen "ExcludeHttpsRootDomain" und dem Wert 1  erstellt.

Weitere Informationen: https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover 

ActiveSync bleibt verbunden trotz...

Kunden haben mir gemeldete, dass ActiveSync Verbindungen trotz geändertem Passwort oder sogar deaktiviertem AD User Objekt weiterhin verbunden bleibt, und dies zum Teil für Tage.

Aufgefallen ist dies, weil ja die meisten Firmen einen sporadischen Passwortwechsel verlangen. Dabei hat sich gezeigt, dass Mobile Geräte zum Teil erst nach Tagen das neue Passwort verlangen und in der Zwischenzeit munter Mails empfangen und versendet werden konnten, alles unter einem Passwort, welches eigentlich nicht mehr gültig ist.

Für Benutzer, welche einfach so oder weil dies sporadisch verlangt wird, ihr Passwort ändern, die Firma aber nicht verlassen, stellt dieses Verhalten kein allzu grosses Problem dar. Der Benutzer hat ja sein Passwort selbst gewechselt und wüsste das neue Passwort.

Problematisch wird es, wenn das Passwort vom Administrator gewechselt oder der Account deaktiviert wurde, weil der Benutzer das Unternehmen verlassen hat. In diesem Fall würde man ja annehmen, dass der Benutzer durch diese Aktion keinerlei Zugriffe auf die Firmeninfrastruktur mehr hat.

Durch die Beschriebene Problematik ist der Benutzer also, unter Umständen, noch tagelang in der Lage Mails zu empfangen und auch zu versenden. Dies kann grossen Schaden verursachen, je nach dem wie einvernehmlich die Trennung von der Firma abgelaufen ist.

Meine Suche nach einer Lösung hat hervorgebracht, dass dieses Problem schon diversen Personen aufgefallen ist, es aber keine Lösung dafür gibt. Es scheint, dass hier Sicherheit durch Benutzerfreundlichkeit ausgehebelt wurde.

Wichtig ist, diesen Umstand zu kennen, denn ein User lässt schon gänzlich von seinem Postfach trennen, nur reicht es nicht, "nur" den AD Account zu deaktivieren oder das Passwort zu ändern. Mindestens einer der folgenden Schritte muss zusätzlich ausgeführt werden:

• Neustart der Webservices (IIS)
• Recyceln der Application Pools "MSExchangeSyncAppPool"

Diese beiden Optionen sind nicht die optimalsten, denn diese Aktionen betreffen auch andere Benutzer. Ohne andere Benutzer zu stören nützen auch folgende Aktionen:

• In den Einstellungen des Postfaches ActiveSync deaktivieren
• Das betroffene Postfach in eine andere Datenbank verschieben
• Das Telefon aus der Exchange Verwaltungsseite heraus wipen
• Die Verbindung des Telefons aus dem Postfach löschen

OWA und EAS Log Analyse

OWA Log Analyse

Die Zugriffe auf OWA lassen sich mittels der IIS Logs analysieren. Dazu kann man das MS Tool «LogParser 2.2» verwenden. Das Tool lässt sich hier herunter laden:

https://www.microsoft.com/en-us/download/details.aspx?id=24659

Arbeitsordner erstellen

Für die Analyse der IIS Logs ist es am einfachsten, zuerst mal einen Arbeitsordner zu erstellen. Danach werden dort die Logs abgelegt, welche analysiert werden sollen.

Hierarchisches Adressbuch

In grossen Organisationen stellt sich immer wieder die Frage, wie Adressbücher übersichtlich gestaltet werden sollen. Seit Exchange 2010 SP1 haben wir eine neue Funktion bekommen, welche sich «Hierarchisches Adressbuch» nennt. Das Ganze sieht wie folgt aus:

Der Aufbau eines hierarchischen Adressbuches wird über Verteilerlisten gesteuert. Diese werden ineinander verschachtelt und so gekennzeichnet, dass sie im hierarchischen Adressbuch berücksichtigt werden. Wie das geht, zeige ich anhand einer Step by Step Anleitung am Beispiel der Firma, in welcher ich arbeite. Das Ziel ist, ein hierarchisches Adressbuch aufzubauen, wie ihr es oben in der Ausbildung sehen könnt.

Exchange 2016 - Deaktiviertes Postfach mit Archiv wieder verbinden

Wenn man unter Exchange 2016 ein Postfach mit Archiv deaktiviert, wird sowohl das Postfach wie auch das Archiv vom Userobjekt in der AD abgekoppelt. Exchange löscht nun das Postfach wie auch das Archiv in der Datenbank gemäss den Einstellungen auf der Datenbank (Gelöschte Postfächer aufbewahren für (Tage)). Der Standardwert für die Vorhaltezeit gelöschter Postfächer sind 30 Tage.

Wenn man nun ein deaktiviertes Postfach wieder mit einem Userobjekt in der AD verbinden will (muss nicht das ursprüngliche Userobjekt sein), muss man zuerst die «MailboxGuid» des Postfaches herausfinden. Dies kann mit folgendem Befehl gefunden werden:

Get-MailboxStatistics -Database MDB02 | fl DisplayName,MailboxGuid

Dieser Befehl gibt aber alle vorhandenen Postfächer in einer Datenbank aus. Natürlich ist das nicht sehr praktisch in einer Umgebung mit vielen Postfächern. Also kann es erforderlich sein, etwas mehr zu filtern.

Get-MailboxStatistics -Database MDB02 | ? {$_.DisplayName -like "*Brunner*"} | FL DisplayName,MailboxGuid

Hier werden alle Postfächer gefunden, welche im Namen «Brunner» beinhalten und sich in der Datenbank «MDB02» befinden.

Wenn ich aber nun nicht weiss, in welcher Datenbank sich das Postfach (oder das Archiv) befunden hat, kann ich über folgenden Befehl herausfinden, welche Postfächer (oder Archive) es in allen Datenbanken gibt, welche im Namen «Brunner» beinhalten. Im Resultat wird auch gleich die MailboxGuid der Postfächer ausgegeben:

Get-MailboxDatabase | Get-MailboxStatistics | ? {$_.DisplayName -like "*Brunner*"} | FL DisplayName,MailboxGuid,Database

Um einfach alle getrennten Postfächer in allen Datenbanken anzuzeigen kann folgender Befehl verwendet werden:

Get-MailboxDatabase | Get-MailboxStatistics | ? {$_.DisconnectDate -ne $NULL} | FL DisplayName,MailboxGuid,Database,DisconnectDate

Wenn wir nun mal die MailboxGuid haben, können wir das Postfach wieder mit einem Userobjekt verbinden. Ich verwende jeweils den UPN des Userobjektes, an welches ich das Postfach hängen will:

Connect-Mailbox –Identity 4cd7b972-cb64-43bc-b6fc-5dc4446ed971 –Database MDB02 –user b.brunner@itrain.ch

Leider ist nun aber lediglich das primäre Postfach verbunden. Wenn das Postfach vorher ein Archiv hatte, muss ich das auch noch mit dem Userobjekt verbinden. Dies geht mit folgenden Befehl:

Enable-Mailbox -ArchiveGuid 8d6fbef2-5f73-4e00-b06e-5e91c9e9ad30 -ArchiveDatabase MDB02 -Identity b.brunner@itrain.ch

Nun sind Postfach und Archiv wieder gemeinsam mit dem gewünschten Userobjekt verbunden.

Mail versenden mit Alias

Hatte gerade eine Anforderung eines Kunden. Dort sollen Leute Mails wahlweise unter einem Alias versenden können anstelle unter der Standard Antwort Adresse die im Postfach konfiguriert ist. Grundsätzlich ist dies nicht möglich. Es musste also ein Workaround gefunden werden.

Als erstes habe ich natürlich daran gedacht, einfach den Alias vom Postfach zu entfernen und ein separates Postfach mit der Adresse zu erstellen. Dann gibt man noch «Vollzugriff» und «Senden als» Berechtigungen für die Person, welche die Adresse verwenden will.
Nachteil dieser Lösung ist, dass der User am Ende eine weiteres Postfach im Outlook hat und auch die gesendeten Mails werden natürlich in diesem zusätzlichen Postfach abgelegt. Diese Lösung gefiel dem Kunden nicht. Die User sollen weiterhin nur ein Postfach im Outlook haben und über die Auswahl im «Von Feld» die zweite Adresse auswählen können. Auch sollen die gesendet Mails in diesem einen Postfach abgelegt werden.

Im Internet findet man auch Lösungsansätze, die sich mit einem POP3 «dummy» Postfach behelfen. Ich wollte keine POP3 auf dem Exchange aktivieren und habe weiter nach einer bessern Lösung gesucht.

Exchange 2016 - Erste News von der Ignite 2015

Die ersten Infos über Exchange vNext sind nun draussen. die ersten Sessions zum Thema an der Ignite 2015 sind gelaufen. Hier ein paar Facts:

Release Date

• Exchange 2016 Public beta ist auf Sommer 2015 angesagt. RTM soll im Herbst / Winter 2015 verfügbar sein.

Architektur

• Keine Trennung der Rollen bei der Installation. Also keine reinen CAS oder MBX Server mehr
• CAS Proxing zwischen Exchange 2016 und 2013 möglich, und dies in beide Richtungen
• Gemischte Umgebungen mit Exchange 2010 SP3 RU11 (oder höher) oder Exchange 2013 CU10 (oder höher)
• Wie zu erwarten war, keine Koexistenz mit Exchange 2007
• Als OS wird 2012 R2 und Server 10 unterstützt
• Forest und Domain Level müssen 2008 R2 oder höher sein
• Es werden Outlook 2010 SP2 (mit KB2956191 und KB2965295 oder höher), Outlook 2013 SP1 (mit KB3020812 oder höher) und Outlook 2016 unterstützt
• Als Standard-Clientprotokoll wird MAPI/HTTP verwendet
• Witness Share (Zeugenserver) in Azure möglich

Speicherung der Daten

• 22% weniger IOPS im Vergleich zu Exchange 2013 RTM (und täglich grüsst das Murmeltier)
• Der Suchindex wird auf der passiven Kopie einer Datenbank erstellt

Hochverfügbarkeit

• DAG hat kein Clusterobjekt (CNO) mehr
• Schnellere Datenbank-Umschaltung
• Weitgehend die gleichen Anforderungen an Load Balancer wie bei Exchange 2013

Weitere News werde ich wieder Posten.

ADFS 3.0 non SNI Client Support konfiguration

Seit Windows Server 2012 R2 ist ADFS in der Version 3.0 verfügbar. Eine der grossen Änderungen ist, dass das es ADFS Proxy nicht mehr gibt. Es wird auch keine IIS mehr benötigt. Dafür ist aber der Support von SNI dazu gekommen. Aber was ist denn SNI überhaupt? SNI heisst «Server Name Indication». Infos über SNI gibt es hier und hier.

Wie ihr also in den Links oben lesen könnt, sind «nur» neuere Clients in der Lage SNI-Informationen im TLS Handshake mitzusenden. Die Clients machen mir aber in der Praxis nur selten Sorgen. Es ist eher so, dass ADFS Umgebungen meist redundant aufgebaut werden und daher auch ein Load Balancing benötigen. Nun ist es eben so, dass die meisten Load Balancer nicht mit SNI umgehen können oder diese Informationen auf dem Backend einfach nicht weiter geben.

Ein ADFS 3.0 Server möchte aber in der Default-Konfiguration diese Information haben. Anfragen ohne SNI Informationen werden nicht verarbeitet. Also müssen wir den ADFS 3.0 Server dazu bringen, diese Anfragen trotzdem zu verarbeitet. Bewerkstelligt wird dies, indem man ein Standard Zertifikat definiert. Und gemacht wird dies so:

iOS 8.3 bringt Exchange relevante Fixes

Das neueste Update für iPhones bringt auch Fehlerkorrekturen in Bezug auf Exchange:

• Exchange-Abwesenheitsbenachrichtigungen können jetzt separat für externe Antworten bearbeitet werden
• Optimiert die Wiederherstellung von Exchange-Accounts bei temporären Verbindungsproblemen
• Korrigiert ein Problem, durch das Exchange-Termine mit langen Notizen abgeschnitten wurden

Falls ihr in letzter Zeit mit solchen Problemen gekämpft habt, ist dies sicher eine gute Nachricht.

Die ganze Liste der Leistungsverbesserungen und Fehlerkorrekturen findet ihr hier.