Outlook und "Admin hat Änderung durchgeführt"

Diese Seite behandelt das Problem, dass Outlook immer wieder einen Neustart anfordert, weil angeblich der Administrator eine Änderung durchgeführt hat. Das kann unterschiedlichste Gründe haben, die ich hier vorstelle. Vielleicht erlösen Sie damit ihre Anwender von diesem Problem.

So sieht es aus

Die Meldung erscheint meist unverhofft und zur falschen Zeit, obwohl Outlook teils tagelang problemlos gearbeitet hat. Häufig kommt die Meldung während einer Migration oder wenn nach dem Ende die alten Server abgeschaltet werden.

  • Die englisch Meldung lautet:
    "The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook"
  • Die deutsche Meldung sagt genauso wenige aus:
    "Der Microsoft Exchange-Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert."

Beide Meldungen verraten aber nicht, welche Änderung Outlook dazu veranlasst einen Neustart einzufordern-

Mögliche Ursachen

Im Laufe der Jahre habe ich verschiedene Ursachen ermitteln können, die solch eine Meldung aufzeigen. Ich erwarte aber, dass es immer weniger Meldungen der Art gibt, da Microsoft sowohl Outlook aber vor allem auch den Exchange Server derart weiterentwickelt, dass einige Ursachen schon entfallen sind.

Bei Migrationen von Exchange 2010 nach 2016 erscheint diese Meldung nicht nur, wenn ihr eigenes Postfach verschoben wurde und durch den Wechsel von MAPI/TCP oder RPC/HTTP auf MAPI/HTTP das Profil geändert wird, sondern auch wenn andere Postfächer migriert werden, auf die Sie z.B. per Stellvertreter zugreifen.

  • Postfach verschoben (Cross Site)
    Wenn sie ein Postfach im Rahmen einer Migration auf neue Exchange Server verschieben und daher der alte CAS-Server nicht mehr zuständig ist, muss Outlook einmal neu gestartet werden. Dies ist eigentlich immer der Fall, wenn im Rahmen einer Konsolidierung die Postfächer über die Standortgrenzen der ADSite z.B. in die Zentrale verlagert werden und damit sich der RPC-ClientServer ändern. Diese Meldung wird mit älteren Exchange Version nicht zu vermeiden sein, Mit Exchange 2013/2016 dürfte das seltener passieren, da hier die CAS-Server als Reverse Proxy die Daten weiter geben können. Dennoch würde ich Postfächer am besten dann umstellen, wenn die Anwender eh "offline" sind.
  • RPC Zugriffspunkt hat sich geändert
    In die gleiche Richtung geht ein Wechsel des RPC-Zugriffspunkts, der z.B. beim Schwenk eines Rechenzentrums als "Desaster Fall" sich ändern kann, z.B. weil die CAS-Services im anderen RZ einen anderen Namensraum haben.
  • RPC/HTTP und RPC/MAPI-Wackelei
    Bis Exchange 2013/2016 war MAPI/TCP das häufigste interne Zugriffsprotokoll und RPC/HTTP wurde meist nur für den "Outlook Anywhere"-Zugriff von Extern genutzt. Wenn nun die interne TCP-Connection nicht funktioniert, dann kann es passieren, dass durch den Wechsel auf RPC/HTTP mit unpassender Proxy-Konfiguration und Veröffentlichung diese Meldung kommt. Manchmal ist es auch ein fach ein Loadbalancer, der die Verbindungen nicht halten kann. (z.B. Portlimit und 65535 Port-Limit)
  • Public Folder
    Sie können heute Exchange auch ohne öffentliche Order betreiben. Aber häufig gibt es noch alte Verweise auf öffentliche Ordner, die bei einer Migration nicht sauber deinstalliert wurde und manchmal kommt Outlook damit nicht zurecht.
  • Änderungen an Public Folder Datenbanken
    Wenn die Replikate von Ordnern geändert werden und Exchange nun einen anderen "besseren" Server für den Clientzugriff kennt, sendet er einen Verweis an den Client. Outlook schwenkt aber nicht automatisch, sondern braucht einen Neustart.
  • Änderung der Authentifizierung
    Wenn Sie am Server z.B. die Authentifizierungsverfahren bei Outlook Anywhere IIS ändern, kann dies auch den Client dazu bringen, einen Neustart zu verlangen. Informieren Sie daher ihre Clients, wenn Sie z.B. Kerberos für CAS-Server aktivieren.
  • Skype for Business/Lync
    Wenn ein Postfach verschoben wurde, sollte Sie nicht nur Outlook sondern auch den Lync/Skype for Business Client neu starten, da dieser eventuell die MAPI blockiert und Outlook trotz Neustart sich wieder meldet.
  • Update, Update Update
    Auch Outlook ist durchaus nicht fehlerfrei oder kommt mit Neuerungen des Servers nicht zurecht. Prüfen Sie daher, ob ihre Outlook Version aktuell gepatched ist.
  • Stellvertreter etc.
    Beachten Sie auch, dass sich Änderungen nicht nur auf das primäre Postfach beziehen, Wenn ein Benutzer Zugriff auf andere Postfächer hat und diese z.B. verschoben werden, dann kann dies auch diese Meldung erzeugen.

Schauen wir uns ein paar Aspekte etwas genauer an:

RPC-Zugriffspunkt

In den meisten Fällen ist diese Meldung dadurch veranlasst, dass sich der RPC-Endpunkt zumindest einer Verbindung geändert hat und Outlook diese neue Konfiguration erst nach einem Neustart übernimmt. In den meisten Fällen handelt es sich hierbei um Meldungen bei einer Migration, wenn ein Postfach, ein Raum oder auch ein öffentliche Ordner "umgezogen" wird und sich der bisherige RPC-Zugriffsserver ändern.

Es ist egal ob Outlook nun über MAPI/TCP, RPC/HTTP oder MAPI/HTTP mit dem Backend spricht. Auf jeden Fall macht es RPC-Aufrufe und verbindet sich mit einem realen oder virtuellen Service. Im Profil können Sie dies sehr gut sehen:

Mein Postfach lag zum Moment der Aufnahme auf einem Exchange 2016 Server, welcher schon die Datenbank-GUID als RPC-Endpunkt nutzt. Bei älteren Exchange Servern kann dies der Name des "CASArray" oder ein echter Servername sein. Ein echter Servername ist früher oft der Fall gewesen, wenn es nur einen Server gab oder öffentliche Ordner angesprochen wurden. Auch in dem "Verbindungsstatus" von Exchange kann der RPC-Endpunkt gesehen werden.

Outlook Version und Client Protokolle

In Zeiten von Windows Update, Office Update und Click to Run wird es immer schwerer eine veraltete Version zu betreiben. Aber viele Office Updates kommen nicht beim Firmenarbeitsplatz an, weil sie eben aus Sorge dass bestimmte Makros und Add-ons etc. nicht mehr laufen. Auch ist vielen Administratoren gar nicht bekannt, dass es auch für Outlook quasi "monatliche Updates" gibt. Suchen Sie mal nach "Outlook-X-None" und Sie werden finden:

Ein Update kann manchmal Wunder bewirken. Viele Probleme sind Microsoft nämlich durch Support-Calls anderer Firmen schon bekannt.

  • 2591913 "Microsoft Exchange administrator has made a change that requires you quit and restart Outlook" error when you try to access a moved mailbox in Office 365 Dedicated/ITAR
  • 2934750 Mailbox move to Exchange Server causes Outlook connectivity issue
  • 2863911 Description of the Outlook 2013 Update 2863911: March 11, 2014
  • 2878264 January 8, 2015 Update for Outlook 2010 (KB2878264)
    Erforderlich um MAPI/HTTP mit Outlook 2010 zu betreiben
  • 2625547 How to install the latest applicable Updates for Microsoft Outlook (US English only)

Public Folder

Öffentliche Ordner haben eine lange Geschichte in MS-Mail, Exchange und Outlook. Auch wenn immer mehr andere Plattformen die Zusammenarbeit erleichtern, z.B. Yammer, SharePoint etc. gibt es in vielen Exchange Umgebungen weiterhin öffentliche Ordner. Dabei ist jeder Postfachdatenbank genau eine "Öffentliche Ordner Datenbank" zugeordnet. Da kann es bei Migrationen und Veränderungen an den Servern schon einmal passieren, dass diese Verweise ins Leere laufen oder auf eine längst gelöschte Datenbank verweisen. Und das verwirrt Outlook. Prüfen Sie daher den Inhalt des Felds MSExchHomePublicMDB an den jeweiligen Postfachdatenbanken. Mit ADSIEdit können Sie das Feld seht einfach kontrollieren.

Die Einträge können Sie natürlich auch per Exchange PowerShell ermitteln

[PS] C:\>Get-MailboxDatabase  | select name,publicfolderdatabase

Name PublicFolderDatabase
---- --------------------
MB1  PF1
MB2  PF1

Allerdings werden hier Fehler nicht immer korrekt ausgegeben. Daher habe ich hier ein kleines Skript, welches die Daten aller Datenbanken in der Organisation mal schnell als LDAP-Werte ausgibt.

$RootDSE = [ADSI]"LDAP://RootDSE" 
$query = new-object system.directoryservices.directorysearcher
$query.SearchRoot = "LDAP://$($RootDSE.configurationNamingContext)"
$query.PageSize = 1000
$query.filter = "(objectclass=msExchPrivateMDB)"
$query.SearchScope = "subtree"
$query.PropertiesToLoad.Clear() | Out-Null
$query.PropertiesToLoad.Add("name") | Out-Null
$query.PropertiesToLoad.Add("msExchHomePublicMDB") | Out-Null
$query.findall() | % {
   $entry=""| select name,msexchhomepublicmdb
   $entry.name=$_.properties.name[0]
   $entry.msexchhomepublicmdb=$_.properties.msexchhomepublicmdb[0]
   $entry
}

Hier sollten Sie dann schnell auch ein "DEL:" o.ä. sehen. Jede Datenbank sollte einen Verweis auf eine gültige und die richtige Public Folder Datenbank haben oder eben gar keinen Eintrag, wenn es keine öffentlichen Ordner mehr gibt.

Logging

Wenn Sie alle Eventualitäten überprüft haben aber die Meldung weiterhin erscheint, dann könnte das Outlook-Logging auf dem Client weitere Informationen liefern.

Leider sind die Möglichkeiten der Auswertung doch arg beschränkt und ohne einen Microsoft Support Call kommt man hier kaum weiter.

Warnung unterdrücken ?

Interessanterweise gibt es aber auch eine Möglichkeit diese Meldung komplett zu unterdrücken. Folgender Schlüssel in der Registrierung steuert die Meldung. Ein "0" bedeutet, dass die Meldungen abgeschaltet werden während eine 1 die Meldungen wieder aktiviert:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Office\14.0\Outlook\Display Types\Balloons]
"Exchange"=dword:00000000

Ich bin zwar weiterhin ein Freund davon, die Ursache zu finden und zu beheben, vor allem weil Outlook ja nicht unbedingt weiter Mails senden und empfängt. Aber es mag durchaus Situationen geben, in denen die Meldung durch Supportanrufe zu Aufwänden führt, die ein Betreiber vielleicht verhindern will.

Weitere Links