Mittwoch, 13. Dezember 2017

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 


Donnerstag, 5. Januar 2017

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