Alle Beiträge von johannes

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!

Description

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: 'pdc.example.com', Bevorzugter globaler Katalog: 'pdc.example.com', Bevorzugte Domänencontroller: '{ pdc.example.com }'
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 'pdc.example.com'.
[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:

Get-OwaVirtualDirectory
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 
   urationTasks.RemoveOwaVirtualDirectory
    + PSComputerName        : Exch16.example.com

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
CN=Configuration,DC=example,DC=com

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
gKDigKDigKDigKDigKDigKDigKDigKDigKDigKDigKDmhKA6Q049b3dhIChEZWZhdWx0IFdlYiBT
aXRlKSxDTj1IVFRQLENOPVByb3RvY29scyxDTj1FWENIMTYsQ049U2VydmVycyxDTj1FeGNoYW5n
ZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoQUJDREVGR0gxMklKS0xNKSxDTj1BZG1pbmlzdHJhdGl2
ZSBHcm91cHMsQ049Rmlyc3QgT3JnYW5pemF0aW9uLENOPU1pY3Jvc29mdCBFeGNoYW5nZSxDTj1T
ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWV4YW1wbGUsREM9Y29t=

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 “https://exch16.example.com/owa” -ExternalUrl “https://mail.example.com/owa”
 
Name                             Server                           OwaVersion
----                             ------                           ----------
owa (Default Web Site)           EXCH16                          Exchange2013
 
New-OwaVirtualDirectory  -InternalUrl “https://exch16.example.com/owa” -ExternalUrl “https://mail.example.com/owa” -WebSiteName “Exchange Back End”
 
Name                             Server                           OwaVersion
----                             ------                           ----------
owa (Default Web Site)           EXCH16                          Exchange2013
 
Get-OwaVirtualDirectory
 
Name                             Server                           OwaVersion
----                             ------                           ----------
owa (Default Web Site)           EXCH16                          Exchange2013

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

Get-OwaMailboxPolicy
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
   MailboxPolicy
    + PSComputerName        : exch16.example.com

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:

Remove-OwaMailboxPolicy
New-OwaMailboxPolicy -Name Default

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

Environment

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!

<include>
  <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="wia-sip-proxy.ngn.versatel.de"/>
    <param name="outbound-proxy" value="wia-sip-proxy.ngn.versatel.de"/>
 
    <!--/// 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"/>-->
  </gateway>
  <!--rfc5626 : Abilitazione rfc5626 ///-->
  <!--<param name="rfc-5626" value="true"/>-->
  <!--rfc5626 : extra sip params to send in the contact-->
  <!--<param name="reg-id" value="1"/>-->
</include>

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…

/etc/asterisk/sip.conf:

register => 0049301234567:bu!Msuf5@versatel.sip/0049301234567
 
[0049301234567]
type=peer
host=62.214.36.241
outboundproxy=versatel.sip
realm=versatel.sip
proxy=versatel.sip
registrar=versatel.sip
port=5060
context=isdn-incoming
defaultuser=0049301234567
fromuser=0049301234567
username=0049301234567
secret=bu!Msuf5
dtmfmode=rfc2833
insecure=port,invite
canreinvite=no
registertimeout=600
disallow=all
allow=alaw
allow=ulaw

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

62.214.36.241   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:

ALTER TABLE radacct
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

mysql.cnf

[client]
host = localhost
user = root
password = kennwort
 
[mysqldump]
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%
 
d:
cd %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 example.com.crt -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.: https://www.huque.com/bin/danecheck oder https://dane.sys4.de/

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.: https://de.ssl-tools.net/tlsa-generator)

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:

#!/bin/bash
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 gruppe04.de

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.abc, irgendwas.lan usw.  werden  durch CAs nicht mehr ausgestellt

Also: „Umbenennen“ des Servers exchange.example.local nach exchange.example.com, 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="https://exchange.example.com/autodiscover/autodiscover.xml" rel="nofollow">https://exchange.example.com/autodiscover/autodiscover.xml</a>

EWS URL

Anpassung der InternalURL

 Set-WebServicesVirtualDirectory -Identity "Your_Server_Name\EWS (Default Web Site)" -InternalUrl <a class="external free" href="https://exchange.example.com/ews/exchange.asmx" rel="nofollow">https://exchange.example.com/ews/exchange.asmx</a>

OAB URL

Anpassen der InternalURL

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

 UM Web URL

Falls verwendet: Anpassen der UM Web InternalURL

 Set-UMVirtualDirectory -Identity “Your_Server_Name\unifiedmessaging (Default Web Site)-InternalUrl <a class="external free" href="https://exchange.example.com/unifiedmessaging/service.asmx" rel="nofollow">https://exchange.example.com/unifiedmessaging/service.asmx</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

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/hostname.sh stop
  2. echo fliege.home.example.org > /etc/mailname
  3. echo fliege > /etc/hostname
  4. in der /etc/hosts „192.168.102.12   fliege.home.example.org fliege“
  5. /etc/init.d/hostname.sh start

Danach sollte sich die Maschine wie folgt verhalten:

fliege:~# hostname
fliege
fliege:~# hostname -f
fliege.home.example.org

Wirklich ausschlaggebend ist eigentlich nur die /etc/hosts

127.0.0.1       localhost.localdomain localhost
192.168.102.12   fliege.home.example.org 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

regedit
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 „https://mail.example.com/owa/auth.owa“ 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 192.168.0.7:64337.  —> System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden  da der Zielcomputer die Verbindung verweigerte 192.168.0.77:64337    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 (http://exchangeserverpro.com/exchange-2013-client-access-server-high-availability/) 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*

Guid
—-
abbbb120-a4567-890a-bcde-f01234567ae2

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“