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.
- Released: Exchange Server
2010 SP3
http://blogs.technet.com/b/exchange/archive/2013/02/12/released-exchange-server-2010-sp3.aspx -
What’s New
http://technet.microsoft.com/en-us/library/jj965775(v=exchg.141).aspx -
Release Notes
http://technet.microsoft.com/en-us/library/jj965774(v=exchg.141).aspx -
Exchange Server 2013 Reaches
General Availability (3 Dec
2012)
http://blogs.technet.com/b/exchange/archive/2012/12/03/exchange-server-2013-reaches-general-availability.aspx -
Announcing Exchange 2010 Service
Pack 3 (25. Sep 2012 !)
http://blogs.technet.com/b/exchange/archive/2012/09/25/announcing-exchange-2010-service-pack-3.aspx - 2837926 "File check failed : Logfile 'f:\logs\DB\Enn.log' is generation 2024" error when you activate a passive copy of an Exchange Server 2010 SP3 database
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.
- 2550886 A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working
- Recommended Windows Hotfix für Database Availability Groups
running Windows Server 2008 R2
http://blogs.technet.com/b/exchange/archive/2011/11/20/recommended-windows-hotfix-for-database-availability-groups-running-windows-server-2008-r2.aspx
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.
- INFO: Update Rollup 4 für Exchange Server 2007 Service
Pack 1
http://blogs.technet.com/b/exchange/archive/2008/09/11/3406233.aspx
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: MSXFAQ\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: MSXFAQ\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.
- Why is MsMpEng.exe using so
much CPU
http://social.technet.microsoft.com/Forums/en-US/Forefrontclientgeneral/thread/8ee4a53e-2ae7-4e91-9ac9-173ee3b12650/ - Microsoft Security
Essentials und 100%
CPU-Auslastung
http://www.anonym-surfen.com/microsoft-security-essentials-und-100-prozent-cpu-auslastung/
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.