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“