Exchange 2016 – DNString mismatch

This little article should be hopefully helpful to solve the following error while Updating a Microsoft Exchange Server 2016 or Accessing this Server using Powershell.
It’s not a solution to solve the actual problem, but a work a round to complete the Setup and get the Server up and running.

The Error shows up as:

„DNString length mismatch“

Don’t run into the wrong direction

At First don’t run into the wrong direction. This Error has noting to do with DNS (and a forgotten second „s“). It’s a LDAP Error. If this Error would be written by:

„DN String length mismatch“

it would be more clearly!


While running the Update procedure to MS Exchange 2016 CU 8, the Setup interrups while progressing Mailbox role: Client Access service with the following Error:

Searching objects of type "ADOwaVirtualDirectory" with filter "(OwaVersion NotEqual Exchange2003or2000)", scope "SubTree" under the root "EXCH16".
[ERROR] DNString length mismatch
[WARNING] An unexpected error has occurred and a Watson dump is being generated: DNString length mismatch
Die Active Directory-Sitzungseinstellungen für 'Set-OwaVirtualDirectory' lauten: Vollständige Gesamtstruktur anzeigen: 'True', Konfigurationsdomänencontroller: '', Bevorzugter globaler Katalog: '', Bevorzugte Domänencontroller: '{ }'
User specified parameters:  -Identity:'EXCH16\OWA (Exchange Back End)' -FormsAuthentication:'False' -WindowsAuthentication:'True'
Beginning processing set-OwaVirtualdirectory
Searching objects "EXCH16\OWA (Exchange Back End)" of type "ADOwaVirtualDirectory" under the root "$null".
Previous operation run on domain controller ''.
[ERROR] DNString length mismatch
[WARNING] An unexpected error has occurred and a Watson dump is being generated: DNString length mismatch

While accessing the OWAVirtualDirectory I got the same Error:

WARNUNG: Unerwarteter Fehler. Ein Watson-Abbild wird generiert: DNString length mismatch.

Trying to remove the actual OWA Directory to recreate it would fail with the same error

Remove-OwaVirtualDirectory "Exch16\owa (Default Web Site)"
WARNUNG: Unerwarteter Fehler. Ein Watson-Abbild wird generiert: DNString length mismatch.
DNString length mismatch
    + CategoryInfo          : NotSpecified: (:) [Remove-OwaVirtualDirectory], FormatException
    + FullyQualifiedErrorId : System.FormatException,Microsoft.Exchange.Management.SystemConfig 
    + PSComputerName        :

work a round

OK, let’s fix it!

Short info: The Attributes we will need to correct will be not editable by using ADSI, so I used Apache Directory Studio.

Connect to

LDAP-Tree and Navigate to:
DN: CN=owa (Default Web Site),CN=HTTP,CN=Protocols,CN=EXCH16,CN=Servers,CN= Exchange Administrative Group (ABCDEFGH12IJKLM),CN=Administrative Groups,CN =First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=com

If you dump this branch into ldif File you would find something link this:

msExchOWABlockedMIMETypes: S:22:application/javascript:CN=owa (Default Web S
 ite),CN=HTTP,CN=Protocols,CN=EXCH16,CN=Servers,CN=Exchange Administrative 
 Group (ABCDEFGH12IJKLM),CN=Administrative Groups,CN=First Organization,CN=M
 icrosoft Exchange,CN=Services,CN=Configuration,DC=example,DC=com
msExchOWABlockedMIMETypes:: Uzo2NjrigKDigKDigKDigKDigKDigKDigKDigKDigKDigKDi

The second line is the problem.

Find and Remove the Lines starting with „††.*“

After that connect to powershell and discard and recreate the OWAVirtualDirectory (with command Feedback):

Remove-OwaVirtualDirectory "EXCH16\owa (Default Web Site)"
Remove-OwaVirtualDirectory "EXCH16\owa (Exchange Back End)"
New-OwaVirtualDirectory  -InternalUrl “” -ExternalUrl “”
Name                             Server                           OwaVersion
----                             ------                           ----------
owa (Default Web Site)           EXCH16                          Exchange2013
New-OwaVirtualDirectory  -InternalUrl “” -ExternalUrl “” -WebSiteName “Exchange Back End”
Name                             Server                           OwaVersion
----                             ------                           ----------
owa (Default Web Site)           EXCH16                          Exchange2013
Name                             Server                           OwaVersion
----                             ------                           ----------
owa (Default Web Site)           EXCH16                          Exchange2013

Please check also OWAMailboxPolicy, it’s possible that you get the same error:

WARNUNG: Unerwarteter Fehler. Ein Watson-Abbild wird generiert: DNString length mismatch.
DNString length mismatch
    + CategoryInfo          : NotSpecified: (:) [Get-OwaMailboxPolicy], FormatException
    + FullyQualifiedErrorId : System.FormatException,Microsoft.Exchange.Management.Tasks.GetOwa
    + PSComputerName        :

If so, goto DN: CN=Default,CN=OWA Mailbox Policies,CN=First Organization,CN=Microsoft Ex change,CN=Services,CN=Configuration,DC=example,DC=com and Find and Revove the Lines starting with „††.*“.
After that recreate the MailboxPolicy by:

New-OwaMailboxPolicy -Name Default

Then restart the Exchange Upgrade Setup. It should be completed.


This problem occours while Updating MS Exchange Server 2016 to CU 8 released on 17. Dec. 2017 on Windows 2012 Server R2 Std. The MSAD PDC is a Windows Server 2012 R2 and a Samba Server Version 4.5.12 (Running Debian Stretch) as Fileserver and Domain Controller.

Uncheck assumption: The Problem maybe occurs because of an Replication Error.
Possible hint: The defect BASE64 String in the LDAP Tree is maybe happend by a bit toppler in replication
ToDo: Try to reproduce in Lab

freeSwitch – versatel.sip

As known, Versatel needs „versatel.sip“ as REALM. This is not an fqdn and there for we run in some little possible config trouble.

Basic example for connection freeswith pbx to (1&1) Versatel public phone service

This example contains an example phone number and password – please change it!

  <gateway name="versatel">
    <param name="username" value="0049301234567"/>
    <param name="password" value="bu!Msuf5"/>
    <!--/// proxy /realm host: Versatel Name! ///-->
    <param name="proxy" value="versatel.sip"/>
    <param name="realm" value="versatel.sip"/>
    <!--/// send register to this proxy: correct DNS Name! ///-->
    <param name="register-proxy" value=""/>
    <param name="outbound-proxy" value=""/>
    <!--/// expire in seconds: *optional* 3600, if blank ///-->
    <!--<param name="expire-seconds" value="60"/>-->
    <!--/// do not register => false ///-->
    <param name="register" value="true"/>
    <param name="register-transport" value="udp"/>
    <!--<param name="retry-seconds" value="30"/>-->
    <!--Use the callerid of an inbound call in the from field on outbound calls via this gateway, imported to versatel -->
    <param name="caller-id-in-from" value="true"/>
    <!--extra sip params to send in the contact-->
    <!--<param name="contact-params" value="tport=tcp"/>-->
    <!--send an options ping every x seconds, failure will unregister and/or mark it down-->
    <!--<param name="ping" value="25"/>-->
  <!--rfc5626 : Abilitazione rfc5626 ///-->
  <!--<param name="rfc-5626" value="true"/>-->
  <!--rfc5626 : extra sip params to send in the contact-->
  <!--<param name="reg-id" value="1"/>-->

Asterisk – versatel.sip

Die Versatel wünscht sich als REALM „versatel.sip“ in der Registrierung. Mit der folgenden Konfiguration funktioniert die Registrierung mit einer Asterisk PBX.

Telefonnummer und Kennwort sind natürlich der individuellen Konfiguration anzupassen…


register => 0049301234567:bu!Msuf5@versatel.sip/0049301234567

ggf. ist noch in der /etc/hosts der folgende Eintrag sinnvoll hinzuzufügen:   versatel.sip

Updating freeradius 2.2.5 to 3

After a Debian Update to Stretch the freeradius Server with mysql database stopped working!
A short investigation I saw that the config structure change and there was no update script provided. – Ok. No Problem: Old config on the left hand – new Config on the rigth hand and after a few minutes the radius server was talking to the mysqldb/mariadb server, again. But looking to the debug log, I found some mysql insert errors.
An other a short comparission I found the changes in the database schema, especially in the accounting table (radacct), but there was als no Update script 🙁
So. here is my SQL Update for the radius database:

ADD COLUMN `acctupdatetime` datetime NULL default NULL AFTER `acctstarttime`,
ADD COLUMN `acctinterval` int(12) default NULL AFTER `acctstoptime`,
DROP COLUMN `acctstartdelay`,
DROP COLUMN `acctstopdelay`,
DROP COLUMN `xascendsessionsvrkey`,
ADD KEY `acctinterval` (acctinterval);
GRANT ALL PRIVILEGES ON radius.radpostauth to 'radius'@'localhost';

cmd batch script für ein MySQLdump pro DB

Falls es noch jemensch gebrauchen kann:
Hier ein kleines Script, nur batch und mysql client tools, zum dumpen aller Datenbanken in jeweils eine eigene .sql Datei

Installationsort in diesem Beispiel: c:\mysqldump


host = localhost
user = root
password = kennwort
host = localhost
user = root
password = kennwort

mysql.bat (Hilfsscript)

@echo off
set MYSQLBIN="C:\Program Files\MySQL\MySQL-5.6\bin"
set MYSQLCONF=C:\mysqldump\mysql.cnf
%MYSQLBIN%\mysql.exe --defaults-file=%MYSQLCONF% -B --skip-column-names -e "show databases"

mysqldump.bat (Hauptscript)

@echo off
set BACKUPDIR=C:\mysqldump\mysqldump
set MYSQLBIN="C:\Program Files\MySQL\MySQL-5.6\bin"
set MYSQLCONF=C:\mysqldump\mysql.cnf
if not exist %BACKUPDIR% mkdir %BACKUPDIR%
for /f "delims=" %%A IN ('C:\mysqldump\mysql.bat') DO (
    echo %%A
    %MYSQLBIN%\mysqldump.exe --defaults-file=%MYSQLCONF% %%A  &gt; %BACKUPDIR%\%%A.sql
exit 0

Spaß mit TLSA Records

Bei dem Erzeugen des Hash für einen TLSA Record kann mensch plötzlich sehr viel „Spaß“ haben.

Die geläufigste, beim Suchen zu findende Anleitung ist ja die folgende:

openssl x509 -in -outform DER | openssl sha256
(stdin)= 46fc14a051629364fc0bedafd87b74731c7e63af4d772127871b0bd9f2bbd29c

soweit so gut. Also einen ensprechden Hashwert erzeugt und per DNS publiziert. Im nächsten Schritt versuchen wir mal den Eintrag zu validieren unter Verwendung von z.B.: oder

Und was müssen wir feststellen: Der Hashwert ist ungültig! – aber warum?

Ok, also auf ein Webseiten gegangen um einen TLSA Hash zu erstellen (z.B.:

Hups, warum kommt die Webseite auf ein anderes Ergebnis als openssl in der Shell?

Möglicherweise ein openssl Problem? – Probieren wir mal einen anderen Rechner aus – das gleiche Ergebnis wie vorher – ist ja auf der einen Seite gut und sollte auch so sein – aber warum kommt die Webseite auf ein anderes Ergebnis als ich?

Beim Suchen bin ich nun über den einen Blogeintrag gestolpert:
Hier gibt es einen Codeschnipsel zum erzeugen des TLSA Records … Probieren wir den doch mal aus – und? – das gleiche Ergebnis wie die Webseiten ….

Hier der besagte Codeschnipsel als bash script:

server=`hostname -f`
tlsa=$(openssl x509 -in $1 -noout -pubkey |
 openssl pkey -pubin -outform DER |
 openssl dgst -sha256 -binary |
 hexdump -ve '/1 "%02x"')
echo -e "_25._tcp.$server. IN TLSA 3 1 1 $tlsa\n"

Ist ein wenig aufwendiger – führt aber zu einem offensichtlich „schönerem“ Ergebnis.

Und für’s nächste mal:

posttls-finger -t30 -T180 -c -L verbose,summary

und selber überprüfen …

Exchange 2013 Änderung des fqdn

Änderung des internen Servernamens zu einem öffentlichen fqdn

Problem: SAN/UCC Zertifikate mit irgendwas.local,, irgendwas.lan usw.  werden  durch CAs nicht mehr ausgestellt

Also: „Umbenennen“ des Servers exchange.example.local nach, damit Netzwerkinterne Clients kleine Zertifikatsfehlermeldungen erhalten

Autodiscover URL

  • Verbinde dich mit der Exchange Managemend Shell
Set-ClientAccessServer -Identity Your_Server_Name
 Set-ClientAccessServer -Identity Your_Server_Name -AutodiscoverServiceInternalUri <a class="external free" href="" rel="nofollow"></a>


Anpassung der InternalURL

 Set-WebServicesVirtualDirectory -Identity "Your_Server_Name\EWS (Default Web Site)" -InternalUrl <a class="external free" href="" rel="nofollow"></a>


Anpassen der InternalURL

 Set-OABVirtualDirectory -Identity "Your_Server_Name\oab (Default Web Site)" -InternalUrl <a class="external free" href="" rel="nofollow"></a>


Falls verwendet: Anpassen der UM Web InternalURL

 Set-UMVirtualDirectory -Identity “Your_Server_Name\unifiedmessaging (Default Web Site)-InternalUrl <a class="external free" href="" rel="nofollow"></a>

IIS App Pool Recycle

  • Öffne den IIS Manager
  • Gehe zum Server -> Application Pool / Anwendungspool
  • Suche MSExchangeAutodiscoverAppPool -> rechtsklick Recycle / Wiederverwenden
  • zur Sicherheit IIS Neustarten iisreset


Quelle: GoDaddy (im Google Cache)

   Help/SSL Certificates/Reconfiguring Microsoft Exchange Server to Use a Fully Qualified Domain Name

Inhaltliche Wiedergabe und Zusammenfassung

fqdn setzen bzw. anpassen

Um die .local, .lan, .intern Sünden zu beheben und vor allem spätestens, wenn es notwendig wird, einem internen Dienst ein „ordentlich“, soll heißen öffentlichen CA, signierten Zertifikat auszustatten ist sinnvoll und notwendig den Maschinen einen Fully Qualified Name mit gültiger tld.

Also passen wir hier in unseren vorhandenen Debian Systemen mal fleißig die Namen an:

  1. /etc/init.d/ stop
  2. echo > /etc/mailname
  3. echo fliege > /etc/hostname
  4. in der /etc/hosts „ fliege“
  5. /etc/init.d/ start

Danach sollte sich die Maschine wie folgt verhalten:

fliege:~# hostname
fliege:~# hostname -f

Wirklich ausschlaggebend ist eigentlich nur die /etc/hosts       localhost.localdomain localhost fliege

Die Datei /etc/hostname ist eigentlich nur anzupassen, wenn sich der Hostname selber ändert

Die Datei /etc/mailname ist nur vorhanden, wenn auch ein MTA installiert ist – hier sollte der gleiche fqdn gesetzt sein, wie in der /etc/hosts

LDAP Abfrage für einen vorgelagerten Postfix

Wie so schon in Beiträgen wie diesen beschrieben, kann ein Postfix wunderbar dem Netzwerkinternen Exchange Server vorgeschaltet werden. Bei der LDAP Abfrage gegenüber dem AD möchte mensch natürlich nur gültige eMailadressen annehmen und dem Exchange Server weiter leiten. Dafür reicht der folgende LDAP Query Filter prinzipiell aus:

query_filter = (|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))
result_attribute = mail

Allerdings kann es in einer Domainumgebung vorkommen, daß Menschen eine Organisation verlassen und der Account z.B. zu einem Bestimmten Zeitpunkt auslaufen / gesperrt werden. Diese Information wird im AD bei dem Benutzer in dem Attribut „accountExpires“ gespeichert. Der Defaultwert ist dabei in Dezimal: 9223372036854775807 oder auch 0x7FFFFFFFFFFFFFFF als Hexadezimalwert. Die entsprechende Dokumentation des Attributes kann bei Microsoft im Artikel ms675098 gefunden werden.

Darüber hinaus ist es möglicherweise nicht gewünscht, daß für deaktivierte Accounts / gesperrte Accounts überhaupt eMails angenommen werden. Ob ein Account gesperrt ist oder welchen zustand dieser so gerade hat, wird im AD bei dem Benutzer im Attribut „userAccountControl“ abgespeichert.

Ein aktivierter Account hat den Dezimalwert 512, ein aktivierter Account ohne ablaufenden Kennwort wird Dezimal als 66048 repräsentiert. Beide werte sind also für aktive Accounts

query_filter = (&(|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))(&(accountExpires=9223372036854775807)(|(userAccountControl=512)(userAccountControl=66048))))

Diese Abfrage filtert demnach a) die gültige eMailadresse, b) ob der Account nicht Abgelaufen ist und c) ob der Account aktiviert ist.

Bei der Abfrage ob ein Account aktiviert ist, stellt sich hier das Problem, daß ein Account gerade deaktiviert wurde oder in Zukunft deaktiviert, eMails aber noch angenommen werden sollen (z.B.: um per auto-replay mitzuteilen, daß mensch nicht mehr dabei ist und zukünftig andere Personen zuständig sind)

Mit Hilfe der Powershell lässt sich die aktuelle Zeit einfach in einen entsprechenden Zeitstempel umrechnen und ausgeben

PS> (Get-Date).ToFileTime()

Der Filter lässt sich wie folgt anpassen:

query_filter = (&(|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))(&(accountExpires>=130954282658740101)(|(userAccountControl=512)(userAccountControl=66048))))

somit werden eMails an einen Account, der eine kleinen kleineren Zeitstempel, als der in der Abfrage, hat, nicht mehr zugestellt. Diesen Zeitstempel muß mensch ggf. regelmäßig im Filter der LDAP Abfrage anpassen.

Mit dem bisher gebauten filter sind leider keine Exchange eMail Gruppen berücksichtigt. Um diese zu berücksichtigen erweitern wir den Filter um die Frage nach der „objectClass„.

query_filter = (&(|(mail=%u@%d)(uid=%u)(proxyAddresses=*smtp:%u@%d*))(|(&(accountExpires>=130954282658740101)(|(userAccountControl=512)(userAccountControl=66048))(objectClass=person))(objectClass=group)))

Was genau macht dieser Filter jetzt?

  1. gibt es die eMailadresse: ja
  2. ist das Object eine Gruppe: ja
    => alles schick: gibt die eMailadresse zurück
  1. gibt es die eMailadresse; ja
  2. ist das Object ein Benutzer: ja
  3. ist der Benutzer weder gesperrt noch abgelaufen?: ja
    => alles schick: gibt die eMailadresse zurück


Exchange 2013 cu6 Probleme bei Sicherheitsupdate

Hier eine kleine Dokumentation von einem Problem, welches nach einem Sicherheitsupdate für den Microsoft Exchange 2013 CU6 aufgetreten war.

Das Problem trat auf nachdem ein über den WSUS verteiltes Sicherheitsupdate (KB3011140) während der Installation abgebrochen war und nicht automatisch erneut installiert werden konnte.

Bei der Analyse des Exchange Servers konnte dann festgestellt werden, daß alle vom Exchange benötigten Dienste deaktiviert waren. Ein Rollback des Sicherheitsupdates nach dem Abbruch fand also offensichtlich nicht statt.
Eine erneute Installation des Sicherheitsupdates war nicht möglich. In der MSI Log Datei war zu entdecken, daß dieses Update nicht für die aktuell installiert Version des Exchange Servers bestimmt sei.

Problem Lösung:
Alle Dienste wurden auf Manual starten eingestellt und die installation des Exchange 2013 CU6 wurde als Updateinstallation noch einmal durchgeführt.

setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms

Hier war sodann das Problem, daß angeblich, auch nach einem Server neustart, ein Server neustart ausstand. Also

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

hier löschen wir dem Schlüssel „PendingFileRenameOperations“ und starten die Update Installation des Exchange Servers neu.

Nach der erfolgten Update Installation starten wir die Installation des Sicherheits Updates KB3011140 neu. Wie bereits geschrieben werden bei der Installation des Sicherheitsupdates alle Exchange Dienste deaktiviert und nach der Installation auch wieder aktiviert (oder fast alle!).

Nach der Installation des Sicherheitsupdates lief der Exchangeserver ersteinmal wieder sauber. Lediglich nur bis zum Neustart des Servers. Nach einem Neustart ist es zwar möglich auf die OWA und ECP Seiten aufzurufen und dort anzumelden. Leider kommt der mensch aber dann nur bis zu Seite „“ eine leeren Seite, welche der Server mit der Statusmeldung 500 (Genauer: 500 ServerLocatorError) zurück gibt.
Zuerst natürlich die „üblichen“ Probleme im IIS kontrollieren: Sind die SSL Bindings für die Default Web Site und die Backend Website korrekt? – Ja sind sie.
Mit ein wenig „googeln“ kommt mensch zu dem Hinweis mensch möge doch mal in der \Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa\HttpProxy_*.log nachschauen und siehe da wir entdecken die folgende Fehlermeldung nach der Anmeldung:
HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Kommunikationsfehler bei Aufruf von Serverlocatordienst. —> Microsoft.Exchange.Data.Storage.ServerLocator.ServerLocatorClientTransientException: Kommunikationsfehler bei Aufruf von Serverlocatordienst. —> System.ServiceModel.EndpointNotFoundException: Es konnte keine Verbindung mit „net.tcp://exchange.example.local:64337/Exchange.HighAvailability/ServerLocator“ hergestellt werden. Der Verbindungsversuch hat für einen Zeitraum von 00:00:02.0480278 angedauert. TCP-Fehlercode 10061: Es konnte keine Verbindung hergestellt werden  da der Zielcomputer die Verbindung verweigerte  —> System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden  da der Zielcomputer die Verbindung verweigerte    bei System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)    bei System.ServiceModel.Channels.SocketConnectionInitiator.ConnectAsyncResult.OnConnect(IAsyncResult result)    — Ende der internen Ausnahmestapelüberwachung —  Server stack trace:     bei System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)    bei System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)    bei System.ServiceModel.Channels.ServiceChannel.EndCall(String action  Object[] outs  IAsyncResult result)    bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeEndService(IMethodCallMessage methodCall  ProxyOperationRuntime operation)    bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)  Exception rethrown at [0]:     bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg  IMessage retMsg)    bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData  Int32 type)    bei ServerLocator.EndGetActiveCopiesForDatabaseAvailabilityGroup(IAsyncResult result)    bei Microsoft.Exchange.Data.Storage.ServerLocator.ServerLocatorServiceClient.EndGetActiveCopiesForDatabaseAvailabilityGroup(IAsyncResult result)    — Ende der internen Ausnahmestapelüberwachung —    bei Microsoft.Exchange.Data.ApplicationLogic.Cafe.MailboxServerLocator.EndGetServer(IAsyncResult result)    bei Microsoft.Exchange.HttpProxy.MailboxServerCache.ServerLocatorEndGetServer(MailboxServerLocator locator  IAsyncResult asyncResult  Guid initiatingRequestId)    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.ProcessMailboxServerLocatorCallBack(IAsyncResult asyncResult  MailboxServerLocatorAsyncState asyncState)    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalOnCalculateTargetBackEndCompleted(TargetCalculationCallbackBeacon beacon)    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass3a.<OnCalculateTargetBackEndCompleted>b__39()    — Ende der internen Ausnahmestapelüberwachung —;
Gut, danke für den Hinweis, also weiter suchen:
Ich bin dann über die folgende Website ( gestolpert. Die beschäftigen sich hier mit der Hochverfügbarkeit von Exchange Servern.
Der folgende PowerShell Befehl gab hier einen kleinen Hinweis:

PS C:\Windows\system32> Get-MailboxDatabase -status | select name,mounted,mountedonserver

Name                                                                                                      Mounted MountedOnServer
—-                                                                                                      ——- —————
Sirius01                                                                                                    False exchange.example.local

Warum zum Geier ist die Datenbank nicht gemountet?

Gut also Datenbank einbinden, hierfür holen wir uns mal kurz die Guid

PS C:\Windows\system32> Get-MailboxDatabase | select *UID*


und mounten:

PS C:\Windows\system32> Mount-Database -Identity abbbb120-a4567-890a-bcde-f01234567ae2
Fehler beim Einbinden der Datenbank „abbbb120-a4567-890a-bcde-f01234567ae2“. Fehler: Fehler bei Active Manager-Vorgang: Der Microsoft Exchange-Replikationsdienst kann nicht auf Server EXCHANGE.example.local ausgeführt werden. Spezifische RPC-Fehlermeldung: Error 0x6d9 (In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar) from cli_MountDatabase3.
+ CategoryInfo          : InvalidOperation: (Sirius01:ADObjectId) [Mount-Database], InvalidOperationException
+ FullyQualifiedErrorId : [Server=EXCHANGE,RequestId=9b9d2a66-2c1b-42d1-8e84-69e34533b2da,TimeStamp=18.12.2014 11:12:43] [FailureCategory=Cmdlet-InvalidOperationExcep
tion] 85C2F094,Microsoft.Exchange.Management.SystemConfigurationTasks.MountDatabase

OK, der Dienst „Exchange-Replikationsdienst“ wird nicht ausgeführt…
Problem ist, daß dieser Dienst nach dem einspielen des Sicherheitsupdates auf Maunal gestellt ist und somit nicht automatisch gestartet wird. Starten wir den Dienst, können wir die Dantenbank problemlos einbinden und die Exchange Webseiten sowie die Outlook RPC Verbindung steht wieder zur Verfügung.

Um dies persistent zu machen stellen wir die Starteinstellungen von „Manual“ auf „Automatisch“ und nun steht die Datenbank auch nach einem Neustart des Servers automatisch wieder zur Verfügung.

… „tolle (vegane) wurst“