Wenn Sie CRM Online verwenden, möchten Sie ebenfalls den CRM 2013 Client für Outlook verwenden. Bei der Konfiguration der Client Integration kann es zu einem Fehler kommen, der ursächlich mit dem Office 365 Single-Sign-On Client und den Internet Explorer Einstellungen zusammenhängt.
Nach dem Download des Microsoft Dynamics CRM 2013 for Microsoft Office Outlook, müssen Sie die Outlook Verbindung zu Ihrem CRM Online Tenant mit Hilfe des CRM Konfigurationsassitenten konfigurieren.
Zu diesem Zeitpunkt der Konfiguration konnte sich der Client mit CRM Online verbinden, da das Outlook Add-In den Organisationsnamen und Anzeigenamen der Organisation erfolgreich abfragen konnte. Wenn Sie nun mit der Konfiguration fortfahren möchten, kommt es zu einem Fehler in der Kommunikation mit dem CRM Online Server.
Beispiel der Fehlermeldung: Exception : Object reference not set to an instance of an object. at Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo(String redirectEndpoint, String partner, String policy, String& postData) at Microsoft.Crm.Outlook.ClientAuth.PassportAuthProvider`1.SignIn() at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError) at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProvider(Uri endPoint, Credential credentials, AuthUIMode uiMode, Uri webEndPoint, IClientOrganizationContext context, Form parentWindow) at Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadUserId() at Microsoft.Crm.Application.Outlook.Config.ServerInfo.Initialize(Uri discoveryUri, OrganizationDetail selectedOrg, String displayName, Boolean isPrimary) at Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadDataToServerInfo() at Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__2(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
Quelle: SF-Tools, CRM 2013 for Outlook configuration fails
Die Virtualisierung von Exchange ist nicht neu und war bereits seit Exchange 2003 mit VMware eine Option, obwohl es damals von Microsoft keine offizielle Unterstützung hierzu gab. Im Rahmen des Microsoft Server Virtualization Validation Program (SVVP) wurde die Virtualisierung von Exchange 2007 Service Pack 2 auf VMware ESX 3.5 Update 2 erstmal offiziell voll unterstützt.
Mit der Veröffentlichung von Exchange Server 2010 wurden alle Serverrollen (Unified Messaging ab Exchange 2010 SP1) auf allen SVVP validierten Hypervisor-Plattformen unterstützt. Die Unterstützung der Virtualisierung von Exchange Server 2010 wurde aber nur langsam adaptiert, da dies eine grundlegende Änderung im Design und der Architektur der Systeminfrastruktur mit sich brachte. Viele Systemadministratoren misstrauten der Virtualisierung und führten häufig die fehlende "Performance" als primären Grund an, sich gegen die Virtualisierung zu entscheiden. Interessant ist, dass "Performance" als genereller Begriff verwendet wurde (wird), um die Virtualisierung von Exchange Systemen abzuwenden. Die technologische Weiterentwicklung von Exchange und die stete Reduzierung der Anforderungen an Speichermedien in Bezug auf den erforderlichen Datendurchsatz, denn diese waren in der Vergangenheit der einzige Grund, sich gegen die Virtualisierung zu entscheiden, wird teilweise immer noch ignoriert.
Mit Exchange Server 2013 können alle Rollen problemlos virtualisiert werden und ermöglichen so eine optimale Ausnutzung der Hardware-Ressourcen in Ihrem Rechenzentrum.
Trotzdem ist es erforderlich, eine Exchange Umgebung korrekt und gewissenhaft zu planen und zu berechnen. Dies hat sich mit der Virtualiserungsoption für Exchange nicht geändert. Nur mit einer gewissenhaften Planung können komplexe Änderungen der Exchange-Landschaft zu einem späteren Zeitpunkt vermieden werden. Exchange Server 2013 besteht aus folgenden Serverrollen:
Die erfolgte Reduzierung von vier Serverrollen in Exchange 2007/2010, hin zu zwei Serverrollen, wenn wir die Edge-Rolle einmal als Sonderfall betrachten, erleichtert die Konzeption einer virtualisierten Exchange-Umgebung erheblich.
Wenn es um das Thema Virtualisierung von Enterprise-Applikation geht, einmal ganz ohne den Fokus Exchange, muss immer geklärt werden, wie die Hochverfügbarkeit (HA) der Applikation gewährleistet wird. Auf der einen Seite existieren HA-Funktionen in der jeweiligen Hypervisor-Plattform selber, auf der anderen Seite stehen die HA-Funktionen der Applikationen. Naiv gesehen könnte man annehmen, dass beides zusammen das Maximum an Hochverfügbarkeit bieten würde. Dies ist jedoch nicht der Fall.
Gerade für den Fall eines Support-Calls mit Microsoft ist es wichtig, dass Exchange in einer Konfiguration betrieben wird, die auch zu 100% unterstützt wird.
Für die Virtualisierung von Exchange Server 2013 gilt es Folgendes für einzelnen Systemkomponenten zu beachten
Exchange Server 2013 kann ebenso wie Vorgängerversionen als Multi-Role Server (Mailbox- und CAS-Rolle auf einem Server) oder als Single-Role Server (Mailbox-Rolle und CAS-Rolle auf separaten Systemen) installiert werden. So wie Exchange Rollen selber aufgeteilt werden können, können auch physische und virtuelle Systeme verteilt betrieben werden.
Natürlich können (sollten) auch die benötigten Load Balancer virtualisiert betrieben werden. Die möglichen Kombinationen mit den o.g. Exchange-Konfigurationen sind zahlreich und werden in diesem Artikel vernachlässigt.
Grundsätzlich gilt die Empfehlung, für das Sizing einer Exchange 2013 Umgebung (physisch oder virtuell), den Exchange 2013 Server Role Requirements Calculator zu verwenden. An diesem Tool führt kein Weg vorbei, wenn man eine verlässliche Aussage zu den Anforderungen für die Exchange Umgebung erhalten möchte. In den aktuellsten Versionen sind notwendige Berechnungskorrekturen für die Virtualisierung bereist enthalten. Microsoft geht von einem zusätzlichen Overhead durch den Hypervisor von 10% aus. VMware wiederum geht von ca. 2% bis 5% Overhead aus.
Wie bereits erwähnt, ist eine 1:1 Zuordnung von virtuellen CPU Cores zu physischen CPU Cores zu empfehlen, da dies die Umsetzung der kalkulierten Anforderungen in den laufenden Betrieb stark vereinfacht.
Microsoft hat empfiehlt beim Einsatz von Exchange Server (2010 und 2013) auf das Hyper-Threading der CPUs zu verzichten. Wichtig ist, dass Hyper-Threading CPUs nicht gleichzusetzen sind mit physischen CPUs. Als Hauptgrund wird angegeben, dass dies die CPU Planung unnötig verkompliziere. Als zweiter Grund wird die .NET Garbage Collection angeführt, die auf Basis der CPU Anzahl arbeitet und entsprechend Arbeitsspeicher allokiert. Durch Hyper-Threading wird allerdings unnötig viel Arbeitsspeicher für die Garbage Collection reserviert.
Im Rahmen einer Virtualisierung besteht das beschriebene Problem nicht im gleichen Ausmaß, wie in einer physischen Umgebung, da der VM eine feste Anzahl an Prozessoren zugeordnet ist. Dies bedeutet, dass Sie das für Ihre Umgebung passende Processor-Ratio finden müssen, wenn Sie nicht der 1:1 Zuordnung folgen möchte. Dies gelingt am besten, indem Sie mit einer 1:1 Zuordnung beginnen und mit einer System-Monitoring Lösung eine Baseline erstellen. Anschließend passen Sie die Prozessorzuordnung an und vergleichen die Auslastung- und Performancediagramme mit der Baseline.
Die nachfolgende Tabelle listet die Mindestanforderungen an Arbeitsspeicher für Exchange Server 2013
Dies sind die absoluten Mindestanforderungen. Ohne Verwendung des Role Requirements Calculators wird eine korrekte Planung für den performanten Betrieb von Exchange nicht gelingen.
Für einen Exchange Mailbox-Server mit 1000 Postfächern mit einem Anwenderprofil von 150 gesendeten und empfangenen Nachrichten pro Tag und einer Anforderung von 36MB Datenbankcache pro Postfach, benötigen Sie bereits mindestens 36GB Arbeitsspeicher. Ergänzend zum Role Requirements Calculator empfehle ich den Blog-Artikel "Ask the Perf Guy: Sizing Exchange 2013 Deployments" (http://bit.ly/PerfGuyExchange2013Deployments).
Ergänzend zu den Speicheranforderungen für Exchange Server 2013 müssen noch 4GB bis 8GB für das Betriebssystem addiert werden.
Für die Planung der Netzwerkverbindungen der virtuellen Systeme gelten die gleichen Anforderungen wie für physische Exchange Server. Exchange Server, die nicht Mitgliedsserver einer DAG sind, können mit einem einzelnen Netzwerkadapter konfiguriert werden. Mitgliedsserver einer DAG sollten immer mit zwei Netzwerkadaptern konfiguriert werden, um die Datenbankreplikation über ein separates Netz zu leiten und vom allgemeinen Zugriff auf die Postfachdatenbanken zu trennen. Der Einsatz von einzelnen Netzwerkadaptern ist zwar unterstützt, sollte sich aber auf Test- und Laborumgebungen beschränken.
Die physischen Netzwerkadapter im Host-System können durch Teaming ausfallsicher konfiguriert werden.
Das nachfolgende Beispiel zeigt, wie ein Exchange 2013 Mailbox Server, der Mitgliedserver einer DAG ist, und ein CAS Server nur durch VLANs getrennt an einem virtuellen Switch verbunden sind. Der virtuelle Switch ist durch NIC-Teaming im Hypervisor redundant mit der physischen Netzwerk Infrastruktur verbunden.
Mit der gleichen Exchange Server-Konstellation kann aber das DAG Netzwerk-Interface zur Datenreplikation über einen separaten virtuellen Switch, der über ein eigenes NIC-Interface im Hypervisor verfügt, mit einem dedizierten Replikationsnetzwerk verbunden werden.
Die zweite Konfiguration stellt sicher, dass die Datenreplikation in einem dedizierten physischen Netzwerk stattfindet. Jedoch erhöht dieser Lösungsansatz auch die Komplexität der Netzwerkinfrastruktur selber. Hinzu kommt, dass standardmäßig das MAPI Netzwerk als Backup für einen möglichen Ausfall des Replikationsnetzwerkes verwendet wird. Wenn Sie ausschließen möchten, dass das MAPI Netzwerk als Backup-Netzwerk verwendet werden kann, müssen Sie die Hochverfügbarkeit des Replikationsnetzwerkes sicherstellen.
In VMware Umgebungen empfiehlt es sich, immer den VMXNET3 Adapter für die virtuellen Maschinen zu verwenden, da der E1000 Adapter im Host-System nur CPU 0 für die Emulation verwendet. Die Nutzung des VMXNET3 Adapters bietet somit eine deutlich bessere Performance gegenüber dem E1000 Adapter.
Ganz unabhängig von der gewählten virtuellen Netzwerkkonfiguration muss immer sichergestellt werden, dass die Host-System sowohl in der Hardware-seitigen, als auch in virtuellen Netzwerkkonfiguration identisch konfiguriert sind. Die virtuellen Gast-Systeme können schließlich nur zwischen Hosts verschoben werden, die auch die notwendigen Ressourcen (virtuelle Switche, VM Port Groups, etc.) zur Verfügung stellen.
Die Bereitstellung des notwendigen Festplattenspeichers für virtualisierte Exchange Server 2013 Systeme bietet vielfältige Optionen. Die rein physischen Optionen, wie z.B. Bereitstellung von Raw LUNs, die in einem SAN Speicher konfiguriert sind, oder VMDK, VHD/VHDX Dateien im SAN oder im DAS, oder aber die direkte Einbindung der Datastore-Volumes per iSCSI im Gast-Betriebssystem selber, unterliegen den Möglichkeiten und Anforderungen Ihrer Unternehmensumgebung. Manchmal unterliegt die Auswahl des Speichermediums aber auch internen politischen Richtlinien, durch die bestimmt wird, dass ein "teurer" SAN Speicher verwendet werden muss, obwohl dies durch die Anforderungen von Exchange Server 2013 selber gar nicht mehr notwendig ist. Eines der Arguments für die Migration zu Exchange Server 2013 ist die Unterstützung von günstigen JBOD Enclosures, die sehr große Datenspeicher sehr günstig (im Vergleich zu klassischem SAN Speicher) bereitstellen können.
Hier muss eine sehr genaue Abwägung zwischen technischem Vorteil/Nutzen und dem zusätzlichen Aufwand und der zusätzlichen Komplexität in der Umgebung für Speichersubsysteme erfolgen. Es ist meist schwierig, die Einführung einer neuen Technologie nur mit den Anforderungen einer einzigen Applikation zu begründen. Es ist hilfreich zu prüfen, ob nicht auch andere Applikationen, die in naher Zukunft migriert werden sollen (z.B. von SharePoint 2010 auf SharePoint 2013), von dem neuen Speichermedium profitieren können. Eine stärkere strategische Ausrichtung hilft bei der Argumentation sehr.
Zusammenfassend kann man sagen, dass die Virtualisierung eine große Flexibilität im Sizing und im Betrieb einer Exchange Plattform mit sich bringt. Jedoch birgt eine Virtualisierung schnell auch Risiken. Dieses Risiken wirken sich nicht unbedingt auf den sicheren Betrieb von Exchange aus, sondern vielmehr auf die Reaktionszeit, also die Performance der Exchange Umgebung.
Grundsätzlich darf man aber nicht vergessen, dass gemessene Performance nicht gleichzusetzten ist, mit subjektiv gefühlter Performance. Insbesondere Endanwender sind sehr empfindlich und reagieren kritisch, wenn "Ihr" Outlook nicht in der gleichen Zeitspanne startet, wie "gestern". Ähnlich sieht es aus, wenn Nachrichten durch mangelhafte Ressourcenverfügbarkeit zu lange in einer Warteschlange verweilen, bevor sie zugestellt werden. Auch wenn Administratoren wissen, dass E-Mail (oder besser SMTP) ein Warteschlangen-basierende Kommunikation ist, ist dies Endanwendern meist nur sehr schwer zu vermitteln.
Viel Spaß bei der Virtualisierung von Exchange Server 2013.
Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist.
Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.
Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema.
Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.
Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:
Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?
Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.
Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..
Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.
Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.
Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.
Weiterhin viel Spaß mit Exchange Server
Vom 4. - 8. November fand die diesjährige Microsoft Ignite Konferenz statt. Ein großes Thema war natürlich auch der Hybrid Betrieb von Exchange Server mit Exchange Online und die neuen Funktionen für Outlook für Desktop, Outlook für Mac, Outlook Mobile und Outlook on the Web..
Die folgenden Liste bietet einen Überblick über die wichtigsten Sessions zu diesen Themen.
Der jeweilige Link führt Sie zu den detaillierten Session-Informationen, inklusive der Session-Aufzeichnung und PowerPoint-Präsentation, falls vorhanden. Hinter jedem Titel ist der Themenlevel für die Zielgruppe vermerkt.
Intermediate (200)
Advanced (300)
TK = Technical Keynote THR = Theater Session (20 Minuten) BRK = Breakout Session (45 Minuten)
Nutzen Sie für Fragen zu den einzelnen Sessions gerne direkt die Kommentarmöglichkeit unterhalb Sessionbeschreibung. Hierzu ist allerdings eine Anmeldung erforderlich,
Für Fragen rund um Exchange, Exchange Online und Outlook stehen Ihnen die Conversation Spaces der Tech Community zur Verfügung:
Viel Spaß mit Microsoft 365, Exchange Online und Outlook.
Sie benötigen Hilfe bei der Entscheidung für oder gegen einen Wechsel zu Office 365 oder Microsoft 365? Unser Microsoft Cloud Workshop hilft Ihnen, die für Ihr Unternehmen passenden Entscheidungen zu treffen. Melden Sie sich bei uns: info@granikos.eu
Manchmal ist es notwendig, das Offline Adressbuch (OAB) für den Outlook E-Mail Client manuell herunterzuladen.
Kommt es beim Herunterladen des OAB zu einem Fehler, in diesem Fall 0x80200051, wird durch den First-Line Support gerne zwischen dem Online- und dem Cached-Modus von Outlook hin und her gewechselt. Leider behebt dieses Vorgehen den Fehler nicht.
Nach dem erneuten Aktivieren des Cached-Modus, muss das OAB vollständig neu heruntergeladen werden. Leider ist im Outlook-Diaglog zum manuellen Download des OAB die Checkbox "Änderungen seit der letzten Übermittlung herunterladen" standardmäßig aktiv. Diese Option muss abgewählt werden, um einen vollständigen Download es OAB durchführen zu lassen.
Mit dieser Download-Einstellung kommt es nicht mehr zu einem Fehler.
Viel Spaß mit Outlook.
Die Installation des Windows Features Active Directory Domains Services (AD DS) kann fehlschlagen.
Bei der Installation per PowerShell kommt es zu folgendem Fehler:
Install-WindowsFeature -Name AD-Domain-Services Install-WindowsFeature : The request to add or remove features on the specified server failed. The operation cannot be completed, because the server that you specified requires a restart. At line:1 char:1 + Install-WindowsFeature -Name AD-Domain-Services + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exce ption + FullyQualifiedErrorId : DISMAPI_Error__Failed_Reboot_Required,Microsoft.Windows.ServerManager.Commands.AddWindow sFeatureCommand Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- False No Failed {}
Das ganze sieht erstmal danach aus, dass es sich um ein VMWare Problem handelt. "+ CategoryInfo: DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exception" und das noch ein Reboot aussteht "because the server that you specified requires a restart."
Dem ist leider nicht so. Auch nach mehrfachem Neustart des Servers, bleibt es bei der gleichen Fehlermeldung.
Ein Blick ins EventLog zeigt, es gibt eine Abhängigkeit zwischen dem Dienst "DFS Namespace" und "Remote Registry".
Der "Remote Registry" Dienst konnte nicht gestartet werden, da dieser deaktiviert war.
Dieser Dienst war in der VM Vorlage deaktiviert.
Nach Umstellung auf Automatisch und einem Reboot ließ sich das Windows-Feature AD DS fehlerfrei installieren und der Server zum Domain Controller hochstufen.
Im Gegensatz zu vorherigen Versionen von Exchange Server, wo Update Rollups relative kleine Installationspakete darstellten, kommt die Installation von Cumulativen Updates (CU) bei Exchange Server 2013 faktisch einer Neuinstallation gleich. Hierdurch ergibt sich ein ganz anderer Planungsaufwand für die Durchführung eines Upgrades, sowohl in zeitlicher wie auch in ressourcentechnischer Hinsicht. Erstellen Sie sich eine zeitliche Baseline, um die erforderliche Zeit für die CU Installationen in Ihre Wartungspläne zu integrieren.
Wenn Sie auf einem Exchange 2013 Server ein CU installieren möchten, müssen die anderen Exchange Server wissen, dass ein Upgrade durchgeführt wird. Wenn Sie den entsprechenden Server nicht als "in Wartung" kennzeichnen, wird der Primary Activation Manager (PAM) der Database Availability Group (DAG) im Fehlerfall versuchen, auf dem im Upgrade befindlichen Server passiven Datenbank aktiv in Betrieb zu nehmen. Dies wird mit sehr großer Wahrscheinlich zu einem unfreiwilligen Test Ihres Desaster Recovery Plans führen.
Die folgenden Schritte beschreiben die Aktivierung und Deaktivierung der Wartung.
Vor dem Aktivieren der Wartung gilt es einige Vorbereitungen zu treffen, um unnötige Fehlersituationen des Exchange 2013 Setups zu vermeiden.
Prüfung Festplattenplatz
Auf dem Laufwerk der Exchange Server 2013 Installation, müssen ca. 10 GB freier Festplattenplatz zur Verfügung stehen. Sollte auf dem Laufwerk weniger Platz zur Verfügung stehen, müssen Sie diesen Platz zuerst sicherstellen.
Prüfung PowerShell Execution Policy
Wird auf dem Exchange Server die MachinePolicy per Gruppenrichtlinie (GPO) gesetzt, wird es beim Ausführen des Exchange Setups zu einem Fehler kommen.
Prüfung der aktuellen Konfiguration erfolgt mit Get-ExecutionPolicy -List.
Ist die MachinePolicy konfiguriert, so kann die Policy für die Installation mit folgendem PowerShell Befehl (Berechtigung vorausgesetzt) auf nicht konfiguriert gesetzt werden.
Get-ExecutionPolicy -List Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell -Name ExecutionPolicy -Value ""
Starten Sie die Exchange Management Shell als Adminstrator und prüfen Sie zuerst den aktuellen Status aller Serverkomponenten. Bei dieser Abfrage müssen alle Komponenten auf active stehen. Anschließend werden die Komponenten Hub Transport und UM Call Router auf Draining gesetzt. Dies Ausführung als Administrator ist erforderlich, da in den PowerShell Scripten StartDAGMaintenance und StopDAGMaintenance auch Cluster Befehle ausgeführt werden.
Get-ServerComponentState [SERVERNAME] Set-ServerComponentState [SERVERNAME] –Component HubTransport –State Draining –Requester Maintenance Set-ServerComponentState [SERVERNAME] –Component UMCallRouter –State Draining –Requester Maintenance
Verschieben Sie eventuell noch vorhandene Nachrichten im Transport Service auf einen anderen Transport Server.
Redirect-Message –Server [SOURCESERVER FQDN] –Target [TARGETSERVER FQDN]
Nach diesen Schritten wird der Server in DAG Maintenance gesetzt. Sollten Ihre DAG nur aus zwei Datenbankkopien bestehen, ergänzen Sie den Aufrud des PowerShel Scripts um den Switch Parameter -overrideMinimumTwoCopies.
cd $ExScripts .\StartDAGServerMaintenance.ps1 [SERVERNAME] Get-MailboxDatabaseCopyStatus -Server [SERVERNAME]
Setzen Sie nun alle Komponenten in serverweite Wartung.
Set-ServerComponentState [SERVERNAME] –Component ServerWideOffline –State Inactive –Requester Maintenance
Wenn alle Serverkomponeten auf Wartung gesetzt sind, kann die Installation des Cumulative Updates erfolgen. Schließen Sie die Exchange Management Shell und starten Sie ein neues PowerShell Fenster als Administrator. Wechseln Sie in das Verzeichnis des entpackten Exchange 2013 CU und starten Sie das Setup.
.\setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms
Nach Ablauf des ersten Teils der Installation werden Sie aufgefordert, den Server neu zu starten. Nach erfolgreichem Neustart und erfolgter Anmeldung, starten Sie ein neues PowerShell Fenster als Administrator, wechseln erneut in das Verzeichnis des entpackten Exchange 2013 CU und starten Sie das Setup.
Nach erfolgreichem Setup von Exchange ist kein erneuter Start des Servers erforderlich.
Prüfen Sie die Version der Exchange Server.
Get-ExchangeServer | ft Name, Admin*
Nach erfolgter Installation des Exchange Server 2013 CU muss der Exchange Server aus der Wartung genommen werden, um wieder Verbindungen annehmen zu können.
Set-ServerComponentState [SERVERNAME] -Component ServerWideOffline -State Active -Requester Maintenance Get-ServerComponentState [SERVERNAME]
Wenn Sie die beiden Komponenten Hub Transport und UM Call Router in Draining gesetzt haben, werden diese beiden Komponenten separat wieder aktiviert.
Set-ServerComponentState [SERVERNAME] -Component UMCallRouter -State Active -Requester Maintenance Set-ServerComponentState [SERVERNAME] -Component HuBTransport -State Active -Requester Maintenance Get-ServerComponentState [SERVERNAME]
Anschließend wird die DAG Wartung beendet.
cd $ExScripts .\StopDAGServerMaintenance.ps1 [SERVERNAME] Get-MailboxDatabaseCopyStatus -Server [SERVERNAME]
Und nun heisst es warten auf das nächste CU für Exchange Server 2013.
Gerne unterstützen wir Sie bei der Planung und Umsetzung Ihrer Exchange Server 2013 Anforderungen und der Anbindung an Office 365. Kontaktieren Sie uns: info@granikos.eu Erfahren Sie mehr über unsere Beratungsdienstleistungen unter http://www.Granikos.eu.