Die Präsentation zum Thema "Über die Notwendigkeit einer (Langzeit-) Archivierungslösung" wurde aktualisiert.
Hauptpunkte der Präsentation
Die Dienste von Microsoft 365 machen es Anwender leicht, sich mit Ihrer beruflichen E-Mail-Adresse anzumelden. Anwender werden regelrecht dazu verführt, eine für sie interessante Lösung auszuprobieren.
Lösungen wie Microsoft Teams, Power BI und andere benötigen für ihre Funktion Azure AD und damit einen Microsoft 365 Mandanten. Wenn sich nun ein Anwender mit einer beruflichen E-Mail-Adresse bei einer ausgewählten Lösung anmeldet, ob die E-Mail-Domäne bereits eine, existierenden Mandaten zugeordnet ist. Ist dies der Fall, erfolgt die Authentifizierung und weitere Nutzung auf Basis der Einstellungen des entsprechenden Mandanten.
Was aber passiert, wenn die E-Mail-Domäne keinem Mandanten zugeordnet ist?
In diesem Fall erstellt Microsoft 365 einen sog. Schattenmandanten, dem die E-Mail-Domäne des Anwender als Schattendomäne zugeordnet wird. Hierzu erhält der Anwender kein Feedback, da die Nutzung der ausgewählten Lösung im Vordergrund steht.
Das Problem einer Schattendomäne trifft Sie, als Administrator eines Microsoft 365 Mandanten erst dann, wenn Sie diese Domäne einem regulär aktiviertem Mandanten hinzufügen möchten. Oder wenn Sie dies als Berater für einen Ihrer Kunden durchführen möchten. In diesem Fall führt Sie der Einrichtungsassistent des Microsoft 365 Admin Centers zu einem Übernahmeprozess der Domäne per E-Mail.
In diesem Prozess kann aus ganz unterschiedlichen Gründen zu Problemen kommen. Einfacher ist es, die Schattendomäne mit Hilfe von PowerShell zu übernehmen. Hierzu benötigen Sie das MSOnline-PowerShell Modul und Zugriff auf die DNS-Verwaltung der betroffenen Domäne.
Führend Sie folgenden Schritte durch.
# Falls nicht installiert Install-Module -Name MSOnline # Falls installiert Update-Module MSOnline -Force # Anmeldung am Microsoft 365 Mandanten als globaler Administrator Connect-MSOnline # Hinzufügen der Schattendomäne (Beispiel varunagroup.de) New-MSOLDomain -Name varunagroup.de # Prüfung des Domain Status der nicht verifizierten Domäne Get-MSOLDomain # Abfrage des Wertes zur Überprüfung per TXT-Eintrag Get-MSOLDomainVerificationDns -DomainName varunagroup.de -Mode DnsTxtRecord
Als Ausgabe erhalten Sie die Informationen für einen TXT-Eintrag in der Form MS=xxxxxxx. Dieser Wert muss in der DNS-Verwaltung als namenloser TXT-Eintrag für die Schattendomäne eingetragen werden. Geben Sie den DNS-Servern ein paar Minuten Zeit, um die Änderung zu übernehmen.
Führen Sie nun in der gleichen PowerShell-Session die Überprüfung des TXT-Eintrages durch. Wichtig ist hierbei der zusätzliche Parameter ForceTakeOver.
# Überprüfung des DNS-Eintrages und Übernahme der Domäne Confirm-MSOLDomain -DomainName varunagroup.de -ForceTakeover Force # Prüfung des Domain-Status Get-MSOLDomain
Die Prüfung kann einen Moment Zeit in Anspruch nehmen. Der Status der neuen Domäne muss von Unverified zu Verfied wechseln.
Damit haben Sie eine Schattendomäne übernommen und zu einem bestehenden Mandanten hinzugefügt.
Viel Spaß mit Microsoft 365!
"Zu wissen, was man weiß, und zu wissen, was man tut, das ist Wissen."
Seit den Zeiten von Konfuzius ist dies eine der Maximen über Wissen an sich und hat auch seine ganz eigene Bedeutung in der heutigen IT und dem strategischen Betrieb von komplexen und sicheren IT-Umgebungen.
Die größte Gefahr in jeder IT-Umgebung ist somit das Unwissen. Nach der Identifikation eines Problems und dem Finden der Ursache, verbleibt nur das Auffinden von technischen Ressourcen, um das Problem zu beseitigen. Um das zu erreichen und um die organisatorischen Geschäftsanforderungen voranzutreiben, benötigen Unternehmen eine intelligente Sicht auf das große Ganze. Oder ganz einfach: Enterprise IT ist auf solide Berichterstattung angewiesen.
Es gibt im IT-Portfolio eines Unternehmens keine Dienstleitung, die ähnlich wichtig ist, wie E-Mail (ergänzt durch Exchange und Active Directory Datenbanken). Für die meisten Unternehmen ist E-Mail die wichtigste Kommunikationsart und damit die Lebensader für einen erfolgreichen Betrieb. Leider übersehen viele IT-Verantwortliche wichtige E-Mail bezogene Themen, die sich auf die Produktivität, betriebliche Effizienz und letztlich auf die Rentabilität des Unternehmens auswirken. Zahlreiche Herausforderungen, wie Ausfälle und Service-Optimierungen, Sicherheitswarnungen und Speicherengpässe, wirken sich in ganzer Linie auf den Betrieb des Unternehmens aus. Ohne messbare KPIs für solch kritische Applikationen versuchen Unternehmen eine große Unbekannte zu verwalten. Sie fliegen sozusagen blind.
Im Fall von Exchange muss eine Berichterstattung drei Themenbereiche abdecken, um einen produktiven und effizienten Betrieb zu unterstützen:
Eine Berichterstattung über Exchange ist kein monolithisches Gebilde, vielmehr erfordert eine produktive Berichterstattung unterschiedliche Detailierungsebenen, um alle notwendigen Informationen für schnellere und bessere Entscheidungen bereitzustellen. Zum Beispiel ist für einen CIO nicht von Vorteil, wenn er Kenntnis darüber hat, dass ein bestimmter Benutzer das Postfachlimit überschritten hat. Diese Information ist für Service-Desk Mitarbeiter viel sinnvoller. Die generelle Information aber, wie viele Nutzer das Limit überschritten haben, hilft bei der strategischen Planung und Budget-Entscheidungen für die IT-Infrastruktur.
Mit Hilfe einer Rollen-basierten Berichterstellung erhalten die Mitglieder einer Rolle genau die Informationen, die sie für Ihre speziellen Aufgaben benötigen. Dies vereinfacht zum einen die Arbeit der Mitarbeiter selber und stellt zum anderen sicher, dass keine unnötigen oder unerlaubten Daten im Zugriff sind.
Ein weiteres Problem heutiger Berichterstattung in der IT ist, dass zahlreiche Berichte automatisch erstellt und per E-Mail an unterschiedliche Empfänger zugestellt werden. Dort werden sie meist durch Postfachregeln automatisch in Unterordner sortiert und harren dort aus, um gelesen zu werden. Die Informationen sind zum Zeitpunkt des Lesens bereits wieder veraltet und stellen nur einen alten, bereits vergangenen, Betriebszustand dar, und nicht den aktuellen Betriebszustand.
Jenseits dieser eher abstrakten Darstellungen folgen nun zwei reelle Anwendungsbeispiele:
Was ist mit der Identifizierung fragwürdiger Aktivitäten?
Exchange Auswertungen helfen dem Service-Desk Mitarbeiter fragwürdige IP-Adressen zu identifizieren, die auf Nutzerpostfächer zugreifen, und dies auf eine Block-Liste zu setzen. Exchange Administratoren können abgelaufene und ungenutzte Benutzerkonten (eine Spielwiese für Malware und Sicherheitsbrüche) identifizieren und deaktivieren oder löschen. Die HR Abteilung kann nachverfolgen, ob bestimmte Benutzer gegen Unternehmensrichtlinien verstoßen. Und der CIO kann sicherstellen, dass alle Sicherheitsinitiativen den rechtlichen Vorschriften entsprechen.
Wie hilft das Wissen über die Speicherkapazitäten bei der Umsatzgenerierung des Unternehmes?
Stellen Sie sich vor, Ihr Verkaufsteam kann eine wichtige Verkaufspräsentation oder eine wichtiges und vertrauliches Angebot nicht zum Kunden senden, da das Postfachlimit des Teams erreicht ist. In dem Fall erfolgt sicher eine umgehende interne Eskalation, die durch ein pro-aktive Überwachung und Berichterstattung vermeidbar gewesen wäre. Solche Situationen sind für alle Beteiligten nervenaufreibend und unnötig. Mit dem Wissen über die aktuellen Speicherkapazitäten und -limits kann schon im Vorfeld solcher Situationen eingegriffen werden und das Verkaufsteam bleibt produktiv.
Nachfolgend wird anhand von Anwendungsbeispielen gezeigt, die personalisierte Berichterstattung helfen kann:
Erkennung, Blockierung, Quarantäne von E-Mails aus fragwürdigen Quellen
Nutzungs- und Zugriffkontrolle (z.B. BYOD) und Einhaltung von Unternehmensrichtlinien Unterscheidung zwischen rechtmäßiger Unternehmensnutzung und missbräuchlicher Nutzung durch Anwender
Überwachung von ungewöhnlichen Nutzeraktivitäten, wie z.B. unberechtigter Zugriff auf Postfächer der Unternehmensleitung
Reduzierung von Sicherheitslücken durch Löschung von alten oder ungenutzten Benutzerkonten
Identifikation von möglichen Sicherheitsrisiken und damit Hilfe beim Schutz geistigen Eigentums
Durchsetzung von Richtlinien mit Hilfe von Active Directory Einstellungen
Sicherstellung des IT-Betriebes im Rahmen der Compliance
Ausarbeitung von Zugriffs- und Sicherheitsrichtlinien, basierend auf aktueller Exchange-Auslastung
Benachrichtigung von Anwendern, vor dem Erreichen des Postfachlimits
Löschen von inaktiven Postfächern, um CALs und Speicherplatz besser auszunutzen
Identifikation von anormal anwachsenden E-Mail-Warteschlangen, bevor größere Probleme entstehen
Troubleshooting und Diagnose
Erkennung von Nutzungsmuster, die sich negativ auf den laufenden Betrieb auswirken können (z.B. Nutzungsspitzen) oder die generelle Performance beeinträchtigen
Genehmigung notwendiger Ressourcen, um die Produktivität sicherzustellen Auditierung und Kontrolle des Lifecycle Managements der Hardware
Hilfe bei der Entwicklung von Standards und Nutzerrichtlinien
Reaktion auf kritische Betriebszustände (Plattenplatz, Prozessor- und Speicherauslastung), um Störungen des laufenden Betriebs zu vermeiden
Erleichterung der Betriebsplanung, Ausführung von Archivierungsrichtlinien und die Verfeinerung von Backup Prozessen
Verständnis der Ressourcennutzung und die Abhängigkeit zwischen Nutzungsverhalten und Produktivität
Einhaltung von Service Level Agreements
Kenntnis über die Speichernutzung und Planung von notwendigen Erweiterungen
Kenntnis über das Service-Desk Last-Aufkommen
Verwaltung der Speicherkapazitäten, Serverressourcen und anderer zugehöriger Kosten
Detailliertes Verständnis der Kosten- und Nutzungsstrukturen
Begründung von Budgetanforderungen für notwendigen Erweiterungen durch Chargeback-Berichte für jede Abteilung
Die meiste Unternehmen haben nur eine begrenzte Anzahl an Mitarbeitern zur Verfügung, die sich um mit dem stetigen Wandel der IT-Anforderungen mitzuhalten. Die Menge an E-Mail Datenverkehr und die Postfachgrößen selber werden weiter wachsen. Berichtssysteme selber werden dieses Probleme nicht lösen, sie helfen aber, die notwendigen aktuellen Informationen den richtigen Personen zum richtigen Zeitpunkt zur Verfügung zu stellen.
Mit den richtigen Informationen können Sie neue Anschaffungen für den sicheren Betrieb Ihrer Exchange Infrastruktur auch detailliert begründen.
Möchten Sie mehr darüber erfahren, wie Mailscape Ihnen dabei helfen kann die Lücken über das Wissen in Ihrer Umgebung zu schließen?
http://www.granikos.eu/de/Mailscape
Eine benutzerdefinierte Domäne kann innerhalb aller Office 365 Instanzen (Global, Deutschland und China) nur einmal registriert werden. Damit eine einmal registrierte Domäne in einem neuen Tenant verwendet werden kann, muss die registrierte Domäne aus dem alten Tenant entfernt werden.
Im nachfolgenden Text wird davon ausgegangen, dass Sie bereits alle Benutzerdaten migriert oder gesichert haben. Die beschriebenen Schritte führen ansonsten zu einer direkten Löschung von Daten oder zu einer Freigabe zur Löschung innerhalb von Office 365. Sollte die zu löschende Domäne die Standarddomäne des Tenants sein, so befinden sich auch Konten für Gastbenutzer (user_remotedomain#EXT#mydomain.com) im Azure AD, die diese Domäne verwenden. Diese Konten müssen Sie ebenfalls bereinigen.
Wenn für den alten Tenant eine Synchronisierung mit Azure AD Connect existiert, muss diese zuerst zurückgebaut werden. Die zu löschende Domäne darf von keinem Benutzer- oder Gruppenobjekt in Azure AD verwendet werden. Hierzu gibt es mehrere Möglichkeiten:
Bevor die Domäne in Office 365 gelöscht werden kann, überprüfen Sie per PowerShell, ob in Office 365 noch Objekte existieren, die die zu löschende Domäne verwenden.
# Installation des PowerShell Moduls für Office 365 Install-Module MSOnline # Alternativ, falls das Modul bereits installiert ist Import-Module MSOnline # Mit Office 365 verbinden - Globales Administratorkonto ohne MFA erforderlich Connect-Msolservice # Domainname $Domain = 'granikoslabs.de' $Filter = "*@$Domain" # Auflistung aller Office 365 Nutzer mit einem UPN für die Domäne Get-MsolUser -DomainName $Domain | FL UserPrincipalName # Auflising aller Office 365 Nutzer mit einer E-Mail-Proxyadresse für die Domäne Get-MsolUser | Where-Object {$_.ProxyAddresses -like $Filter} # Auflistung aller Gruppen in Office 365 mit E-Mail-Proxyadressen für die Domäne Get-MsolGroup | Where-Object {$_.ProxyAddresses -like $Filter} # Auflistung aller Gruppen in Office 365 mit einer E-Mail-Adresse für die Domäne Get-MsolGroup | Where-Object {$_.EmailAddress -like $Filter}
Wenn Sie bei einer der o.g. Auflistungen ein Ergebnis erhalten, so müssen Sie die betroffenen Objekte bereiningen. Ohne diese Bereinigung ist eine Entfernung der Domäne nicht möglich.
Wenn Sie für alle vier Auflistungen keinerlei Ergebnis erhalten, löschen Sie die benutzerdefinierte Domäne final aus Ihren Tenant:
# Löschung der Domäne Remove-MsolDomain -DomainName $Domain -Force
Nach der Löschung der Domäne aus dem Tenant kann die Domäne relativ zeitnah einem neuen Tenant in den Office 365 Instanzen hinzugefügt werden.
Viel Spaß mit Office 365!
Bei dem Thema Cloud wird allzu oft nur an gehostete Dienstleistungen der unterschiedlichen Anbieter gedacht. In den letzten Jahren gab es jedoch eine wahre Explosion von Angeboten, die im Rahmen von Software-as-a-Service (SaaS)[1] ihren Weg zu privaten und gewerblichen Kunden gefunden haben.
Die Nutzung dieser sog. "Cloud-basierten" Anwendungen ist sowohl für Anwender, wie auch für Administratoren gleichermaßen, vollständig transparent. Hier wird vordergründig die Einsparung von zusätzlicher Hardware und die schnelle Umsetzung der Anforderungen (z.B. FastTrack Onboarding in Office 365) gesehen.
Das Umsetzen des Cloud-Gedanken auf der Infrastrukturseite erfordert allerdings ein Umdenken der IT-Verantwortlichen und auch ein Loslassen von alten Konzepten bei Administratoren.
Der sehr allgemeine Begriff "Cloud" lässt sich für die IT-Infrastruktur in die Bereiche Private Cloud und Public Cloud verfeinern. Mit diesen Begriffen wurde in der Vergangenheit hauptsächlich die Bereitstellung von Infrastrukturkomponenten beschrieben, mit denen eine Virtualisierung von Serversystemen mehr oder weniger einfach erreicht werden konnte. Man war in der Lage ein Serversystem entweder in der eigenen Umgebung ("Private Cloud") oder in der Umgebung eines Hosters ("Public Cloud") zu betreiben.
Ergänzt wird das Public Cloud Angebot durch Platform-as-a-Service (PaaS)[2]. Hierbei kann der Kunde seine Kompetenz ganz auf den Betrieb und die Nutzung seiner Line-of-Business Applikationen ausrichten und den größtmöglichen Nutzen aus allen Plattformkomponenten ziehen. Am Beispiel von Microsoft Azure stehen über den Middleware-Stack nicht nur unterschiedliche Speichermedien bereit, sondern vielmehr Dienste, die z.B. eine automatische Verarbeitung von großen Datenmengen erleichtern. Die kontinuierliche Erweiterung und Verbesserung der Plattform ist für die Kunden von großen Nutzen, da in technologischen Spezialgebieten keine eigenes Infrastruktur Knowhow aufgebaut werden muss.
Das nachfolgende Schaubild verdeutlicht die Unterschiede zwischen dem Betrieb einer eigenen IT-Infrastruktur, Infrastructure-as-a-Service (IaaS)[3], Platform-as-a-Service (PaaS)[2] und Software-as-a-Service (SaaS)[1].
Am Beispiel Microsoft Azure lässt sich der Nutzen der "Private Cloud" in Unternehmen sehr gut verdeutlichen. Aus Sicht von Microsoft Azure sind "Kunden" immer "externe Kunden" des Plattformbetreibers.
Wie wäre es, wenn man die Vorteile einer Platform-as-a-Service (PaaS)[2] Umgebung im eigenen Unternehmen bereitstellen könnte?
Genau dies erreicht man mit dem Microsoft Cloud Platform System (CPS). Hierbei handelt es sich um eine vorkonfigurierte Hardwareumgebung, die aus einem 19" Rack mit allen erforderlichen Komponenten besteht. Das System kann auf bis zu 4 Racks erweitert werden.
Setzt man nun den Plattformbetreiber gleich mit der internen IT-Abteilung eines Unternehmens und die "externen Kunden" mit den Fachabteilungen eines Unternehmens, wird deutlich, wo die Vorteile einer solchen Konfiguration liegen.
Abteilungen können eigenständig die erforderlichen Dienste aus der Plattform abonnieren, konfigurieren und nutzen. Durch die Integration von Microsoft System Center und der Azure Pack Erweiterung ergibt sich ein einheitliches Nutzungsszenario zwischen dem On-Premise CPS und dem Azure-Abonnements des Unternehmens.
Gerade die dynamische Skalierung von Systemen, bei der automatisch zusätzliche Server mit gleicher Konfiguration bereitgestellt und genutzt werden, hilft Fachabteilungen bei der effizienten Realisierung antizyklischer Berechnungen.
Neben der Nutzung des integrierten Portals (Azure Pack), besteht auch die Möglichkeit, die konfigurierten Dienste durch eigene Softwareentwicklung über eine REST-API anzusprechen oder ein eigenes, den Unternehmensvorgaben entsprechendes, Portal zu erstellen.
Insgesamt stehen in einem CPS, bestehend aus vier Racks, 1,1 PB Speicherkapazität zur Verfügung. Mit einer VM Konfiguration von 2vCPU und 1,75 GB lassen sich in solch einem CPS bis zu 8.000 virtuelle Serversysteme betreiben.
Das standardmäßig integrierte Management, auf Basis von System Center, erleichert das Monitoring der Umgebung und die Verteilung von Softwareaktualisierungen. Mit Hilfe der integrierten Automation Engine können beliebige Konfigurationsschritte teilweise oder vollständig automatisiert werden. Von Hause aus, müssen keinen zusätzlichen Arbeiten zur Erstellung von Datensicherungen durch geführt werden. Neue Systeme werden automatischen durch den integrierten Data Protection Manager (DPM) gesichert.
Somit stellt das CPS eine attraktive Alternative oder Ergänzung zu bereits vorhandenen On-Premise Lösungen dar. Insbesondere Unternehmen die, aus unterschiedlichsten Gründen, den Weg in die Public Cloud nicht gehen wollen finden in CPS einen gangbaren Weg um die Vorteile einer Cloud Lösung nutzen zu können.
Das Thema "ungünstiger Exchange Server Implementierungen" scheint in seiner Vielfalt unerschöpflich. Leider ist Exchange Server, auch in der aktuellen Version 2019, ein sehr tolerantes Produkt, wenn es um die Installation und den Erstbetrieb geht. Die eigentlichen Probleme und Fehler einer schlechten Exchange Server Implementierung treten erst nach einer gewissen Betriebszeit in Erscheinung. Ähnlich sieht es aus, wenn nach einer IT-Störung notwendige Wiederherstellungsschritte ausgelassen oder unbedacht ausgeführt werden.
Heute möchte ich mit Ihnen folgendes Beispiel teilen, bei dem einige Informationen auf Annahmen basieren, da von Kundenseite nicht alle Fragen beantwortet wurden bzw. beantwortet werden konnten.
In der lokal installierten Exchange Server Plattform treten Performance-Probleme mit der Nachrichtenzustellung im Outlook-Client auf. Nach Aussage des Kunden erfolgt die Zustellung eingehener Nachrichten mit einer bis zu 60-minütigen Verzögerung.
Diese Beschreibung erscheint auf den ersten Blick auf einen einfach zu lösenden Fehler hinzudeuten. Bei genauer Betrachtung zeigt sich aber, dass es sich um ein schwerwiegendes Problem innerhalb der Exchange Server-Plattform handelt.
Im Vorfeld wurde, so die Aussage des Kunden, die IT-Infrastruktur durch eine Krypto-Attacke kompromittiert. Im Rahmen der ausgeführten Wiederherstellungsmassnahmen wurde, so der Anschein, ein Domain Controller auf einen älteren Stand zurückgesetzt. Zu dieser Maßnahme fehlen leider detaillierte Informationen.
Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:
In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:
Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:
Weitere Fakten:
In der beschriebene Exchange Server Plattform kommen unterschiedliche Probleme zusammen. Das beschriebene Fehlerbild der verzögerten Nachrichtenzustellung hängt weniger mit der eklatante Fehlkonfiguration der Exchange Organisation zusammen, als mit dem schlechten Aufbau der IT-Hardware. Hier kommen mehrere Punkte zusammen:
Die Probleme hinsichtlich der Leistungsdefizite der beiden Exchange Server 2016 Systeme hätten bereits im Vorfeld mit einer einfachen Systemüberwachung des Betriebssystems erkannt werden können. Bei der Konfiguration des Arbeitsspeicher für die Systeme standen die Einschränkungen der Hypervisor-Hostsysteme im Vordergrund. Die realen Anforderungen von Betriebssystem, Exchange Server 2016, Endpunkt-Sicherheitslösung und anderer installierter Komponenten, fanden keinen Anwendung. Insbesondere wurden auch die internen Anforderungen von Exchange Server 2016 beim Betrieb einer DAG, in Kombination mit der Managed Availability, nicht berücksichtigt.
Mit dieser Hardware-Konfiguration kann der Programmcode von Exchange Server nicht korrekt arbeiten. Die im Verhältnis recht hohe Zahl an vorhandenen Prozessorkernen führt nicht zu einer Beschleunigung von Exchange Server. Da gleichzeitig nicht genug freier Arbeitsspeicher zur Verfügung steht und die Disk I/O-Leistung zu gering ist, kommt es zwangsläufig zu einer verzögerten Ausführung des Codes und damit automatisch zu einer verzögerten Verarbeitung von Nachrichten.
Für diese Hardware-Plattform sind zu viele iSCSI-Volumes in Betrieb und zu viele Postfachdatenbanken je Server eingebunden. Bei 40 Datenbanken mit je einer aktiven und einer passiven Kopie werden insgesamt 80 Datenbankkopien auf den iSCSI-Zielen betrieben. Trotz der starken Reduzierung der Disk I/O-Anforderungen in Exchange Server 2016, im Vergleich zu den Vorversionen, kann ein iSCSI-NAS die permanent erforderliche Leistung nicht liefern. Für ein Caching von Postfachinformationen steht nicht genug Arbeitsspeicher zur Verfügung. Exchange Server muss die Daten direkt auf Disk schreiben, um die Daten sicher zu persistieren.
Die fehlerhafte Konfiguration der Exchange Organisation im Active Directory trägt ihren ganz eigenen Teil zu den Problemen bei. Diese Konfiguration wird von allen Exchange Servern gelesen und für weitere Aktionen verwendet. Einige dieser Aktionen, die jeder einzelne, in Betrieb befindliche, Exchange Server durchführt, sind:
Exchange Server besteht aus viel mehr als nur der Verarbeitung von individuellen eingehende und ausgehenden Nachrichten. Die Funktion der Managed Availability nimmt einen nicht unerheblichen Teil des Leistungsbedarfs eines Exchange Servers in Anspruch. Exchange Server ist dafür ausgelegt, eine hochverfügbare Messaging-Plattform bereitzustellen. Hierzu dienen all die Funktionen, die unter der Haube ablaufen. Neben den Anforderungen an die Systemleistung von CPU und Arbeitsspeicher, schreiben alle Exchange Server Komponenten Protokolldateien auf Disk. Dies wird gerne ebenfalls vernachlässigt.
Die in der Active Directory Konfigurationspartition vorhandenen Exchange Server 2010 Systeme sind als Computerobjekte nicht mehr vorhanden. Dies deutet darauf hin, dass die Wiederherstellung der authoritativen AD-Datensicherung Ursache des Fehlers ist. Alternativ ist es auch möglich, dass diese Situation durch eine "Ad-Hoc-Deinstallation" von Exchange Server aus dem Active Directory eingetreten ist. Unter einer "Ad-Hoc-Deinstallation" versteht man das unmittelbare Löschen des AD-Computerobjektes eines Servers, auf dem Exchange Server installiert ist. Diese Art der "Deinstallation" von Exchange Server führt automatisch zu verwaisten Einträgen in der Konfigurationspartition und damit zu Folgeproblemen beim Betrieb der Exchange Organisation.
Führen Sie unter keinen Umständen eine "Ad-Hoc-Deinstallation" von Exchange Server durch.
Die Fehlersituation in der Exchange Server-Plattform bei diesem Kunden ist noch nicht abschließend gelöst. Die optimale Lösung erfordert zum einen die Bereinigung des Active Directory und zum anderen einen Umbau der Exchange Server Infrastruktur. Dies ist jedoch mit Investitionen verbunden.
Dieses Beispiel ist eine Ergänzung zu den in meinem Buch "Exchange Server 2019 - Das Handbuch für Administratoren" beschriebenen Beispielen ungünstiger Exchange Server Implementierungen.
Ich wünsche Ihnen viel Spaß und gute Laune mit Exchange Server.
Image by Pexels
Vom 24. - 26. Juni 2019 findet in Wien die SharePoint Konferenz 2019 statt.
Im Rahmen dieser Konferenz spreche ich am am Dienstag, 25. Juni 2019, über
Überwachung der Office 365 Endbenutzererfahrung - Ist das notwendig?
Sobald Unternehmen Office 365 (Hybrid oder Cloud-Only) nutzen, erkennen sie, dass dies zu ganz neuen Herausforderungen im täglichen IT-Betrieb führt. Häufig mangelt es an Transparenz und Kontrolle über die Endbenutzererfahrung, sodass viele Unternehmen keine Sichtbarkeit hierüber haben. In dieser Session werden bewährte Methoden zum Überwachen einer Cloud-Umgebung gezeigt und wie man die Einschränkungen von Office 365 überwinden kann. Erst wenn Unternehmen Office 365 besser kennengelernt haben können sie die nächste Hürde, die Erhöhung der Service-Akzeptanz und die Kontrolle der Lizenzkosten, in Angriff nehmen.
Die weiteren Themen der Konferenz sind:
Ich freue mich, Sie auf der SharePoint Konferenz persönlich begrüßen zu dürfen.