Granikos Technology Blog

Die Migration von E-Mail Postfächern von alternativen E-Mail Servern, wie z.B. Lotus Notes, zu Office 365 ist über das Protokoll IMAP möglich. Die Möglichkeit zur Datenmigration ist in das Office 365 Admin Center implementiert. Über den Menüpunkt Datenmigration können Office 365 Administratoren Postfach-Migrationen zu Office 365 starten. Hierbei werden im Hintergrund die notwendigen Konfigurationen in Exchange Online vorgenommen.

Die nachfolgenden Schritte beschreiben die Migration von Postfächern von einem E-Mail Server mit einer IMAP-Migration, beginnend mit dem Hinzufügen einer neuen Domäne zu Office 365. Für die Einrichtung der IMAP-Migration ist keine vollständige DNS-Konfiguration der Domäne erforderlich. Die Validierung der neuen Domäne ist ausreichend.

An welchem Schritt Sie nun die DNS-Einträge für die MX Ressource Records umstellen, ist Ihnen überlassen und hängt vom Migrationsszenario ab. Sollte die betroffene Domäne weiterhin aktiv für die E-Mail Zustellung verwendet werden, so empfehle ich ein Umstellung der MX-Einträge direkt nach Einrichtung aller Postfächer in Office 365.

Voraussetzungen

Für eine erfolgreiche Migration sind folgende Voraussetzungen notwendig

• Adminkonto auf dem IMAP-Server, um den IMAP-Endpunkt für den Zugriff in Office 365 (Exchange Online) zu konfigurieren
  • E-Mail Adresse und Kennwort
• Liste der zu migrierenden IMAP-Benutzerpostfächer für
  • Anlage neuer Office 365 Benutzer mit zugewiesener Office 365 Lizenz, die einen Exchange Plan enthält
  • IMAP E-Mail-Adresse und Benutzerkennwort zur Synchronisation der Postfachdaten
• Erreichbarkeit des IMAP Endpunktes per TCP 993 aus dem Internet
• Umstellung der MX DNS Ressource Records zur Umstellung der E-Mail Zustellung

Hinzufügen der Domäne zu Office 365

In den folgenden Schritten wird die Domäne azure-usergroup.de als neue Domäne zu einem Office 365 Tenant hinzugefügt.

Schritt 1

Rufen Sie im Office 365 Admin Center den Menüpunkt Setup > Domänen auf und klicken Sie auf Domäne hinzufügen, um den Wizard für eine neue Domäne zu starten.

Geben Sie den Domänennamen ein und klicken Sie auf Weiter.

Schritt 2

Es ist erforderlich, dass Sie die Eigentümerschaft für die Domäne, die Sie hinzufügen möchten, nachweisen. HIerzu stehen Ihnen drei Möglichkeiten zur Verfügung.

1. Validierung mit Hilfe eines TXT Resource Record Eintrages in der Internet DNS Zone der hinzuzufügenden Domäne
2. Validierung mit Hilfe eines MX Resource Record Eintrages in der Internet DNS Zone der hinzuzufügenden Domäne
3. Validierung mit Hilfe eines per E-Mail zu gesandten Codes - Diese Methode steht nur zur Verfügung und wird nur dann angezeigt, wenn die entsprechenden Daten in der DNS Zone hinterlegt sind

Kopieren Sie den TXT-Wert, im aktuellen Beispiel MS=ms81514861 und tragen Sie diesen als Wert für den TXT Resource Record ein.

Je nach DNS Anbieter, kann es mehrere Minuten dauern, bis der Eintrag für Server von Microsoft abrufbar ist. Bei einigen DNS Anbietern kann dies bis zu 24 Stunden in Anspruich nehmen. Wenn Sie bei solch einem Anbieter Ihre DNS Zonen pflegen, sollten Sie über einen Wechsel nachdenken.

Klicken Sie auf Überprüfen, um den TXT Resource Record Eintrag prüfen zu lassen. Wenn der Eintrag erfolgreich geprüft wurde, gelangen Sie zum nächsten Schritt.

Schritt 3

Da Sie die DNS Einträge für Ihre Domäne selber veralten, wählen Sie den Punkt Ich verwalte meine eigenen DNS-Einträge aus und klicken Sie auf Weiter.

Schritt 4

Die Migration der IMAP-Postfachdaten erfordert keine Anpassung der DNS-Einträge für Ihre Domäne. Diese sind erst erforderlich, wenn Sie die Office 365 Dienste bereitstellen und die E-Mail Zustellung zu Exchange Online Protection umstellen möchten.

Wählen Sie die Checkbox am Ende der Seite, um die Aktualisierung der DNS-Einstellungen auszulassen und klicken Sie auf Überspringen. 

Schritt 5

Damit ist die Ersteinrichtung der neuen Domäne in Office 365 abgeschlossen.

Klicken Sie auf Fertig stellen.

IMAP Postfach-Migration 

Nachdem die neue Domäne erfolgreich zu Office 365 hinzugefügt wurde, kann mit der IMAP Migration begonnen werden.

Zur geführten IMAP-Datenmigration zu Office 365 gelangen Sie über den Menüpunkt Setup > Datenmigration.

Einrichtung Benutzerkonten

Vor der Einrichtung der IMAP-Datenmigration über das Office 365 Admin Center müssen Sie die Benutzer in Office 365 anlegen, einen Benutzernamen mit der zu migrierenden Domäne vergeben und eine Office 365 Lizenz zuweisen. Durch diese Zuweisung wird das erforderliche Ziel-Postfach für die Datenmigration erstellt. Der Benutzername in Office 365 kann vom Benutzernamen auf IMAP-Quellseite abweichen.

Im folgenden Beispiel sehen Sie die Erstellung eines Benutzers unter Verwendung der neu hinzugefügten Domäne. Diese Adresse ist sowohl der Office 365 Anmeldename, als auch die neue primäre E-Mail Adresse des Benutzers. 

Optional können Sie neue Benutzer natürlich auch mit Hilfe eines CSV-Datei Imports erstellen.

Schritt 1 : Einrichtung Datenmigration

Im Bereich der Datenmigration bietet Microsoft eine Unterstützung für gängige E-Mail Plattformen an. Die allgemeine E-Mail Datenmigration mit IMAP verbirgt sich unter dem Auswahlpunkt Weitere E-Mail-Quellen.    

Geben Sie den IMAP-Servernamen, den IMAP-Port und die verwendete Sicherheitsmethode an. Eine IMAP-Verbindung ohne Verbindungsverschlüsselung wird nicht unterstützt.

Tragen Sie die E-Mail Adresse des IMAP-Administratorkontos und das dazugehörige Kennwort ein. Klicken Sie anschließend auf Speichern. 

Schritt 2: Start der IMAP-Migration

Wählen Sie das Office 365 Ziel-Konto aus und geben Sie die passende E-Mail Adresse des Quell-Postfaches an. Nach Eingabe der dazugehörigen Kennwortes wird die IMAP-Verbindung zum Postfach überprüft. Wiederholen Sie diesen Schritt für jedes zu migrierende Postfach.

Nach der erfolgreichen Überprüfung des IMAP-Zugriffes können Sie die Migration der Postfachinhalte durch einen Klick auf Migration starten auslösen.

Nach dem Start der Migration erfolgt eine Rückmeldung im Office 365 Admin-Center, dass die Migration in Bearbeitung ist. 

Springen Sie zu Schritt 3, um das nachfolgende Exchange Online Intermezzo zu überspringen.

Intermezzo 1: IMAP-Migration und Exchange Online

Natürlich führt nicht das Office 365 Admin-Center die Migration der Postfächer durch, sondern Exchange Online. Das Office 365 Admin-Center übernimmt die Konfiguration des Migrationsendpunktes, die Erstellung und die Steuerung des Migrationsbatches. Aber wie sieht solch eine erstelle Konfiguration in Exchange Online aus?

Schauen wir uns die Migrationsendpunkte im Exchange Online Admin-Center (EAC) genauer an. Sie finden die Konfiguration der Migrationsendpunkte in der EAC unter:

Empfänger > Migration > ... > Migrationsendpunkte

In der Übersicht der Migrationsendpunkte wurde ein neuer Endpunkt vom Typ IMAP erstellt.

Die Übersicht der Migrationsbatche zeigt den durch das Office 365 Admin-Center konfigurierten Batch und man erkennt, dass in diesem Batch ein Postfach enthalten ist, jedoch noch nicht synchronisiert wurde.

Wählen Sie das IMAP_Batch in der Übersichtsliste aus, um im rechten Fenster die Zusammenfassung des Batches anzuzeigen. Man sieht z.B. die Richtung der Migration (Onboarding) und den aktuellen Gesamtstatus des Batches (Synchronisierung). Hier finden Sie auch Informationen zur zeitlichen Dauer der Migration.

Klicken Sie unterhalb von Postfachstatus auf Details anzeigen, um sich die Liste der im Batch konfigurierten Postfächer und deren Details anzeigen zu lassen. 

Aber nun zurück zum Office 365 Admin-Center.

Schritt 3: Synchronisierte Postfächer

Nachdem im Hintergrund der Migrationsendpunkt in Exchange Online eingerichtet und das Migrationsbatch erstellt wurde, gilt es zu warten. Exchange Online verarbeitet Migrationsbatche in Abhängigkeit der aktuellen Serverlast. Das bedeutet, dass die Einrichtung und der Start einer Migration nicht gleichzusetzen ist mit dem Start der Ausführung. 

Sobald die Erstsynchronisierung abgeschlossen ist, wird das IMAP-Postfach alle 24 Stunden automatisch synchronisiert. Im Office 365 Admin-Center wird im Kopftext zwar angezeigt, dass die Migration erfolgreich abgeschlossen ist, dies ist aber nicht korrekt.   

Dies wird im nächsten Exchange Online Intermezzo deutlich. Springen Sie zu Schritt 4, wenn Sie die IMAP-Migration abgeschliessen möchten.

Intermezzo 2: Status des IMAP-Migrationbatch

In der Übersicht der Exchange Online Migrationsbatche wird deutlich angezeigt, dass das Batch synchronisierte, aber keine finalisierten (abgeschlossenen) Postfächer enthält.

Schritt 4: IMAP-Migration beenden

Über das Office 365 Admin-Center können Sie die IMAP-Migration für jeden Benutzer getrennt beenden. Hierzu wählen Sie einen Benutzer aus, dessen Postfach im Status Synchronisiert ist und klicken auf Migration beenden. Nach der Bestätigung mit Ja wird das ausgewählte Postfach innerhalb des Migrationsbatches finalisiert.

Das bedeutet, dass für diesen Bentuzer eine letzte IMAP-Synchronisierung durchgeführt wird und dieser Benutzer nach Abschluss der Synchronisierung aus dem Migrationsbatch entfernt wird. Alle im Batch verbleibenden Postfächer werden weiterhin alle 24 Stunden synchronisiert.

Wenn kein Postfach mehr Migrationsbatch enthalten ist, haben Sie die Möglichkeit, neue Benutzer auszuwählen und eine Migration zu starten. 

Über die Schaltfläche Verbindung schließen wird die Information über eine laufenden IMAP-Migration aus dem Office 365 Admin-Center entfernt. Nach dem Schließen der Verbindung erreichen Sie über den Menüpunkt Datenmigration die Einstiegsseite der Datenmigration, wie in Schritt 1 beschrieben.

Nachdem alle IMAP-Postfächer zu Office 365 migriert wurden, können Sie mit dem Rückbau der Postfächer auf den Quellsystemen beginnen. 

Intermezzo 3: Exchange Online und der leere IMAP-Migrationbatch

Nach dem Beenden der IMAP-Migrationen und dem Schließen der Verbindung über das Office 365 Admin-Center verbleibt ein leerer IMAP-Migrationsbatch in Exchange Online. Diesen können Sie bedenkenlos über das Papierkorbsymbol löschen. 

Links

• Exchange Online Admin-Center
• Wie funktioniert eine IMAP-Migration

Sie haben Fragen zur IMAP Migration zu Office 365? Nutzen Sie bitte die Kommentarfunktion dieses Blogbeitrages.

Viel Spaß mit Office 365!

NoSpamProxy Azure Edition is the cloud based email security gateway of the successful NoSpamProxy family of products by Net at Work. The Azure edition of NoSpamProxy can easiliy be deployed using the Microsoft Azure Marketplace.

NoSpamProxy Azure easily connects an Office 365 tenant and offers an easy way to provide centralized email encryption and decryption with PGP and/or S/MIME for mailboxes hosted in Exchange Online. Additionally, NoSpamProxy Azure provides compliant anti-spam handling, an anti-malware component, and a large file portal.

The edition currently available in Microsoft Azure installs a NoSpamProxy single-server deployment. A single-server deployment combines the NoSpamProxy intranet role and the gateway role on a single server.

The NoSpamProxy Azure Edition is provided as BYOL (Bring Your Own License) deployment. In addition to the recurring fees for the Microsoft Azure VM you are required to buy a NoSpamProxy license. If you already own a NoSpamProxy Version 11 license, the license can be used for the NoSpamProxy Azure Edition as well.

Content

DeploymentOptions
Notes
Deployment
Links

Deployment Options

Due to the nature of a cloud service NoSpamProxy Azure can be operated in different scenarios in Microsoft Azure. By default the system is configured as a workgroup system without any Active Directory domain membership. The different operational scenarios for NoSpamProxy Azure depend on the existence of a Site-2-Site VPN between your Azure deployment and your on-premises IT infrastructure.

• Without Site-2-Site VPN to Microsoft Azure
   
  • An on-premises email server (e.g. Exchange Server or SmarterMail) utilizes NoSpamProxy Azure as an external relay for outgoing messages. Incoming messages are received by NoSpamProxy Azure and are forwarded to the on-premises email server via the internet.
     
  • Email addresses of internal recipients are maintained manually using plain text file. The file itself is imported automatically by NoSpamProxy Azure
    This is a viable option, if there aren't too many email addresses to maintain.
     
  • Good option for Office 365 customers running a cloud only deployment without any on-premises Active Directory users and mailboxes. The required import file can be created by exporting Office 365 recipients and email addresses.
     
  • RDP access to the Azure VM and NoSpamProxy Azure must be limited to an external IP address of the company network.
     
• With Site-2-Site VPN to Microsoft Azure
   
  • AN on-premises email server (e.g. Exchange Server or SmarterMail) utilizes NoSpamProxy Azure as an internal Relay for outgoing messages. Incoming messages are received by NoSpamProxy Azure and forwarded to the on-premises email servers using the Site-2-Site VPN.
     
  • Automated import of internal email recipients from a LDAP source (e.g. Active Directory)
    This option simplifies recipient maintenance, as recipients are automatically imported by NoSpamProxy Azure.
     
  • Perfect option for Office 365 customers maintaining user accounts on-premises and running Azure AD Connect or maybe even having a full Office 365 hybrid setup with centralized mail flow.
     
  • RDP access to the Azure VM and NoSpamProxy Azure restricted to internal company network(s).

Currently a direct connection to Azure AD is not supported, but it is planned for a future release.
 

Notes

• The Azure Service for NoSpamProxy Azure System requires a Reverse-DNS configuration, as any other public facing SMTP service. External SMTP servers must be able to perform a Reverse-DNS check successfully. A link on how to configure Reverse-DNS in Azure is listed in the Links section.
   
• The system name of the NoSpamProxy Azure VM should not follow internal IT naming conventions, as the name is publically resolvable. Otherwise you are going to expose your internal naming conventions.

Depending on the size of the Azure VM different throughputs can be reached in regards to emails per minute.

Tests have shown the following results for Standard A Virtual Machines:

Deployment

The following steps describe a simple deployment of NoSpamProxy Azure.

Go to Azure Marketplace and search for NoSpamProxy, select the NoSpamProxy Azure Edition.

Click Create to configure the NoSpamProxy Azure system.

Configure the required parameters as needed

• Name
  System name which is added to Azure DNS and externally resolvable.
• VM disk type
  When selecting SSD as VM disk type, you must choose an Azure VM supporting SSD in a following step.
• User name, Password
  User name of the local administrator account
  As the Azure VM is accessible via RDP from the internet by default, you should use a non-trivial user name and password.
• Subscription
  Azure subscription to add the Azure resources to.
• Resource group
  Resource group for the new Azure resources. The example creates a new resource group.
• Location
  Azure region for the new resource group.

Select an appropriate virtual machine type. NoSpamProxy Azure doesn't have extraordinary system requirements for processor and memory. SQL Server 2014 Express is downloaded and installed as part of the standard setup of NoSpamProxy. Even SQL Server 2014 Express can be run on a standard VM..

All other settings remain unchanged for this simple deployment. You can adjust the settings, if required for your individual deployment. Especially if you want to utilize exisiting resources.

• Storage Account
  Storage for Azure VM VHD files
• Virtual Network
  Azure virtual network for the new Azure VM
• Subnet
  Azure virtual network subnet
• Public IP Address
  External IP address
• Network Security Group
  Network firewall configuration

Verify the technical summary and click OK to add the configured system to your shopping cart.

Verify the selected Azure service offering and the configured virtual machine. Click Purchase to buy the selected subscription. The deployment is a so called BYOL Deployment and requires a valid NoSpamProxy trial license or an existing full license. After the NoSpamProxy setup as been completed in the virtual machine you will be redirected to a web page to request a trial license.

Connect to the newly deployed virtual machine using Remote Desktop. After first log on NoSpamProxy setup will start automatically as part of an scheduled task. The scheduled task will execute the following steps:

• Configure the preinstalled SQL Server Express Edition
• Download and setup of the most current release of NoSpamProxy
• Redirect to the NoSpamProxy Azure web page to request a trial license
• Removal of the scheduled task

Do not close or interrupt the Windows PowerShell window.

After the setup has finished the public web page of NoSpamProxy Azure Edition will be opened in Internet Explorer. After initial setup of the operating system Internet Explorer runs in secure mode. Therefore, a security warning is displayed. Just add the web page to the list of exclusions and request your personal NoSpamProxy trial license.

The program setup adds new security groups and adds the logged on account to these security groups. It is required to log off and log on again to reflect the new group memberships. This is mandatory to sucessfully manage NoSpamProxy.

After log on start the NoSpamProxy Configuration MMC to import the license.

The NoSpamProxy Configuration MMC displays the NoSpamProxy version.

After initial import of the license you can start configuring NoSpamProxy to suit your needs.

Links

• NoSpamProxy Azure
• NoSpamProxy Protection
• Blogartikel: Gateway based email encryption with Office 365
• Microsoft Azure Trial
• Microsoft Azure Reverse DNS
• Microsoft Azure Reverse DNS mit der CLI

Die E-Mail Gateway Lösung NoSpamProxy von Net at Work ist seit Kurzem als NoSpamProxy Azure Edition im Azure Marketplace verfügbar. Somit kann NoSpamProxy auch dann für den Schutz der E-Mail Kommunikation eingesetzt werden, wenn keine eigenen IT-Systeme für den Betrieb von NoSpamProxy zur Verfügung stehen.

Die in NoSpamProxy Azure integrierte Möglichkeit zur Anbindung von Office 365 bietet eine einfache und kostengünstige Möglichkeit zur zentralen Ver-und Entschlüsselung von E-Mails und zur sicheren Spamabwehr.

Das aktuell verfügbare Paket installiert eine Single-Server Variante, bei der die NoSpamProxy Intranet-Rolle und die Gateway-Rolle auf einem System kombiniert betrieben werden.

Die NoSpamProxy Azure Edition wird als BYOL (Bring Your Own License) System bereitgestellt und erfordert neben den Betriebskosten in Microsoft Azure den Erwerb einer NoSpamProxy Lizenz. Eine bereits vorhandene Lizenz für die aktuelleste NoSpamProxy Version kann bei einer Migration zu Microsoft Azure weiter verwendet werden.

Inhaltsübersicht

Betriebsmöglichkeiten
Hinweise
Bereitstellung
Links

Betriebsmöglichkeiten

NoSpamProxy Azure kann auf unterschiedliche Weise in Microsoft Azure betrieben werden. Das System wird standardmäßig als Workgroup System und somit ohne eine AD-Mitgliedschaft in Microsoft Azure bereitgestellt. Die einzelnen Betriebsmöglichkeiten von NoSpamProxy Azure leiten hauptsächlich dadurch ab, ob zwischen der eigenen IT-Infrastruktur und Microsoft Azure ein Site-2-Site VPN besteht oder nicht.

• Ohne Site-2-Site VPN zu Microsoft Azure
   
  • Ein lokaler E-Mail Server (z.B. Exchange Server oder SmarterMail) nutzt NoSpamProxy Azure als externen Relay Server für ausgehende E-Mail Nachrichten, eingehende E-Mail Nachrichten werden von NoSpamProxy Azure über das Internet an den lokalen E-Mail Server weitergeleitet.
     
  • Manuelle Pflege der unternehmensinternen E-Mail Adressen mit Hilfe einer Textdatei – Automatischer Import der Textdatei durch NoSpamProxy Azure
    Diese Variante ist nur empfehlenswert, wenn die Anzahl der zu verwaltenden E-Mail Adresse überschaubar ist, da alle Adressen in einer Importdatei gepflegt werden müssen.
     
  • Optimal für Office 365 Kunden, die Benutzerkonten und E-Mail Postfächer nur in Office 365 pflegen, kein lokales Active Directory nutzen
    Die für NoSpamProxy Azure erforderliche Importdatei kann durch einen Export aus Office 365 einfach erstellt werden.
     
  • Einschränkung des RDP Zugriffes auf das NoSpamProxy Azure System auf eine externe IP-Adresse des Unternehmensnetzwerkes.
     
• Mit Site-2-Site VPN zu Microsoft Azure
   
  • Ein lokaler E-Mail Server (z.B. Exchange Server oder SmarterMail) nutzt NoSpamProxy Azure als internen Relay Server für ausgehende E-Mail Nachrichten, eingehende E-Mail Nachrichten werden von NoSpamProxy Azure über das Site-2-Site VPN an den lokalen E-Mail Server weitergeleitet.
     
  • Automatischer Import der unternehmensinternen E-Mail Adresse aus einem LDAP Verzeichnis (z.B. Active Directory)
    Dies Variante vereinfacht die Verwaltung, da im LDAP Verzeichnis erstellte Benutzer automatisch in NoSpamProxy importiert werden.
     
  • Optimal für Office 365 Kunden, die Benutzerkonten in einem lokalen LDAP Verzeichnis pflegen und eventuell sogar eine Office 365 Hybrid-Konfiguration nutzen
     
  • Einschränkung des RDP Zugriffes auf das NoSpamProxy Azure System aus dem internen Netzwerk.

Aktuell wird eine direkte Anbindung an Azure AD nicht unterstützt, ist aber in Planung.

Hinweise

• Der Azure Service für das NoSpamProxy Azure System erfordert eine Reverse-DNS Konfiguration, damit externe SMTP Server eine Reverse-DNS Prüfung erfolgreich durchführen können. Einen Link zur Reverse-DNS Konfiguration in Azure finden Sie in unter Links.
   
• Der Name für das NoSpamProxy Azure System sollte nicht der internen IT Namenskonvention entsprechen, da der Service-Name extern auflösbar ist.

Je nach ausgewählter Azure VM können unterschiedliche Datendurchsätze hinsichtlich der verarbeiteten E-Mails pro Minute erreicht werden.

Lasttests auf Basis von Standard A Maschinen haben folgendes Ergebnis gebracht:

Bereitstellung

Die nachfolgenden Schritte beschreiben die einfache Bereitstellung von NoSpamProxy Azure.

Suchen Sie im Azure Marketplace nach NoSpamProxy und wählen Sie die NoSpamProxy Azure Edition aus.

Klicken Sie auf Create, um das NoSpamProxy Azure System zu konfigurieren.

Konfigurieren Sie die Parameter für

• Name
  Name des Systems, dieser Name wird im Azure DNS eingetragen und ist somit extern auflösbar.
• VM disk type
  Bei Auswahl von SSD muss in einem nachfolgenden Schritt auch ein Azure VM Typ ausgewählt werden, der SSD unterstützt.
• User name, Password
  Benutzername des lokalen Administratorkontos
  Da das System in seiner Standardkonfiguration per Remote Desktop aus dem Internet erreichbar ist, sollte hier ein nicht trivialer Benutzername und ein komplexes Kennwort gewählt werden.
• Subscription
  Azure Abonnement in dem das System erstellt werden soll.
• Resource group
  Auswahl der Resource Group, in der das System  erstellt werden soll. In diesem Beispiel wird eine neue Resource Group erstellt.
• Location
  Azure Region, in der die neue Resource Group erstellt werden soll.

Wählen Sie einen passenden VM Typ. NoSpamProxy hat keine großen Anforderungen an Prozessor und Arbeitsspeicher. Der verwendete SQL Server 2014 Express kommt initial mit einem kleinen System zurecht.

In diesem einfachen Beispiel bleiben die weiteren Einstellungen unverändert. Diese können bei Bedarf individuell angepasst werden, um bereits bestehende Ressourcen zu nutzen.

• Storage Account
  Speicherort für die VHD Dateien der VM
• Virtual Network
  Zu verbindendes Netzwerk für das neue System
• Subnet
  Gewünschtes Subnetz aus dem virtuellen Netzwerk
• Public IP Address
  Externe IP-Adresse
• Network Security Group
  Netzwerk Firewall Konfiguration

Prüfen Sie in der technischen Zusammenfassung die Einstellung und klicken Sie OK, um die das konfigurierte System in den Warenkorb zu legen.

Prüfen Sie auf der Angebotsseite den ausgewählten Azure Service und die konfigurierte VM. Klicken Sie auf Purchase, um den Service und das Systemabo zu kaufen. Da es sich um ein BYOL Deployment handelt, benötigen Sie für die Konfiguration entweder eine NoSpamProxy Testlizenz oder eine gültige NoSpamProxy Volllizenz.

Melden Sie sich nach der erfolgreichen Erstellung des System per Remote Desktop an. Bei der ersten Anmeldung wird die Installation von NoSpamProxy durch einen Scheduled Task gestartet. Der Task führt folgende Schritte durch:

• Konfiguration des vorinstallierten SQL Server Express
• Download und Installation der aktuellen Version von NoSpamProxy
• Aufruf der öffentlichen NoSpamProxy Azure Webseite
• Entfernung des Scheduled Task

Schließen oder Unterbrechen Sie das Windows PowerShell Fenster nicht.

Nach Abschluss der Installation wird die öffentliche Webseite von NoSpamProxy Azure aufgerufen. Da der Internet Explorer zu diesem Zeitpunkt noch im abgesicherten Modus läuft, erscheint ein Warnhinweis. Nehmen Sie NoSpamProxy in die Liste der Ausnahmen auf. Über diese Webseite können Sie Ihre persönliche Testlizenz anfordern.

Durch die Installation von NoSpamProxy wurden Gruppenmitgliedschaften für das Benutzerkonto des angemeldeten Administrators geändert. Um NoSpamProxy verwalten zu können, müssen Sie sich einmal ab- und wieder anmelden.

Starten Sie nach der erneuten Anmeldung die NoSpamProxy Verwaltungskonsole um beginnen Sie mit dem Import der Testlizenz oder Ihrer vorhandenen Volllizenz.

In der Verwaltungskonsole können Sie auf der rechten Seite die installierte Version von NoSpamProxy ablesen.

Nach dem Import der Lizenz erfolgt die individuelle Konfiguration von NoSpamProxy für Ihre Anforderungen.

Links

• NoSpamProxy Azure
• NoSpamProxy Protection
• Blogartikel: Zentrale E-Mail Verschlüsselung mit Office 365
• Blogartikel: Sichere E-Mail Kommunikation mit NoSpamProxy 11
• Microsoft Azure Trial
• Microsoft Azure Reverse DNS
• Microsoft Azure Reverse DNS mit der CLI

Mit Exchange Version 2013 wurden die sog. Modernen Öffentlichen Ordner (Modern Public Folder) eingeführt. In den vorherigen Produktversionen von Exchange Server erfolgte die Replikation der Öffentlichen Ordner mit einer eigenen Replikationstechnologie. Die öffentlichen Ordner bis einschließlich Exchange Server 2010 bezeichnet man als Legacy Public Folder oder als Öffentliche Ordner alter Bauart.

Im April 2017 habe ich bereits die Herausforderungen aufgezeigt, die bei der Migration von Öffentlichen Ordner innerhalb einer lokalen Exchange Organisation auftauchen. Dieser Blogartikel behandelt die Migration von Legacy Public Foldern zu Exchange Online.  

Exchange Online unterstützt die direkte Migration von Legacy Public Foldern aus der lokalen Exchange Organisation zu Modern Public Foldern in Exchange Online. Da es sich hierbei technisch um eine Migration über Exchange Organisationsgrenzen hinweg (sog. Cross-Forest Migration) handelt, ergeben sich ganz eigene Herausforderungen. 

Voraussetzung

Die Postfach-Migration aus einer lokalen Exchange Organisation hin zu Exchange Online erfordert immer die Konfiguration eines Migrationsendpunktes. Über diesen Endpunkt greift Exchange Online auf einen lokal installiert Exchange Server 2016 mit Hybrid Funktion zu.

Das nachfolgende Schaubild zeigt die Zugriffswege für die Migration von Postfächern und die Migration von Öffentlichen Ordnern von Exchange Server 2010 zu Exchange Online. Der Zugriffsweg zur die Migration von Exchange-Postfächern ist grün dargestellt, der für die Migration von Öffentlichen Ordner blau.

Exchange Server 2016 arbeitet bei der Migration von Postfächern als Proxy und nimmt in unserem Beispiel Verschiebeanforderungen von Exchange Online per Exchange Web Service (EWS) unter dem Hostnamen ews.varunagroup.de entgegen. Der Migrationsendpunkt für Exchange-Postfächer kann nicht für die Migration von Legacy Public Foldern verwendet werden. Die Migration der Legacy Public Foldern erfolgt über einen OutlookAnywhere Migrationsendpunkt vom Typ Public Folder. Ein Endpunkt dieses Typs kann im Exchange Admin Center nicht manuell erstellt werden. Die Erstellung erfolgt im Rahmen der Einrichtung des Migrationsbatchs mit Hilfe der Exchange Online Remote PowerShell.  Für die Einrichtung des Migrationsendpunktes wird ein Benutzerkonto (Migrationskonto) im lokalen Active Directory benötigt, dass Organisationsadministrator ist.    

Wenn Sie den externen OutlookAnywhere Zugriff auf Exchange Server 2010 bereits entfernt haben oder ihn noch nie in Betrieb hatten, so müssen Sie diesen Zugriff konfigurieren. Die externe Verfügbarkeit eines OutlookAnywhere Endpunktes ist für die Migration der Legacy Public Folder zu Exchange Online eine Voraussetzung. 

E-Mail aktivierte Öffentliche Ordner

Ein Wort zu E-Mail-aktivierten Öffentlichen Ordnern. E-Mail-aktivierte Öffentliche Ordner hatten in der Vergangenheit ihre Daseinsberechtigung, sind aber in der heutigen Zeit nicht mehr State-of-the-Art. Sie sollten darüber nachdenken, E-Mail-aktivierte Öffentliche Ordner durch eine zeitgemäße Lösung ersetzen. Wenn Sie die Öffentlichen Ordner Hierarchie zu Office 365 migrieren und anschließend zu etwas Neuem wechseln möchten, bringen Sie vielleicht die Funktionen von Microsoft Teams weiter. 

Im Beispiel dieses Artikels gab es zu Beginn der Postfach-Migration in der Exchange Organisation E-Mail-aktivierte Öffentlichen Ordner, die mit Hilfe des Scripts Sync-MailPublicFolders.ps1 (Download) zu Office 365 manuell synchronisiert wurden. Dies war erforderlich, damit Anwender mit einem Postfach in Exchange Online E-Mail-Nachrichten an diese Öffentlichen Ordner senden konnten.  

Als Teil der Vorbereitungen zur Migration der Öffentlichen Ordner zu Exchange Online wurden Funktionen der E-Mail-aktivierten Ordner in Freigegebene Postfächer migriert. Hierzu gehörte damit auch die Deaktivierung der E-Mail Funktionen der betroffenen Öffentlichen Ordner. 

Migrationsschritte

Der Ablauf einer Migration der Öffentlichen Ordner von Exchange Server 2010 zu Exchange Online ist im Grundsatz identisch zur Migration zu Exchange Server 2016 in einer lokalen Exchange Organisation. Der Hauptunterschied liegt in der Konfiguration des Migrationsendpunktes und des Remote-Migrationsbatches.

Die Schritte sind: 

1. Prüfung der Öffentlichen Ordner Namen auf nicht unterstützte Zeichen, wie z.B. "\" "/", und führende oder nachstehende Leerzeichen 
    
   Die Namen der Öffentlichen Ordner müssen vor der Erstellung der Migrationsdateien für eine Migration vorbereitet werden. Sie dürfen keine führenden oder nachstehenden Leerzeichen enthalten. Ebenso dürfen Sie kein "\" oder "/" enthalten, da diese Zeichen in den weiteren Schritten als Trennzeichen für Ordnerebenen identifiziert werden. Hier müssen Sie sich für ein alternatives Trennzeichen entscheiden, wie z.B. "|".  
    
   Hierzu finden Sie in PowerShell-Skript in der TechNet Gallery: https://gallery.technet.microsoft.com/Rename-and-Trim-Legacy-85e483b1 
    
2. Erstellung eines aktuellen Snapshots der gegenwärtigen Öffentlichen Ordner Umgebung 
   
   Hierzu verwenden Sie die von Microsoft im TechNet Artikel bereitgestelten PowerShell Einzeiler. Diese Snapshots haben nur informellen Charakter, da sie in den weiteren Schritten nicht verwendet werden. 
    
3. Download und Ausführung der Legacy Public Folder Migrationsskripte
   
   Laden Sie die Migrationsscripte herunter und führen Sie die Scripte, wie im TechNet Artikel beschrieben aus. 
    
4. Prüfung und Anpassung der Grenzwerte (Quota) zur Bereitstellung von Nachrichten in Modernen Öffentlichen Ordnern in Exchange Online 
    
   Ohne eine Anpassung der Standardgrenzwerte für Modern Public Folder in Exchange Online, steigt das Risiko, dass es bei der Migration der Ordnerinhalte der Legacy Public Folder zu einem Fehler kommt. Der Standardgrenzwert für die Bereitstellung in einen Öffentlichen Ordner ist 2GB.
     

   # Quota für die Migration ganz aufheben
   Set-OrganizationConfig -DefaultPublicFolderProhibitPostQuota Unlimited -DefaultPublicFolderIssueWarningQuota Unlimited

5. Einrichtung des Migrationsendpunktes und Migrationsbatches 
    
   Bei der Einrichtung des Migrationsendpunktes ist es wichtig, dass die Authentifizierungsmethode verwendet wird, die für Ihren OutlookAnywhere Endpunkt konfiguriert ist. Das Beispiel im TechNet konfiguriert Basic als Authentifizierungsmethode. Hier muss als Alternative NTLM konfiguriert werden, wenn OutlookAnywhere in Ihrer Umgebung für NTLM konfiguriert ist. 
    
   Sollte die Legacy Public Folder Hierarchie zu diesem Zeitpunkt noch Fehler, wie z.B. Ordner mit nicht ungültigen Ordnernamen beinhalten, so wird die Einrichtung des Batchs fehlschlagen. In diesem Fall müssen Sie die Fehler beheben und die Einrichtung des Batches wiederholen. 
   
   In diesem Schritt wird das Migrationsbatch nur eingerichtet und nicht automatisch gestartet.
    
6. Start des Migrationsbatchs
   
   Nach dem Start des Batchs erfolgt die erste Synchronisation der Ordnerinhalte und auch der Hierarchie. Nach Abschluss der Synchronisation können Sie für jedes Zielpostfach der Öffentliche Ordner Postfächer prüfen, ob es Probleme mit den Inhalten gab und aufgetretene Probleme beheben. Das Postfach zur Speicherung der primären Hierarchie der Öffentlichen Ordner wird Fehler anzeigen die sich auf die Hierarchie beziehen. Ein Fehlerszenario im Zusammenhang mit E-Mail-aktivierten Ordnern ist unten beschrieben.
   
   Nach Abschluss der ersten Synchronisierung erfolgt alle 24 Stunden eine inkrementelle Synchronisierung.
    
7. Finalisierung des Migrationsbatchs
   
   Mit der Finalisierung des Batchs wird eine letzte Synchronisation der Legacy Public Folder Inhalte ausgelöst. Für die Finalisierung werden die Legacy Public Folder für den Zugriff durch Endanwender gesperrt. Damit diese Sperrung zeitnah angewandt wird, sollten Sie auf den Exchange 2010 Servern, die die Public Folder Datenbank hosten, den Dienst MSExchangeIS neustarten.
   
   Die Finalisierung wird einige Zeit in Anspruch nehmen. Da während dieser Zeit Anwender keine neuen Daten in den Legacy Public Foldern ablegen können, muss diese Finalisierung während eines Wartungsfensters stattfinden.
   
   Tipp
   Kopieren Sie die Datenbanken vor dem finalen Abschluss der Migration auf ein anderes System, um im Anschluss auf die alten Inhalte mit Tools, wie z.B. Veeam Exchange Explorer, zugreifen zu können. Aktivieren Sie vor dem Erstellen der Kopien die Umlaufprotokollierung.
    
8. Testzugriff auf die migrierten Inhalte
   
   Sie testen den Zugriff auf die migrierten Öffentlichen Ordner, indem Sie die erste Public Folder Mailbox für den Zugriff auf die Hierarchie freigeben und für den Test-Benutzer die Default Public Folder Mailbox konfigurieren.
    

   # Erste Public Folder Mailbox freigeben
   Set-Mailbox Mailbox1 -PublicFolder -IsExcludedFromServingHierarchy:$false
   
   # Default Public Folder Mailbox für Test-Benutzer setzen
   Set-Mailbox -Identity JohneDoe@varunagroup.de -DefaultPublicFolderMailbox Mailbox1

9. Abschluss der Migration
   
   Der Abschluss der Migration in der lokalen Exchange Organisation führt dazu, dass die Öffentliche Ordner Hierarchie entfernt wird. Sie haben anschließend keinerlei Möglichkeit mehr, auf normalem Weg auf Daten der Öffentliche Ordner zuzugreifen. Achten Sie nach dem Abschluss der Migration darauf, dass alle Öffentlichen Ordner Postfächer in Exchange Online die Hierarchie bereitstellen. 

   # Alle Public Folder Postfächer für den Hierarchie-Zugriff freigeben
   Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false
   
   # Öffentlichen Ordner Zugriff auf "local" setzen (aus Sicht der Office 365 E-Mail Postfächer)
   Set-OrganizationConfig -PublicFoldersEnabled Local

   
   Die Änderung des Zugriffes auf Öffentliche Ordner wird den Clients über die automatische Konfiguration (AutoDiscover) bereitgestellt. Durch das Caching der Konfiguration kann es mehrere Stunden dauern, bis alle Clients die neue Konfiguration verwenden. Planen Sie diese zusätzliche Zeit in das Wartungsfenster zur Finalisierung ein.

Migrationsfehler mit E-Mail-aktivierten Öffentlichen Ordnern

Wie bereits erwähnt, wurden alle E-Mail-aktivierten Ordner vor der Migration zu Exchange Online deaktiviert und das Skript zur Synchronisation der E-Mail-aktivierten Öffentlichen Ordner mit Office 365 ausgeführt. Leider führt das Skript nicht alle notwendigen Schritte aus, um die Informationen in Exchange Online korrekt zu entfernen.

Fehlermeldung im Migrationsbatch:

"Error: More than N mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important"

Lösung

Sie müssen die nicht mehr vorhanden Ordner manuell mit Hilfe der Exchange Online Remote PowerShell löschen. Mit dem nachfolgenden Beispiel löschen Sie alle E-Mail aktivierten Öffentlichen Ordner, die mit Hilfe des Skriptes  Sync-MailPublicFolders.ps1 in Exchange Online erstellt wurden.

# Löschung eines einzelnen ehemals E-Mail-aktivieren Öffentlichen Ordners in Exchange Online
Get-MailPublicFolder 'My Mail Public Folder' | Remove-SyncMailPublicFolder

# Löschung aller ehemals E-Mail-aktivierten Öffentlichen Ordner in Exchange Online
Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder

Zusammenfassung

Die Migration von Legacy Public Foldern zu Exchange Online ist nicht schwer. Sie erfordert aber, dass die zu migrierende Hierarchie der Öffentlichen Ordner vorbereitet wird und Ordnernamen keinen unzulässigen Zeichen enthalten. Ebenso muss ein passender OutlookAnywhere Endpunkt aus dem Internet erreichbar sein. Ohne einen OutlookAnywhere Endpunkt und ohne ein berechtigtes Migrationskonto kann der Migrationsbatch von Exchange Online keine Daten kopieren.

Stellen Sie die E-Mail-Aktivierung von Öffentlichen Ordnern in Frage und suchen Sie modernere Lösungen. Eventuell notwendige Umzüge von E-Mail-Adressen müssen vor der Migration der Öffentlichen Ordner abgeschlossen sein.

Planen Sie für die Finalisierung der Migration genügend Zeit ein. Im direkten Vergleich zu lokale durchgeführten Modern Public Folder Migrationen benötigten Finalisierungen von Migrationen zu Exchange Online das Vierfache an Zeit. Bedenken Sie, dass nach einer Umstellung des Public Folder Zugriffes für die Postfachnutzer in Exchange Online es noch mehrere Stunden dauern kann, bis die Konfigurationsänderungen durch Outlook Clients genutzt werden.

Viel Spaß mit modernen Öffentlichen Ordnern.

Links

• Download der Public Folder Migrationsscripte
• Use batch migration to migrate legacy public folders to Office 365 and Exchange Online

Das Thema "Cloud" provoziert sehr unterschiedliche Reaktionen. Die einen lehnen sie Grund weg ab und die anderen verehren sie, ohne sie zu hinterfragen.

Der Begriff "Cloud" ist mehr als Zusammenfassung von "*aaS" (Sternchen as a Service) Angeboten zu sehen, die von unterschiedlichen Anbietern zur Verfügung gestellt werden. Alle Dienste, wie eine Person oder ein Unternehmen im Internet verwenden kann, sind als Cloud-Dienstleistung zu anzusehen.

Die wichtigste Erkenntnis, zu der man als Unternehmen gelangen muss, ist, dass die "Cloud" nicht zum Selbstzweck existiert und man nicht ohne eine detaillierte Cloud-Strategie einfach alle Dienste eines Anbieters nutzen kann oder nutzen sollte.

Wie bereits in unserem Blog-Artikel über das Microsoft Cloud System dargestellt, unterteilen sich die die Angebote für Unternehmen in die Bereiche Infrastruktur als Service (IaaS), Plattform als Service (PaaS) und Software al Service (SaaS).

In der letzten Zeit drängt Microsoft mit einem weiteren Angebot in den Markt, das aber eher eine Spezialvariante eines SaaS Angebots darstellt. Mit "Identität als Service" (IDaaS) möchte Microsoft die Funktionen des Azure Active Directories für die Authentifizierung von Benutzern und die Registrierung von Geräten vorantreiben. Das kommende Betriebssystem Windows 10 wird das Windows Azure Active Directory von Hause aus unterstützen und bietet damit zusätzliche Möglichkeiten für Unternehmen, die Sicherheit ihrer IT Infrastruktur zu verwalten.

Office 365

Die Cloud-Angebote von Office 365 sind klassische SaaS Angebote, die für Ihre Funktionen allerdings u.a. Azure AD Funktionen verwenden. Als Office 365 Kunden ist man somit automatisch auch Nutzer von Azure Diensten, ohne hier explizit ein Azure Abonnement eingegangen zu sein.

Ob diese Standardfunktionen weiter ausgebaut werden sollen und sich somit die Notwendigkeit eines erweiterten Azure Abonnements ergibt, legt die Cloud-Strategie des Unternehmens fest. Gerade die weiteren Möglichkeiten der Azure Dienste, jenseits des Azure AD, erfordern eine detaillierte Planung.

Die unter SaaS zusammengefassten Angebote für Anwender werden auf gerne als "Productivity Desktop as a Service" umschrieben und gliedern sich wie folgt:

Azure

Azure bietet zahlreiche Dienste, die einem steten Wandel unterliegen. Aus Microsoft Sicht dient dieser stete Wandel der Dienste nur dem Nutzen des Kunden. Dieser Wandel erfordert aber u.U. auch eine stete Anpassung der eigenen Applikationen, die diese Dienste konsumieren. Hierdurch ergibt sich zusätzlicher Aufwand, der in die Realisierungsprojekte mit eingeplant werden muss.

Die angebotenen Dienste von Azure muss man sich als Baukasten vorstellen, aus denen man sich die Dienste und den Dienstumfang aussucht, die man benötigt.

Die nachfolgende Übersicht zeigt, wie sich die einzelnen Azure-Dienste in die Bereiche Zugriffskontrolle (Access Control Layer), Integrationsdienste (Integration Layer), Applikationen (Application Layer) und Datendienste (Data Layer) unterteilen.

Für den Einsatz von Clouddienstleistungen ist es wichtig zu wissen, in welchen globalen Region die Dienste bereitgestellt werden und wo die eigenen Unternehmensdaten gespeichert werden.

Innerhalb der europäischen Union ist Microsoft gegenwärtig mit zwei Rechenzentren vertreten und gewährleistet eine Redundanz der Systeme innerhalb dieser sog. "Geo". Bereitgestellte Dienste in Office 365 und Azure werden immer nur innerhalb einer geschlossenen "Geo" redundant zur Verfügung gestellt. Somit ist ausgeschlossenen, dass Unternehmensdaten z.B. zwischen Amsterdam und Des Moines repliziert werden. Die einzige Ausnahmen ist gegenwärtig, und dies rein Technologie bedingt, das Azure Active Directory. Jedoch arbeitet Microsoft auch hier an einer Lösung, um die Replikation von Authentifizierungsdaten regional begrenzen zu können.

Sicherheit und Datenschutz

Bei der Nutzung von Cloud-Diensten, ganz unabhängig von Office 365 oder Azure, muss man immer sicherstellen, dass die rechtliche Basis für die Verlagerung von Datendiensten an einen Auftragsdatenverarbeiter gegeben ist. Gerade hier gibt es zahlreiche Mißverständnisse.

Office 365 ist gegenwärtig die erste und einzige Cloudbasierte Produktivitätslösung, die jedem Kunden die EU Model Clauses als Standardvertragklausel anbietet und diese mit einer standardisierten Erklärung zur Auftragsdatenverarbeitung (Data Processing Agreement) kombiniert.

Aber was ist sind die EU Model Clauses?

Beim Abschluss eines Abonnements zu Office 365 kommen grundsätzlich zwei Verträge mit Microsoft zustande. Zum einen ergibt sich ein Vertrag zur Auftragsdatenverarbeitung gem. § 11 BDSG, der mit Microsoft Ireland Operations Ltd. geschlossen wird. Dieser Vertrag wird nun ergänzt um die EU-Standardvertragsklausel für Auftragsdatenverarbeiter vom 5. Februar 2010. Dies ist notwendig, um das notwendige Schutzniveau zu dokumentieren, unter welchem laut § 11 BDSG Auftragsdatenverarbeiter aus nicht EU Ländern beauftragt werden können.

Das ausreichende Schutzniveau wiederum wird durch drei unterschiedliche Möglichkeiten beschrieben:

1. Sichere Drittländer
   Die Liste der sicheren Drittländer wird durch die EU-Kommission festgelegt (s. Links)
2. Safe Harbor
   Unternehmen der USA können sich im Rahmen einer Selbstzertifizierung auf die Liste der Safe Harbor Unternehmen setzen lassen. Zur Sicherheit der Unternehmen dieser Liste gibt es bisher keine verbindliche Entscheidung der EU-Kommission. Gegenwärtig sind mehr als 5.000 Unternehmen geführt.
3. EU-Standardvertragsklausel 
   Die EU-Standardvertragsklausel wurde durch die Art.29-Datenschutzgruppe der EU entwickelt. Mit Schreiben vom 2. April 2014 wurde Microsoft bescheinigt, dass die Clouddienste durch diese Klauseln gedeckt sind.

Mit dem kombinierten Vertrag zur Auftragsdatenverarbeitung und den EU-Standardvertragsklauseln, können die Anforderungen des BDSG abgebildet und damit auch sichergestellt werden.

Für kirchliche Träger wiederum ergeben sich aus dem jeweiligen kirchlichen Datenschutz (KDO, DVO KDO, DSG-EKD) andere Anforderungen. Gerade die Rechtsform des kirchlichen Unternehmens entscheidet über die Anwendbarkeit des BDSG oder der kirchlichen Verordnungen und damit über die Möglichkeiten zur Cloud-Nutzung.

Unternehmen, die Daten in der Cloud speichern, sind nicht dazu verpflichtet, einzig auf die Datenschutz- und Datensicherungsmethoden des Cloud-Anbieters zu vertrauen. Die Speicherung von Daten und Dateien kann mit verschlüsselt erfolgen. Hierbei werden die Daten bereits im internen Unternehmensnetzwerk verschlüsselt und nur in der verschlüsselten Form in der Cloud gespeichert. Die erforderlichen Schlüssel verbleiben vollständig im Besitz und unter der Kontrolle des Kunden.

Nutzen Sie als Unternehmen die Chancen, die Ihnen IT Dienstleistungen in Cloud bieten. Es gibt keine Gründe, diese Dienste nicht zu nutzen. Die gewünschte Sicherheitsstufe unterliegt hier den gleichen Auswahlkriterien wie bei der Implementierung im Rechenzentrum. 

Ihre Anwender werden Cloud Dienste auch ohne Wissen der IT nutzen. Planen Sie Ihre Cloud-Strategie, um die Kontrolle über Unternehmensdaten zu behalten.   

Links

• Übersicht Office 365, https://products.office.com/de-de/business/explore-office-365-for-business
• Übersicht der Azuredienste, http://azure.microsoft.com/de-de
• Commission decisions on the adequacy of the protection of personal data in third countries, http://ec.europa.eu/justice/data-protection/document/international-transfers/adequacy/index_en.htm
• U.S.-EU SAFE HARBOR LIST, https://safeharbor.export.gov/list.aspx
• Office 365 Trust Center, https://products.office.com/de-de/business/office-365-trust-center-cloud-computing-security
• Azure Security Center, http://azure.microsoft.com/de-de/support/trust-center/

Kontakt

Gerne unterstützen wir Sie bei der Entwicklung einer Cloud-Strategie für Ihr Unternehmen. Kontaktieren Sie uns für weitere Informationen: info@granikos.eu.

Wie fängt man am sinnvollsten mit der Nutzung von Microsoft Azure an? Wie nähert man sich diesem Thema überhaupt?

Bevor man mit der Nutzung von Microsoft Azure beginnen kann, muss man die wichtigsten Eigenschaften von Microsoft Azure kennenlernen. Einer der wichtigsten Unterschiede ist, dass es sich bei Microsoft Azure um eine Plattform handelt und nicht um ein packetiertes Produkt wie Office 365.

Mit Hilfe der nachfolgenden Links legen Sie die Basis für ein umfassendes Verständnis von Microsoft Azure. Cloudangebote sind einer schnellen Weiterentwicklung unterworfen, daher sind die meisten Informationen nach der Veröffentlichung anfangs nur in Englisch verfügbar.

• Was ist Microsoft Azure?
• Take a 3–minute tour of Microsoft Azure?
• Read the Microsoft Azure Fundamentals Document (Deutsche Version)
• Lesen Sie die Übersicht der Azure Produkte oder nutzen Sie die Interaktive Azure Übersicht

Die Anzahl der zur Verfügung stehen Dienste ist am Anfang sehr überwältigend. Um den größtmöglichen Nutzen aus den einzelnen Dienstangeboten zu ziehen ist wichtig, die gewünschten Dienste ausführlich kennenzulernen. Dies benötigt Zeit. Diese sollten Sie sich nehmen.

Ein Clouddienst wie Microsoft Azure kann nur dann erfolgrich genutzt werden, wenn man sich dem Thema Vertrauen und Sicherheit stellt. Microsoft bietet hierzu ausführliche Informationen im Microsoft Azure Trust Center. Wie Microsoft Kundendaten in der Cloud schützt wird sehr anschaulich in diesem Video gezeigt.

Microsoft Azure ist nicht der einzige Anbieter von Clouddiensten. Für einen Vergleich mit Amazon AWS stehen folgende Informationsquellen zur Verfügung:

• Microsoft Azure vs. Amazon Web Services (AWS)
• Microsoft Azure vs. Amazon Web Services Mapping
• Microsoft Azure for AWS Professionals Video Series

Fallbeispiele für eine erfolgreiche Nutzung von Azure helfen Ihnen, einer Nutzung von Clouddiensten das erforderliche Vertrauen entgegen zu bringen.

• Kundenreferenzen (DE) für Microsoft Azure

Starten Sie noch heute mit Microsoft Azure

• Erstellung eines Microsoft Azure Testkontos mit €170 Guthaben
• Übersicht der kostenfreien Dienste in Microsoft Azure
• Microsoft Azure Optionen für MSDN-Abonnenten

Viel Spaß und Erfolg mit Microsoft Azure.