Granikos Technology Blog

Vom 24. - 26. Juni 2019 fand in Wien die SharePoint Konferenz 2019 statt.

Überwachung der Office 365 Anwenderererfahrung - 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 Präsentation der Session ist bei SlideShare verfügbar.

Links

• SharePoint Konferenz 2019

Follow

• Twitter @stensitzki
• LinkedIn
• Xing

Der virtualisierte Betrieb von Exchange Server ist seit der Einführung von Hypervisor-Plattformen immer wieder Thema für Diskussionen. Oftmals werden diese Diskussionen sehr emotional geführt und die richtigen Argumente für und gegen solch einen Betrieb finden selten Gehör. Das ist meist dann der Fall, wenn das Motto 100% Virtualisierung ausgerufen wurde.

Unabhängig von der Exchange Server Produktversion gibt es für die Planung und den Betrieb virtualisierter Exchange Server einen wichtigen Grundsatz:

Die Anforderungen an Prozessor, Arbeitsspeicher und Datendurchsatz der Festplatten für virtualisierte Exchange Server sind identisch zu den Anforderungen eines Betriebs auf physischen Servern.

Von diesem Grundsatz wird in der Realität immer wieder abgewichen. Abweichung von diesem Grundsatz haben aber automatisch Auswirkungen auf den stabilen und sicheren Betrieb von Exchange Server und erhöhen zusätzlich das Betriebsrisiko.

Empfohlene Betriebsparameter

Mit Exchange Server 2019 haben sich empfohlenen Betriebsparameter für einen stabilen Betrieb, im Vergleich zu den Vorversionen, stark verändert.

Die empfohlene Prozessor-Konfiguration sieht weiterhin eine 2-Sockel-Architektur, allerdings mit insgesamt bis zu 48 Prozessorkernen (Cores) vor. Für den Betrieb eines Exchange Servers mit Postfach-Rolle ist eine Arbeitsspeichergröße von 128GB und für einen Server mit Edge Transport-Rolle eine Arbeitsspeichergröße von 64GB empfohlen.

Ob für Ihre Exchange Server 2019 Umgebung diese empfohlenen Betriebsparameter sinnvoll oder ob andere Betriebsparameter notwendig sind, finden Sie mit Hilfe des Exchange Server 2019 Sizing Calculator heraus. Der Calculator basiert auf einer Excel-Datei, die für Exchange Server 2019 ab dem Kumulativen Update 2 Bestandteil der Exchange Server 2019 ISO-Datei ist. Für Exchange Server 2016 können Sie die Excel-Datei direkt aus dem Microsoft Download Center herunterladen.

Exchange Server 2019, MetaCache Datenbank und Virtualisierung

Die Virtualisierung von Exchange Server 2019 ist, wenn Sie sich nur an den Empfehlungen der Online Dokumentation orientieren, eine Herausforderung. Sie werden zu recht einwenden, dass niemand diesen Empfehlungen folgt, um Exchange Server 2019 produktiv zu betreiben. Meine Gegenfrage ist aber automatisch: Warum folgen Sie diesen Empfehlungen nicht? Die Empfehlungen basieren auf den jahrelangen Erfahrungen der Exchange Produktgruppe mit dem Betrieb von Exchange Server 2019 in großen und hochverfügbaren Umgebungen.

An dieser Stelle sei auch noch einmal darauf hingewiesen, was das Produkt Exchange Server ist: 

Exchange Server ist eine Softwarelösung zur hochverfügbaren und sicheren Bereitstellung einer Massaging-Plattform für Clients und weitere Applikationen.

Vor dem Hintergrund der Empfehlungen für die Prozessor- und Arbeitsspeicherkonfiguration ist eine Virtualisierung von Exchange Server 2019 nicht immer sinnvoll. Wenn Sie eine Datenbankverfügbarkeitsgruppe (DAG) mit der Mindestanforderung von vier Mitgliedsservern konfigurieren, benötigen Sie auch mindestens vier Hypervisor-Host-Systeme. Der gleichzeitige produktive Betrieb von zwei Exchange Servern auf einem Host-System stellt ein beträchtliches Betriebsrisiko dar und ist im Regelbetrieb zu vermeiden.

Für den empfohlenen Betrieb des Exchange Server Gast-Systems müssen Sie in der Hypervisor-Plattform mit fest reservierten Ressourcen für Prozessor und Arbeitsspeicher arbeiten. Sie können bei der CPU-Ressourcenzuweisung zwar ein Verhältnis von 1:2 (pCore : vCore) konfigurieren, jedoch ist dies nur dann sinnvoll, wenn Sie sowohl die CPU-Auslastung des Gast-Systems, als auch des Host-Systems lückelos überwachen. Sobald auf dem Host-System weitere virtuelle Systeme betrieben werden, die eine hohe CPU-Last erzeugen, geht dies automatisch zu Lasten des Exchange Server-Systems.

Bedenken Sie bei der Konfiguration der Ressourcen immer, dass eine auf einem Windows Server betriebene Applikation immer genau die Ressourcen sieht, die das Betriebssystem meldet. Ist ein Server-System mit 24 vCores und 128GB Arbeitsspeicher konfiguriert, so nimmt die Applikation diese Ressourcen auch in Anspruch. Stehen diese Ressourcen bei einer dynamischen Zuweisung durch das Host-System nicht unmittelbar zur Verfügung, kommt es zu spürbaren Leistungsproblemen und zu Appkilationsfehlern.

Neben den Hypervisor-Herausforderungen für CPU-Cores und Arbeitsspeicher ergeben sich ebenso Herausforderungen für die Anbindung der notwendigen Speichermedien. Idealerweise verfügt das Gast-System für Exchange Server 2019 über nur ein, per Laufwerksbuchstaben eingebundenes Volume für das Betriebssystem und die Exchange Server Programmdateien. Alle weiteren Volumes zur Speicherung der Postfachdatenbanken und Protokolldateien werden über Mountpoints eingebunden. Je nach Anzahl der benötigten Volumes und der verwendeten Technologie zur Bereitstellung von Volumes in der Hypervisor-Plattform, stoßen Sie hier an Grenzen. Erschwert wird diese Situation noch dadurch, dass der hochverfügbare Betrieb einer DAG die Nutzung der AutoReseed-Funktion von Exchange Server vorsieht. Die AutoReseed-Funktion erfordert die Einbindung weiterer Volumes durch die Hypervisor-Plattform in das Gast-System.

Die Bereitstellung von leistungsstarkem Datenspeicher ist der neuralgische Punkt einer virtualisierten Exchange Server-Plattform. Für die Bereitstellung des erforderlichen Datenspeichers bieten Ihnen zahlreiche Hersteller die phantasievollsten Lösungen an. In den meisten Fällen handelt es sich um Lösungen, die eine Ersparnis des benötigten Gesamtvolumens für Exchange Server Postfachdatenbanken und Protokolldateien versprechen. Oftmals wird dies durch eine Form der Deduplizierung für die Postfachdatenbanken und Protkolldateien erreicht.

In solchen einem Fall muss Ihnen bewusst sein, dass Sie das Feld eines unterstützen Betriebes von Exchange Server 2019 verlassen. Sie nehmen Exchange Server eine der wichtigsten Funktionen für den Fall eines Desaster, die Datenbankportierbarkeit.

Jede weitere Technologieebene im Betrieb Ihrer Exchange Server-Plattform erhöht die Komplexität und die Zahl der möglichen Fehlerquellen. Hinzu kommt, dass Sie solch einen extern angebunden Datenspeicher immer redundant betreiben müssen, um das allgemeine Betriebsrisiko der Plattform zu minimieren. Bedenken Sie in diesem Zusammenhang auch, dass das Exchange Server Produktteam klassische HDD-Datenträger für die Speicherung von Datendateien empfiehlt, da SSD-Laufwerke nicht die notwendige Zuverlässigkeit und Robustheit aufweisen.

MetaCache-Datenbank

Mit Exchange Server 2019 wurde die Funktion der MetaCache-Datenbank (MCDB) eingeführt. Die Aufgabe der MCDB ist die Beschleunigung des Datenzugriffs auf häufig genutzte Postfachinformationen. Für den optionalen Betrieb einer DAG mit aktivierter MCDB-Funktion sind einige Voraussetzungen zu erfüllen:

1. Sie müssen Ihre Exchange Server-Systeme in einer DAG-Konfiguration betreiben
2. Sie müssen die DAG für AutoReseed konfigurieren
3. Sie müssen für MCDB die passende Anzahl an SSD-Laufwerken bereitstellen

Beim Betrieb einer Exchange Server Plattform mit physikalischen Servern verwenden Sie idealerweise passende M.2 SSD-Laufwerke, die direkt innerhalb des Servers verbaut sind. Auf diese Weise stehen Ihnen mehr Standardsteckplätze für die HDD-Laufwerke der Daten-Volumes zur Verfügung.

Aber wie können Sie von den Vorteilen der MCDB bei einem virtualisierten Betrieb von Exchange Server profitieren?

Wie bereits erwähnt, basiert die Nutzung der MCDB-Funktion auf SSD-Datenträgern. Bei einem Betrieb in einer Hypervisor-Plattform sind immer zusätzlichen Technologieebenen zwischen dem Betriebssystem und dem eigentlichen Datenspeicher, die den Geschwindigkeitsvorteilen einer direkten SSD-Anbindung in einem physikalischen Server entgegenstehen.

In einer Hypervisor-Plattform ist der Betrieb einer MCDB-Konfiguration nicht sinnvoll. Die zusätzlichen Laufwerke, insofern Sie als SSD-Laufwerke bereitgestellt werden können, erhöhen nochtmals die Komplexität der Plattform und erzeugen mit ihren Disk-I/O zusätzliche CPU-Last auf dem Host-System. Damit steigt das Risiko einer Verlangsamung des Datenzugriffs, sobald auf dem gleichen Host-System andere Applikationen mit hohen Systemanforderungen betrieben werden.

Daher ist meine Empfehlung, die MCDB-Funktion von Exchange Server 2019 nur beim Betrieb mit physikalischen Servern zu nutzen.

Der zu Exchange Server 2019 gehörende Role Requirements Calculator unterstützt Sie auch bei der Planung einer MCDB-Implementierung.

Zusammenfassung

Wenn Sie einen virtualisierten Betrieb von Exchange Server 2019 planen, beachten Sie bitte immer die Empfehlungen der Exchange Server Produktgruppe in der Online Dokumentation. Diese Empfehlungen gründen auf den Erfahrungen im täglichen Betrieb von Exchange Server und den Exchange Server Supportfällen, basierend auf sehr individuellen Exchange Server Betriebsarten in Kundenumgebungen.

Achten Sie bei der Virtualisierung von Exchange Server 2019 auf eine möglichst einfache und standardisierte Implementierung. Jede zusätzliche Technologieebene erhöht nicht nur die Komplexität des Betriebs, sondern ist immer auch eine zusätzliche Fehlerdomäne. Vertrauen Sie nicht auf die Versprechen für vermeintlich leistungssteigernde Speicherlösungen für Ihre Exchange Server Systeme, die gerne von Systemhäusern als Allheilmittel angeboten werden.

Der Einsatz der MetaCache-Datenbank ist nur auf physikalischen Servern sinnvoll. Nur dort bietet die MCDB den gewünschten Geschwindigkeitsvorteil als Cache-Speicher zwischen Applikation und den Postfachdatenbanken.

Und vergessen Sie nicht, die Hochverfügbarkeit der Exchange Server 2019 erfolgt, wie bei allen modernen Exchange Server Versionen, auf Applikationsebene.

Und wenn Sie den Betrieb einer Einzelserverinstallation von Exchange Server 2019 planen, so möchte ich Ihnen den Wechsel zu Microsoft 365 und Exchange Online ans Herz legen.

Links

• Exchange Server – Systemanforderungen
• Exchange 2019 – Bevorzugte Architektur
• Exchange Server - Virtualisierung
• Announcing The Exchange Server 2019 Sizing Calculator
• Exchange Server Role Requirements Calculator v9.1
• Exchange Server Database Portability

Viel Spaß mit Exchange Server 2019.

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. 

Ausgangssituation

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. 

Fakten

Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:

• 6 Exchange Server 2010 SP3
  • 3 Systeme mit Mailbox-Rolle
    30 Postfachdatenbanken
  • 3 Systeme mit kombinierter CAS- und Hub-Transport-Rolle
     
• 5 Exchange Server 2016 mit CU12
  • 2 Systeme mit produktiv eingebunden Postfachdatenbanken in einer DAG mit ca. 40 Postfachdatenbanken
  • 3 Systeme ohne produktiv eingebundene Postfachdatenbanken
     
• 2 konfigurierte Datenbankverfügbarkeitsgruppen (DAG)

In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:

• Exchange Server 2010 Systeme sind nicht mehr vorhanden
• Keine Aussage, ob Exchange Server 2010 auf diesen sechs Systemen deinstalliert wurde oder ob die Systeme einfach gelöscht wurden
• Migration von Exchange Server 2010 zu Exchange Server 2016 gilt beim Kunden offiziell als abgeschlossen

Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:

• 12 vCores
• 16 GB Arbeitsspeicher
• Bereitstellung des Datenspeichers per iSCSI von einem QNAP NAS

Weitere Fakten:

• Selbstsignierte Exchange Server Zertiifkate für Frontend-Dienste
• Unterschiedliche Konfiguration je Exchange Server
• ~100 Transportregeln mit CC-Ergänzungen für die Zustellung an weitere Mitarbeiter
• Endpunkt-Sicherheitslösung ohne Konfiguration von Exchange Server-Ausnahmen

Fazit

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 Einbindung der Volumes per iSCSI über die allgemeine Netzwerkinfrastruktur führt zu einer schlechten Disk I/O Performance
• Die Nutzung von 40 Exchange-Postfachdatenbanken per iSCSI über den gleichen iSCSI Endpunkt verschlechtert die Disk I/O Performance nochmals
• Das Verhältnis von verfügbarer Prozessorleistung und Arbeitsspeicher der Exchange Server 2016 Systeme ist unüberlegt konfiguriert
• Der Arbeitsspeicher ist für die Einbindung von 40 Postfachdatenbanken viel zu gering
  • Bei einer guten Datenbankverteilung innerhalb der DAG und Einbindung von 20 aktiven Postfachdatenbankkopien je DAG-Mitgliedsserver ist der Arbeitsspeicher bereits zu gering
  • Bei einer Aktivierung aller Datenbankkopien auf einem Exchange Server im Fehlerfall steht nicht ausreichend Arbeitsspeicher zur Verfügung

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:

• Regelmäßiger Test der Kommunikationsverbindungen (http https, etc.) zu den anderen Exchange Servern, die in der Konfiguration der Exchange Organisation vorhanden sind
  • Funktionstest zu anderen Mitgliedsservern der gleichen DAG
  • Funktionstest der Erreichbarkeit von Exchange Servern außerhalb der DAG
• Versand von Test-Nachrichten zwischen allen aktiven Postfachdatenbanken einer DAG
  • Funktionstest der E-Mail-Zustellung
  • Funktionstest der Suchindizierung
  • Funktionstest der Client-Protokolle
• Prüfung auf fehlende Kalendereinträge in jedem Postfach

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.

Links

• Exchange Server Systemanforderungen
• Exchange Server Unterstützungsmatrix
• Exchange Server Architektur

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

Am 18. Juni 2019 trifft sich die Microsoft Teams Meetup Gruppe Berlin zu ihrem vierten Treffen.

Bei unseren Meetup-Treffen sprechen wir über Microsoft Teams als universelle Plattform zur Zusammenarbeit als Teil einer Modern Workplace Strategie. Hierzu gehören das Teilen und gemeinsame Arbeiten an Dokumenten, Audio- und Video-Kommunikation, Telefonie und die Erweiterbarkeit durch Applikation, Bots und weitere Schnittstellen.

Agenda

• Microsoft Teams als Entwicklungsplattform für Unternehmensanwendungen
• Neuigkeiten rund um Microsoft Teams
• Entwicklung von Erweiterungen für Microsoft Teams

Termin

• 21. Juni 2019
• 18:00 Uhr
• Semtation GmbH
  Geschwister-Scholl-Straße 38
  14471 Potsdam
  (Google Maps)
   
• Registrierung via Meetup

Links

• Mitglied der Microsoft Teams Meetup Gruppe Berlin werden

Viel Spaß mit Microsoft Teams!

Das Blog Cumulative Update für Mai 2019 (CU0519) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Azure und Skype for Business des Monats Mai 2019 zusammen.

Exchange Server

• [STICKY] Outlook License Requirements for Exchange Features
• Deactivate Offline Address Book Download
• Outlook Addin for exporting Email to EML from Outlook on the Web
• Exchange Hybrid TLS negotiation failed with error NoCredentials
• Export Mailbox Delegates and SMTP Forwarding Information
• HCW Organization Configuration Transfer breaks Outlook connectivity to Office 365

Microsoft 365 | OneDrive | Exchange Online | and more

• [STICKY] Office 365 Network Performance Tool
• [STICKY] Office 365 Support and Recovery Assistant (aka SaRA)
• [STICKY] Office 365 URLs and IP address ranges
• [STICKY] Office 365-Trust Center
• How Long Does it Take to Migrate to Office 365?
• Azure Cloud Shell Now Supports Exchange Online
• Managing Office 365 Group Membership with PowerShell
• OneDrive announcements – SharePoint Conference 2019
• SharePoint Saturday Cologne | Migrating legacy public folders to modern public folders and to Office 365 Groups
• Review and Audit Offensive Language in Office 365 Communications
• SharePoint: Restore of files from document libraries
• Office 365 Retention, Disposal & Archiving - Frequently Asked Questions (And We've Got the Answers!)
• Auditing Inbox rules with EWS and the Graph API in Powershell

Microsoft Teams

• [STICKY] Surface Hub update history
• [STICKY] Instructor-led training for Microsoft Teams
• The New Microsoft Teams Auto Attendants & Call Queues Part 3a: PowerShell
• Add Teams Channel as an Exchange Mail Contact
• How to: Enable Yealink Microsoft Teams Phone Hybrid Mode
• Teams Now Tells You About Planner Task Assignments
• Security & Compliance in Microsoft Teams (Videos)
• The New Auto Attendants & Call Queues
• Teams Calendar Fails To On-Premises Mailbox
• How to avoid the Microsoft Teams "Island Mode" trap

Skype for Business Server | Communications

• [STICKY] Download: Skype for Business Network Assessment Tool
• Sending a Cloud Voice mail using the Microsoft Graph or EWS from Powershell
• Lync 2013 / SfB 2015 Client Update - May 2019
• SfB 2015 Server Update - May 2019

Microsoft Azure

• [STICKY] Virtual Machines Licensing FAQ
• [STICKY] Azure Architecture Center
• [STICKY] Microsoft Azure Trust Center

Cloud | Cloud Sicherheit

• [STICKY] Microsoft Security TechCenter
• Föderierte Authentifizierung für Office 365
• Discover Shadow IT across IaaS and PaaS with Microsoft's CASB
• Demystifying Password Hash Sync
• Simplified iOS device management with Microsoft's Intune for Education
• CISA Report Only Scratches Surface of Securing Office 365
• Register For Azure AD MFA From On-Premises Or Known Networks Only
• Ovum recommends Microsoft security to safeguard your hybrid and multi cloud environments
• 3 investments Microsoft is making to improve identity management
• AAD Connect 1.3.21.0 fixes two vulnerabilities
• May 2nd 2019 Office 365 and Azure Global Outage Recap
• Azure AD Connect v1.3.20.0 offers the next level of identity synchronization
• Identity enhancements to support the more than 1 million active third-party applications on our platform

Docs | Knowledge Base | TechNet

• [STICKY] Getting started with the Cloud Adoption Framework

Allgemein

• [STICKY] Microsoft Products Reaching End of Support for 2019
• The World Surrounding Us: Are You Interested in Environmental Monitoring?
• GDPR’s first anniversary: A year of progress in privacy protection
• 5 Thoughts on Digital Minimalism
• Microsoft expands BitLocker management capabilities for the enterprise
• Building the inclusive workplace we imagine, together
• Building the inclusive workplace we imagine, together
• Rollenbasierte Microsoft Zertifizierungen
• Protecting democratic elections through secure, verifiable voting

Replay

• Juni 2015: Exchange and Office 365: Mail Forwarding
• April 2019: Floating Mailbox Databases in Exchange 2019: Pros & Cons

Podcast Empfehlungen

• Exchange Exposed

Tools

• ADFS Rapid Restore Tool
• Active Directory Migration Tool version 3.2
• Microsoft Azure, Cloud and Enterprise Symbol / Icon Set - Visio stencil, PowerPoint, PNG, SVG
• ISESteroids - PowerTheShell
• Mailscape 365 - Exchange Online Monitoring und Reporting
• Mailscape - Exchange Monitoring und Reporting
• Uniscope - Lync Monitoring und Reporting
• Compass - Active Directory Monitoring und Reporting
• ForeSite - SharePoint Monitoring und Reporting

Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.

Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.

Sie möchten mehr über Exchange Server 2019 erfahren? Wir empfehlen das Standardwerk zu Exchange Server 2019 von Thomas Stensitzki "Exchange Server 2019 - Das Handbuch für Administratoren".

Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu