Exchange 2010 SP3

Unified Communications Consultant m/w
Komm in unser Team bei Net at Work. Bewirb dich jetzt bei uns.
http://www.netatwork.de/jobs.htm#LyncCon

Auch bei Net at Work installieren wir Service Packs von Produkten zeitnah, wenngleich nicht "sofort" nach Erscheinen. Aber auch wir wollen nach Exchange 2013 migrieren und damit ist Exchange 2010 SP3 nun mal eine Voraussetzung. Normal ist eine Service Pack Installation auf einem "Single Server" mit allen Rollen nicht besonders anspruchsvoll aber diesmal hat es mich etwas mehr Zeit gekostet. Und das hatte mehrere Gründe. Ein Teil davon ist schon auf Servicepack:E2010 und Servicepack E2010 SP2 beschrieben.

Vorabinformationen

Am 12. Feb hat Microsoft gleich zwei Update für Exchange 2010 released. Sie haben nun also die Wahl, ob Sie gleich das brandneue Exchange 2010 SP3 installieren, was für die spätere Migration nach Exchange 2013 Voraussetzung ist oder erst das SP2RU6 installieren, um die bekannten Fehler hierzu zu entfernen.

Achtung:
Die Koexistenz mit Exchange 2013 ist erst mit einem CU1 für Exchange 2013 möglich. Siehe E2013

Das Servicepack 3 soll aber auch alle Fixes schon enthalten. Größte Änderungen sind:

  • Exchange 2010 kann nun auf Windows 2012 installiert werden
    Aber sie können ein Windows 2008 nicht "inplace" auf Windows 2012 aktualisieren
  • Internet Explorer 10 als Client für OWA/ECP ist nun unterstützt
  • Diverse Fixes

Achtung
Einige Einstellungen werden bei der Installation des SP3 wieder auf Standards zurück gestellt, z.B. der SSL-Zwang auf das Basisverzeichnis des IIS. Wer also eine HTTP->HTTPS Umleitung nicht über die IIS-Fehlerseite 403.4 gemacht hat oder ein Loadbalancer einen HTTP-Test macht, muss nachkonfigurieren.

Hier die weiteren Links, die ein seriöser Exchange Admin natürlich vor der Installation durchgelesen hat.

Exchange 2010 SP3 (549 MB). Alle Sprachen haben das gleiche File
http://www.microsoft.com/en-us/download/details.aspx?id=36768

UM-Sprachpakete für Exchange Server 2010 SP3
http://www.microsoft.com/de-de/download/details.aspx?id=36769

Hinweis für SBS 2011 Server
Hier liest das Setup den >Registrierungsschlüssel "HKEY_LOCAL_MACHINE/Software/Microsoft/SmallBusinesServer/Networking/LeafCertThumbprint". Der Thumbprint kann aber schon von einem abgelaufenen Zertifikat sein. Einfach den Wert löschen und das Setup neu starten

SBS 2011 Exchange 2010 SP3 "Cannot find the SBS certificate"
http://www.pcxpress.de/pcxblog-ein-blog/item/sbs-2011-exchange-2010-sp3

Aktuell habe ich noch keine Quelle für die entsprechenden UM Language Packs. Hier ein paar Eindrücke der eigenen Installation

Schema Erweiterung

Hinweis: Das Exchange 2010 SP3 macht eine Schemaerweiterung. Darauf weist das Setup auch explizit hin, wenn der angemeldete Benutzer nicht die erforderlichen Rechte hat:

Wenn Sie vorher schon Exchange 2010 SP2 hatten, dann ist diese Erweiterung nur noch minimal. für größere Firmen mit mehreren Domänen und delegierten Administrationsrechten bedeutet das aber doch wieder eine Vorarbeit.

Cluster Hotfix

Es gibt Updates, bei denen bin ich nicht sicher, warum Microsoft diese nicht zumindest als "Optional" über Windows Update anbietet. Dann müsste man nicht die Produktblogs lesen oder auf das nächste Servicepack-Setup warten, dass es eine wesentliche Korrektur gibt, auf das das Exchange 2010 SP3 explizit hinweist:

Und beim Einsatz eines Clusters wird dringend dazu geraten, den Hotfix 2550886 zu installieren.

Interessanterweise kommt die Meldung auch auf einem "Single Server", der nicht in einer DAG betrieben wird.

Unified Messaging

Wenn der Server auch "UM-Server" ist, dann dürfen Sie vorher wieder einmal die Language-Packs deinstallieren. Das Exchange Service Pack Setup kann nicht selbst damit umgehen, wenn das UM Language Packs installiert sind.

Es ist natürlich verständlich, dass Microsoft das 500MB Archiv des SP3 nicht noch durch alle UM Language Packs erweitern will. Diese müssen Sie manuell herunter laden. Aber damit kann das Setup auch nicht davon ausgehen, dass eben diese Language Packs auch zur automatischen Deinstallation vorliegen. Nutzen Sie dazu das SETUP.COM aus dem aktuellen Service Pack mit der Option "/RemoveUMLanguagepack:DE-DE".

c:\temp\ex2010sp3\setup.com /removeumlanguagepack:de-de

Nach der Installation des Service Pack 3 gilt es natürlich wieder die aktuellen Language Packs des SP3 zu installieren:

setup.com /addumlanguagepack:de-de /s:c:\temp

Hier muss im Verzeichnis C:\Temp die Datei "UMLanguagePack.de-DE.exe" liegen.

Verdruss mit %ExchangeSetupPath%

Etwas unschöner waren die Effekte, dass das Setup gar nicht zum Ende gekommen ist, weil der IIS die ganzen Exchange Applikationen nicht starten konnte und im Eventlog alles rot war:

Log Name:      Application
Source:        ASP.NET 2.0.50727.0
Date:          11.04.2013 00:46:13
Event ID:      1310
Task Category: Web Event
Level:         Warning
Keywords:      Classic
Computer:      NAWEX001.netatwork.de
Description:
  Event code: 3008  Event message: A configuration error has occurred.  
  Event time: 11.04.2013 00:46:13  
  Event time (UTC): 10.04.2013 22:46:13  
  Event ID: 72af8a2762884297881a938b9a7fc55e
  Event sequence: 1
  Event occurrence: 1
  Event detail code: 0
     Application information:
      Application domain: /LM/W3SVC/1/ROOT/PowerShell-1-130101075730422188
      Trust level: Full
      Application Virtual Path: /PowerShell
      Application Path: C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell\
      Machine name: NAWEX001
    Process information:
      Process ID: 1580
      Process name: w3wp.exe
      Account name: NT AUTHORITY\SYSTEM
    Exception information:
      Exception type: ConfigurationErrorsException
      Exception message: Could not load file or assembly 'Microsoft.Exchange.Configuration.RedirectionModule, 
           Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. 
           The system cannot find the file specified. (C:\Program Files\Microsoft\Exchange Server\V14\
               ClientAccess\PowerShell\web.config line 42)
    Request information:
      Request URL: http://nawex001.netatwork.de/PowerShell?PSVersion=3.0
      Request path: /PowerShell user host address: 192.168.100.59
Log Name:      Application
Source:        Microsoft-Windows-IIS-W3SVC-WP
Event ID:      2280
Level:         Error
Keywords:      Classic
Computer:      NAWEX001.netatwork.de
Description:
The Module DLL C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll
failed to load.  The data is the error.

Nach etwas stöbern im Internet und den web.config-Dateien habe ich gesehen, dass viele Pfade mit einer Umgebungsvariable versehen waren.

<codeBase version="0.0.0.0" href="file:///%ExchangeInstallDir%bin\Microsoft.Exchange.EdgeSync.Common.dll "/>

Ich war mir nicht sicher, ob das überhaupt gehen kann, denn diese Umgebungsvariable gibt es nicht. Es gibt sehr wohl eine globale Variable %ExchangeInstallPath% (Siehe auch Exchange Pfade). Ich habe dann in anderen Exchange 2010 Installationen nachgeschaut und dort standen absolute Pfade wie hier:

<codeBase version="0.0.0.0" href="file:///C:\Program Files\Microsoft\Exchange 
erver\bin\Microsoft.Exchange.EdgeSync.Common.dll"/>

Es gibt wohl hinweise, dass bei Exchange 2007 SP1 RU4 ein Bug ist, bei dem das Setup vergisst die Strings zu ersetzen aber der Server hatte nie Exchange 2007.

Ich weiß nicht, wann das Setup diese Ersetzung macht, aber mit Notepad++ ist es sehr einfach in ganz vielen Dateien solche Inhalte auf einmal zu ersetzen.

Damit waren dann alle Fehler im Eventlog zum IIS verschwunden und die meisten Webapplikationen liefen.

ACLs auf Dateien

Es will ja mal wieder niemand gewesen sein, aber einen Eventlogeintrag konnte ich damit doch noch nicht lösen.

Log Name:      Application
Source:        Microsoft-Windows-IIS-W3SVC-WP
Event ID:      2280
Level:         Error
Keywords:      Classic
Computer:      NAWEX001.netatwork.de
Description:
The Module DLL C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\
Owa\auth\exppw.dll failed to load.  The data is the error.

Sie können gut sehen, dass der Pfad "korrekt" ist und eine Kontrolle über den Windows Explorer hat gezeigt, dass die Datei auch vorhanden war. Aber erst eine Kontrolle der ACLs hat gezeigt, dass "Authentifizierte user:Read" hatten. Auf meinen Referenz-VM hingegen hatte dieser Kreis "READ/EXECUTE". Damit ist klar, dass der IIS die Datei zwar lesen aber nicht ausführen darf. Ich habe dann gleich einige weitere Verzeichnisse auf ihre ACLs überprüft und bin auch bei OWAUTH fündig geworden. So muss es richtig sein:

Nach diesen Korrekturen konnte der IIS auch wieder die Dateien zum Ausführen laden und die Webdienste anbieten. Leider kann ich nachträglich nicht mehr nachvollziehen, wann wer die Rechte verändert hat und ob andere Verzeichnisse auch noch betroffen sind. Aber da der Server nach der Migration nach Exchange 2013 ehr entfällt, werde ich da nun nicht weiter nachforschen.

Virenscanner (hier MsMpEng.exe)

Eigentlich sind Virenscanner eine wichtige und erforderliche Komponente eines Server. Aber bei einem Installationsschritte hat Exchange SEHR lange benötigt. Das ist besonders nervig, wenn man quasi "davor" steht und wartet.

Eine Kontrolle der Datei "C:\ExchangeSetupLogs\ExchangeSetup.log" hat nichts ergeben. Da wurde nicht protokolliert. Das muss natürlich weiter untersucht werden. Mit Sysinternals ProcMon konnte ich sehen, welche Dateien das Setup nutzt und so bin ich zum Ergebnis gekommen, dass das Exchange Setup hier die Performance Counter durch neuere Versionen ersetzt. Damit machen auch die Einträge im Eventlog Sinn. Erst die Entfernung:

Log Name:      Application
Source:        Microsoft-Windows-LoadPerf
Date:          11.04.2013 08:22:24
Event ID:      1001
Task Category: None
Level:         Information
Keywords: user:          NETATWORK\Administrator
Computer:      NAWEX001.netatwork.de
Description:
Performance counters für the msexchange assistants - per database (msexchange assistants - per database) 
service were removed successfully. The Record Data contains the new values of the system Last Counter 
and Last Help registry entries.

Und dann wieder das addieren:

Log Name:      Application
Source:        Microsoft-Windows-LoadPerf
Date:          11.04.2013 08:22:25
Event ID:      1000
Task Category: None
Level:         Information
Keywords: user:          NETATWORK\Administrator
Computer:      NAWEX001.netatwork.de
Description:
Performance counters für the MSExchange Assistants - Per Database (MSExchange Assistants - Per Database) 
service were loaded successfully. The Record Data in the data section contains the new index 
values assigned to this service.

Und das geht eine ganze Zeit lang so und es werden jede Menge INI-Dateien gelesen und geschrieben. Zusammen mit dem "Microsoft AntiMalware Service" (Task:MsMpEngG.EXE") war der Server hoch belastet und denkbar langsam. Hier bei 50% einer VM mit zwei CPUs.

Anscheinend hat diese Kombination das System deutlich ausgebremst, als wenn der Virenscanner den Zugriff der Applikation verzögert hat, bis die Datei geprüft wurde. Erst als ich den Realtime-Scan zumindest temporär deaktiviert habe, war die Bremse gelöst.

Aus den 50 Minuten wurden 11 Minuten. Natürlich sollte das kein Dauerzustand sein, aber für eine beschleunigte Installation kann man das schon mal tolerieren. Sie sollten dann natürlich keine weiteren Download o.ä. auf dem Server starten.

PendingFileRenameOperations

Bei fast allen Exchange 2010 SP3 Installationen forderte mich Exchange am Ende NICHT zu einem Neustart auf. Das ist löblich, weil es die Downtime minimiert aber Exchange hat doch noch eine Überraschung hinterlassen, die Folgeinstallationen (z.B. UMLanguagePack) behindern können.

Ursache sind Reste im Schlüssel HKCM\System\CurrentControlSet\Control\Sessionmanager\PendingFileRenameOperations. Hier können Programme Einträge addieren, über die Windows beim Neustart z.B. ansonsten noch gesperrte Dateien löscht oder durch neuere Versionen ersetzt.

Die Zeilen sind immer paarweise vorhanden, wobei die erste Zeile ist immer die zu löschende Datei ist und die zweite Zeile die Datei, die den Platz der ersten Datei einnimmt. Ist die zweite Zeile leer, dann wird die Datei einfach nur gelöscht. Wer das weiß und absehen kann, dass die ausstehenden Änderungen keinen Einfluss haben, dann den Schlüssel temporär umbenennen und das Setup ohne Neustart durchführen. Sie sollten danach aber die Änderungen wieder rückgängig machen und wenn das Setup selbst einen neuen Schlüssel angelegt hat, dann müssen Sie die Einträge zusammenführen.

Abschluss

Ich hoffe, dass Sie bei der Installation von Exchange 2010 SP3 auf deutlich weniger Probleme stoßen werden. Aber planen Sie auf jeden Fall "Reserve" ein und erwarten Sie nicht, dass das SP3 mal eben schnell installiert werden kann. Sie können nie wissen, welche andere Komponenten ihnen Knüppel zwischen die Beine werfen. Ich hatte mir 2 Stunden von 22:00-23:59 vorgenommen und letztlich habe ich mir die Nacht um die Ohren geschlagen, damit der Server wieder lief.

Von Vorteil war natürlich, dass kein Datenverlust zu befürchten war und selbst bei einem komplett neu aufzubauenden Server (Desasterfall) die EDB-Dateien in der aktuellen Version immer noch vorlagen. Die Besonderheiten mit dem Ersetzen von Exchange Pfaden in den verschiedenen WEB.CONFIG-Dateien war mit bislang aber ebenso wenig geläufig wie die Umgebungsvariable. Mit jedem Tage lerne ich auch weiter dazu.

Weitere Links