Google Suite

Office 365 ist nicht der einzige Anbieter von Office Diensten in der Cloud. Slack wird gerne mit Teams verglichen, OneDrive muss sich mit Dropbox und Google Drive vergleichen lassen. Wenn es aber um "Office" geht, dann gibt es neben Office 365 mit Word Online natürlich noch die Google Suite (G Suite) und die Frage wird sicher gestellt, ob Microsoft "alternativlos" ist.

Ich habe mich daher mal aufgemacht zu beschreiben, wie sich die G Suite gegenüber Office 365 behaupten kann.

Die hier beschriebenen Daten basieren auf einer Betrachtung im April 2018. Sowohl Microsoft als auch Google entwickeln ihr Angebot natürlich weiter. Die Seite könnte schon wieder veraltet sein.

Was ist die G Suite?

Office 365 ist für viele Personen immer noch "Word, Excel, PowerPoint, Outlook " und die Services "Exchange Postfach, OneDrive und SharePoint" im Backend. Die Google Suite (Kurz G Suite für Unternehmen) enthält ähnliche Funktionen und unterscheidet sich dennoch. Zunächst gibt es drei Ausprägungen:

Produkt Basic Business Enterprise
Kosten

4€

8€

23€

Funktionen

  • G Mail - Geschäftliche Mail
    per IMAP, POP3, Browser, GMail-App
  • Hangout
    Audio/Video Konferenzen
  • Dokumente
  • Tabellen
  • Präsentationen
  • Notizen
  • Formulare
  • 30 GB Speicher pro Benutzer
    Für Mailbox, GoogleDrive u.a.

Basisfunktion zzgl.

  • Erweiterte Suche
  • E-Discovery
  • 1TB/unlimited pro User
  • ActiveSync Support

Business zzgl.

  • Erweiterte Wiederherstellung
  • 3rd Party Archiv-Option
  • Protokollanalyse
  • Telefon Einwahlnummer in Hangout Konferenzen.
  • erweiterte MDM-Funktion
  • serverseitiges SMIME

Schon diese kurze Übersicht zeigt aber auch, dass die Basic-Version quasi die werbefreie Version das kostenfreie GMail/GoogleDrive-Angebot ist und Firmen zumindest mit Business starten sollten.

Google bedeutet 100% Cloud
Wenn ich die G Suite mit Office 365 vergleiche, dann könnte die Basic/Business-Version am besten mit der E1-Verion verglichen werden kann. Zur Enterprise-Version gibt es aber kein entsprechendes Gegenstück, da die E3-Version auch Applikationen für den lokalen PC enthält. Bei Google findet Textverarbeitung immer im Browser (idealerweise Chrome) statt und die Daten liegen immer im Google Drive. Zwar können Anwender Dateien auch synchronisieren und in teilen "offline" Verarbeiten aber der Zwang  zur Cloud ist sicher gewöhnungsbedürftig.

Office 365 und G-Suite

Ich gehe davon aus, dass die meisten meiner Leser sich mit Office 365 besser auskennen oder zumindest die Microsoft Produkte on-premises einsetzen. Die folgende Tabelle beschreibt in Kürze was G Suite für so eine Umgebung bedeutet:

Funktion

Beschreibung

Zielsystem

Benutzerverwaltung, Verzeichnisabgleich

Lokale und Office 365 Dienste Exchange nutzen das lokale AD zur Speicherung von Mailadresse, Konfigurationseinstellungen etc. bezüglich der Empfänger. Die Verwaltung ist in den Betriebsablauf integriert. Eine Nutzung einer Cloud sollte keine Doppelpflege erfordern. In Office 365 ist dazu das Office 365 Identity Management vorhanden.

Über GCDS ist es möglich, die Konten, Gruppen u.a. in der G Suite abhängig vom lokalen AD zu pflegen. Die Funktion ist vergleichbar zu Office 365 AADConnect. Die Replikation erfolgt immer vom lokalen Active Directory zur Google Suite.

Hier gibt es durchaus noch Detailfrage zu klären, wie GCDS funktioniert. So gibt es den Bedarf bestimmte Objekte (Dienstkonten, Administratoren etc.) in der G Suite nicht bekannt zu machen oder auch bestimmte Feldinhalte (private Rufnummer, Personalnummer) von der Replikation auszuschließen.

Der primäre Schlüssel beim Verzeichnisabgleich ist die Mailadresse. Um Änderungen korrekt zu verfolgen erzeugt der Sync-Prozess einen UniqueKey pro Objekt, der auf dem DirSync Service hinterlegt wird. So kann auch eine Änderung der Mailadresse erkannt werden. Bei einer Verlagerung des DirSync auf einen anderen Server wird der Key neu generiert (Matching). In der Zeit der Migration muss natürlich eine Änderung der Mailadresse unterbleiben. Der DirSync Prozess nutzt den Install4j-Installer um eine Java Applikation zu installieren. Der frühere Name des Programms lautete “Google Apps Directory Sync (GADS)”

Achtung: Beim Einrichten des Sync ist unbedingt die „GCDS best practices“ https://support.google.com/a/answer/7177267  zu beachten. Dies gilt insbesondere bezüglich des „Löschens“ von Objekten in G Suite aufgrund fehlender Objekte im AD.

„Set GCDS to suspend accounts that aren't found in Microsoft® Active Directory® or your LDAP directory. Deleted accounts can't be retrieved. If you suspend the account instead, the information in the account is retained. Also you can transfer email and Google Drive content to another account if the account is suspended”.

Dazu ist die Einstellung “Set "Delete no more than “0” organization, users or groups.“ am Anfang ratsam. Auch sollten administrative Konten generell ausgeschlossen werden.

Lizenzmanagement

On-premises sind die Exchange Server Lizenzen und die CALs nur „nachzuweisen“ aber werden nicht hart überprüft.

Jedem Anwender in der G Suite muss eine passende Lizenz (Basic, Business, Enterprise) zugewiesen werden. Das kann automatisch, manuell oder über den Verzeichnisabgleich erfolgen.

Benutzerauthentifizierung

Benutzer melden sich schon heute an ihrem PC lokal gegen das AD an. Auch der Zugriff auf Exchange wird damit danke Kerberos integriert abgedeckt. Siehe dazu auch Authentifizierung.

Ideal ist eine „nahtlose“ Anmeldung oder zumindest die Nutzung des gleichen Kennworts. GCDS kann ungesalzene SHA1- und MD-5 Kennworte replizieren, was aber nicht sicher genug ist. Daher ist der Einsatz eines Authentifizierungsdienstes ratsam, so dass auch lokal deaktivierte, gesperrte oder gelöschte Anwender nicht weiter mit Google Diensten arbeiten können.

Achtung: Mehrere Anleitungen beschreiben den umgekehrten Weg, wie andere Dienste das „Google Konto“ als Authentication Provider nutzen können

Für die geplante Umsetzung scheiden getrennte Kennworte ebenso aus wie ein Kennwort-Sync mit schwach verschlüsselten Kennworten (SH1/MD5). Die Anmeldung an der G Suite sollte per ADFS erfolgen, wozu der Service natürlich entsprechend „hochverfügbar“ bereitgestellt werden muss. Aktuell ist es nur ein Single Server. Das Setup ist identisch zu einer Office 365 Implementierung.

Postfachspeicher

Aktuell stellt Exchange für jeden Anwender ein Postfach bereit.

Jeder "Basci"-Benutzer hat 30 GB Gesamtspeicher für G-Mail, Google Foto und Google Drive. Bei G Suite Enterprise und G Suite Business sind es 1TB oder ab 5 Benutzern „unlimited“

Postfachzugriff Outlook/MAPI

Der Zugriff ist per Outlook über MAPI (RPC oder http) möglich. Die Mails liegen auf dem Server und werden lokal repliziert. Outlook kann problemlos auch „offline“ genutzt werden

Der primäre Weg der G Suite ist der Browser. Mit Chrome können die Mails sogar „offline“ vorgehalten werden. Alternativ ist eine Anbindung über die Internet Standards (POP3/IMAP4) mit verschiedenen Clients (Outlook, Windows Mail, Thunderbird etc.) möglich. Für eine bessere Anbindung von Outlook gibt es zusätzlich die „G Suite Sync for Microsoft Outlook“, welche auf dem Client installiert werden kann um Mails, Kontakte, Termine, Aufgaben zwischen dem lokalen Outlook und dem G Suite Postfach abzugleichen.

GSSMO kann manuell auch konfiguriert werden, um Frei/Belegt-Zeiten abzufragen.

Achtung: Outlook ist lizenzpflichtig und muss entsprechend lizenziert werden.

Achtung: Diverse 3rd Party Programme nutzen immer noch CDO/MAPI, um auf Postfächer zuzugreifen. Diese Exchange-API ist schon lange abgekündigt und mit Google G Suite nicht mehr nutzbar

Exchange Datenmigration

Die Migration von Exchange Postfächern zu Office 365 ist per Cutover, Staging oder Hybrid je nach Firmengröße und Umgebung möglich.

Mit der Installation von GSSMO wird auch „G Suite Migration for Microsoft Outlook“ (GSMMO )installiert, die Daten aus PST-Dateien und Exchange Postfächern exportieren und in das G Suite Konto importieren kann. Migriert werden  E-Mails, Kontakte, Kalendertermine und Outlook-Notizen. Zudem können Aufgaben und Journaleinträge migriert werden, die aber später nur in Outlook (nicht in G Suite Web oder IMAP4) sichtbar sind.

Über Kommandozeilen kann auch ein Administrator die Benutzerdaten vieler Benutzer (über Vollzugriff auf die Quellpostfächer, keine EWS Impersonation) Für „Public Folder“ gibt es kein direktes Gegenstück in G Suite. Google Groups oder Google Drive werden als Alternative genannt.

Zuletzt gibt es von Google noch einen „Cloud Service“, der z.B. von Exchange die Mails, Termine und Kontakte per EWS extrahiert und zu Google überträgt. Alle anderen Quellen werden per IMAP4 serverseitig übertragen.

Eine „Koexistenz“ ist mit Bordmitteln sehr eingeschränkt. In der Regel wird das Zielkonto aktiviert und von Beginn an genutzt und das „Read-Only“-Quellkonto dann nachmigriert. Es wird nicht mit Weiterleitungen (TargetAddress) pro Postfach gearbeitet. Die Bordmittel kommen bei größeren Benutzerzahlen an ihre Grenzen.

Postfachzugriff  Browser /OWA)

Anwender können per Browser ihre Mails, Termine, Kontakte etc. nutzen. Bestimmte Funktionalitäten können per OWA Policies gesteuert werden.

Der Browser ist für G Suite der von Google präferierte Weg. Allerdings ist kein Zugriff auf Journale und Aufgaben möglich. Dies geht nur in Outlook.

Mobile Clients

Mobilegeräte nutzen bei Exchange idealerweise ActiveSync und können eingeschränkt über ActiveSync Policies und Exchange Quarantäne gesteuert werden. Für mehr Funktionen sind MDM-Lösungen (Intune u.a.) erforderlich.

Der Zugriff auf Google Mail per ActiveSync (Google Sync) ist seit dem 30. Jan 2013)  nur für kommerzielle Benutzer (G Suite, G Suite for Gouvernement, G Suite for Education, Cloud Identity und Drive for Work) möglich. Das wäre hier aber der Fall. Auf Android-Geräten gibt es einen nativen Weg Google einzubinden. Mit der Gmail-App (Android/IOS) gibt es einen eigenen Client, vergleichbar zu Outlook for IOS/Outlook for Android.

G Suite enthält ähnlich wie Exchange eine einfache MDM Lösung.

Postfachzugriff EWS

Über EWS greifen nicht nur Mac-Client sondern auch viele 3rd Party Applikationen auf Exchange Inhalte zu, z.B. Raumsysteme, Archivprodukte, Auswertungen, SAP etc.

EWS ist mit GMail nicht möglich.
Entwickler müssen den Zugriff über die Google API nutzen.

https://developers.google.com/gmail/api/guides/

„The Gmail API is a RESTful API that can be used to access Gmail mailboxes and send mail. For most web applications (including mobile apps), the Gmail API is the best choice for authorized access to a user's Gmail data“.

Delegate Zugriff EWS

Diverse Tools (ERP/CRM/Archiv) nutzen EWS Impersonation um „im Auftrag des Anwenders“ Daten zu manipulieren.

EWS ist mit GMail nicht möglich.
Entwickler müssen den Zugriff über die Google API nutzen.

Allerdings bedeutet dies, dass alle Programme angepasst oder getauscht werden müssen, die bislang EWS genutzt haben.

Postfachzugriff POP/IMAP

z.B.: Helpdesk-Systeme

Der Zugriff auf das Postfach ist natürlich per POP3/IMAP4 möglich. Es gibt ein Limit von 2,5GB/tag Down und 0,5GB /Tag Upload pro Postfach

Entsprechende Dienste, die heute Exchange per POP3/IMAP4/SMTP ansprechen, müssen dann über die Firewall mit den Google Servern kommunizieren können.

Mailrouting

Der Empfang und Versand von SMTP-Mails ist eine Grundfunktion. Dazu gehören

  • Ein/Ausgehender Spam und Virenschutz
  • Disclaimer
  • Messagetracking
  • Relaydienste für Drucker u.a.
  • Einbindung eigener Gateways
  • SMIME

Der Einsatz der G Suite ist meist damit verbunden, dass auch das Mailrouting über die Cloud erfolgt. Hier ist Google flexibel und unterstützte die üblichen Routingfunktionen. G Suite kann selbst Mails senden und direkt empfangen und Spam/Virenschutz bereitstellen. Es sind aber auch eigene Gateways möglich und G Suite kann auch als Relay für eigene Systeme verwendet werden. Google unterstützt sogar serverseitiges SMIME.

Für den Versand von internen SMTP-Sendern ist es ratsam ein lokales SMTP-Relay vorzuhalten, um an einer zentralen Stelle den Weg zum Google Mail-Relay zu verwalten und per TLS abzusichern. Ich konnte bislang nicht klären, wie die bisherigen „SendConnectoren“ mit Gmail umgesetzt werden, bei denen z. b. Mails an „smtp:sap.msxfaq.de“ von Google über ein Relay sicher z.B. zu einem internen SAP-Systemen geleitet werden.

Archiv

Viele Firmen haben neben Exchange ein Archiv-System, welches per CDO oder EWS mit Exchange interagiert.

Google bietet ebenfalls einen „Vault“ an, mit dem Mails anhand von Kriterien dort längerfristig gehalten werden können. Dieser Vault kann auch für ein „Undelete“ genutzt werden.

Hier ist zu prüfen, ob mit dem Wechsel zu GMail weiterhin ein Zugriff auf das Archiv, z.B. per URLs und Browser möglich ist oder wie die Mails aus dem Archiv wieder extrahiert und nach Gmail migriert werden können-

Restore gelöschter Objekte

Durch Anwender gelöschte Elemente landen in der Regel in einem Papierkorb, den der Anwender auch noch mal leeren kann. Dann hat ein Exchange Administrator über den Dumpster, Archivfunktionen oder notfalls eine Recovery Storage Group immer noch einen Weg die Daten zu restaurieren. Bei Dateiservern sind nach dem Papierkorb die Schattenkopien oder ein Restore möglich, sofern die Datenablage nicht selbst eine Versionierung unterstützt ( z.B. SharePoint, GIT etc.)

G Suite erlaubt sowohl die Wiederherstellung gelöschter Benutzer ( bis zu 20 Tage) als auch einzelner Mails und Dokumente, die vom Anwender aus seinem Papierkorb entfernt wurden (25 Tage).Dies gilt auch für Daten im Google-Drive.

Delegierte Administration (Helpdesk)

Exchange und Active Directory unterstützt die Delegierung von Berechtigungen für Administratoren, Helpdesk etc.

Bestimmte Routinetätigkeiten (z.B. Mails wiederherstellen, Anzeigen der Konfiguration, Messagetracking o.ä.) müssen nicht durch einen privilegierten Administrator erfolgen. Dazu muss die Plattform zum einen eine passende Verwaltungsoberfläche bereit stellen und eine Delegierung von Rollen erlauben.

Inwieweit die G Suite-Rollen für den Einsatzzweck ausreichen, ist in einer Evaluierungsphase zu klären.

Office Datenhaltung und Office App

Lokal gibt es heute Dateiserver für die Datenablage und die Office Suite (Word, Excel, PowerPoint etc. zur Bearbeitung von Dokumenten. Zusätzlich sind OneDrive/OneDrive Business die Cloud-Lösungen, um lokale Daten auch in einer Cloud abzulegen und mit Office Online Apps (Word Online etc.) zu bearbeiten. Auch andere Sync/Cloud-Dienste wie Google Drive, DropBox, OwnCloud, NextCloud etc. die aktuell aber nicht genutzt werden

Der Einsatz der G Suite beruht auf dem Ansatz, dass alle Daten in der Cloud liegen und damit durch die G Suite Apps in einem Browser bearbeitet werden können. Dies stellt Herausforderungen an die Bandbreite, die Browser und das „Online-Verwalten“. Zudem ist eine Migration der Daten in die Cloud erforderlich. Natürlich können die Dateien auch weiterhin lokal über den Sync-Mechanismus vorgehalten und mit den Microsoft Office Produkten bearbeitet werden. Es gibt allerdings Einschränkungen von Google Docs, Google Tabellen oder Google Präsentationen beim Umgang mit DOCX, XLSX, PPTX-Dateien und umgekehrt. Speziell in Excel genutzte Verknüpfungen zu Datenquellen und Makros sind nicht verfügbar, was insbesondere bei integrierten Lösungen (SAP, ERP) verhindert, dass „Google Tabellen“ die Microsoft Produkte heute ersetzen .Mit entsprechender Voreinstellung können ausgewählte Dokument auch „offline“ bearbeitet werden.

Die Ablage der Dokumente in Google Drive ist Voraussetzung zur Bearbeitung mit den Google Apps. Jede lokale Datei wird immer in das Google Drive hochgeladen und dort geöffnet. Ob die Funktionen der Google Apps für den Geschäftsbetrieb ausreichen, ist in einer Evaluierungsphase zu prüfen um das Einsparungspotential durch den Verzicht auf „Microsoft Office“ korrekt abzuschätzen.

Instant Messaging

Mit Skype for Business ist eine Präsenzanzeige, Instant Messaging und eine leistungsfähige Konferenzplattform vorhanden.

Die G Suite enthält mit „Hangouts“ eine Software für 1:1 Chats, Gruppenunterhaltungen (bis 100 Teilnehmer) und natürlich Konferenzen (bis zu 10 Teilnehmer). Hangouts erfordert Chrome als Browser und ist keine „installierbare Software“, die sich z.B. im Tray-Icon im Hintergrund einnistet.

Hangout kann nur innerhalb von Google genutzt werden, d.h. alle anderen Teilnehmer nutzen auch Hangout. Eine Federation mit andere Diensten (Skype, ICQ, WhatsApp etc.) ist nicht möglich. Google hat vor einiger Zeit die XMPP-API abgeschaltet.

Bandbreite

Die meisten Clients sind im LAN und sprechen mit dem internen Server. Internet wird nur für mobile Clients und SMTP genutzt

Durch den Umzug zur G Suite verlagern sich die Verkehrsflüsse in die Cloud. Mobile User nutzen direkt die G Suite und entlasten die Internetleitung. Allerdings kommunizieren nun alle internen Anwender über das Internet mit Google und selbst rein interne Mails gehen mindestens zweimal über die Leitung. Wenn ein Anwender mehrere Clients nutzt und synchronisiert, erhöht sich das Datenvolumen weiterhin. Auch die Bearbeitung und Speicherung von Dokumenten erfolgt nicht mehr lokal sondern im Browser auf den Server der G Suite.

Dateiserver

Heute haben User Dateien in ihrem Heimatverzeichnis und gemeinsame Laufwerke

Die G Suite kennt nur Google Drive für eigene Daten. Gemeinsame Laufwerke gibt es in der Art nicht, aber können mit Gruppen Usern bereit gestellt werden, die dann an die Mitarbeiter frei gegeben werden. Dies ist nicht mit „Google Groups“ zu verwechseln, welche mit Diskussionsboards/Newsgroups zu vergleichen sind. Unklar für Gruppenablagen ist mir hier der Provisioning-Prozess (Anlage und Berechtigung) und die Lizenzierung. Die Bearbeitung von Dokumenten erfolgt in der G Suite immer über einen Browser gegen die G Suite Server, auf denen die Daten zwingend liegen. Wenn noch lokal vorgehaltene Daten bearbeitet werden müssen, sind diese zuerst in die G Suite hochzuladen.

Dies ist ein erster Versuch die Funktionen von lokalen Dateiservern, Microsoft Office und Exchange Diensten hinsichtlich der G Suite zu beschreiben. Es ist aber nicht als Vergleich zu verstehen, da die Plattformen komplett unterschiedlich sind. Selbst ein Vergleich mit Office 365 ist aus meiner Sicht nicht einfach Möglich. Office 365 besteht aus deutlich mehr komponenten und spätestens ab Office 365 E3 gibt es auch richtige "On-Premises" Programme. Wer darauf aber verzichten kann, kann natürlich auch im Browser Dokumente bearbeiten, sofern diese im Googledrive liegen.

Test-Umsetzung

Viele Funktionen, die bislang „on-premises“ bereit gestellt wurden, können zukünftig über Cloud-Dienste bezogen werden. Dies eröffnet neue Wege der Nutzung, die besser an veränderter Umgebungen angepasst scheinen. Allerdings ist so ein Wechsel auch aufwändig und muss gut überprüft sein. Viele lokal liebgewonnenen Funktionen sind in den Cloud-Angeboten noch nicht enthalten oder können Systembedingt nur anders oder gar nicht abgebildet werden. Daher ist eine zweistufige Test- und Evaluierungs-Phase dringend angeraten, nachdem die Fragen zu Datenschutz/Betriebsrat etc. positiv beantwortet wurden.

  1. Testphase
    Dieser Zeitraum wird genutzt, um die technischen Aspekte zu beleuchten und KO-Punkte zu erkennen. Sie findet ohne aktive Beteiligung der eigentlichen Anwender statt und dient primär der Bereitstellung der Plattform und Vermittlung von Kenntnissen für Administratoren und Helpdesk, die die Plattform später mit betreiben. Zudem sind hier noch alle Funktionen freigeschaltet, so dass Fachverantwortliche mir Testkonten die Eignung verifizieren können. Diese Phase beleuchtet auch die Veränderungen hinsichtlich des Netzwerks, z.B. Proxy-Server, Bandbreiten, Security etc. und Anforderungen an Clients in den verschiedenen Umgebungen (OS-Versionen, Standorte, Geräte)
    Das Ergebnis dieser Phase ist entweder ein GO für eine Evaluierung oder ein NoGo in diese Richtung.
  2. Evaluierung
    In dieser Phase wird die bestehende Umgebung für „Early Adopters“ frei geschaltet, die mit enger Unterstützung durch den Helpdesk und Betrieb die neue Plattform testen. Noch ist keine Entscheidung für die Umsetzung gefallen aber erst die Eignungsprüfung durch ausgewählte Personas liefert die Daten, anhand der später eine qualifizierte Kosten/Nutzen-Bewertung erfolgen kann. Je wahrscheinlicher eine produktive Einführung wird, desto mehr Aufwand kann hier auf die Migrations- und Koexistenz-Planung, Schulungskonzepte etc. verwendet werden
  3. Einführung oder Ende
    Mit dem Wissen um die Funktion, Kosten und Eignung der Lösung fällt die finale Entscheidung.

Der Inhalt der ersten Testphase könnte folgende Bausteine enthalten:

  • Testversion G Suite beantragen
    • Beantragung und Lizenzierungsprozess prüfen
    • Funktionsumfang mit „Cloud Only User” testen
      Mit einfachen nicht synchronisierten Konten kann schon ein Funktionstest erfolgen
    • Eigene „Domain“ eintragen
      Dies ist für Testmails und ADFS-Anmeldungen erforderlich
  • Verzeichnisabgleich
    Die Verwaltung der Benutzer soll anhand des lokalen AD erfolgen
    • GDCS einrichten
    • Synchronisationsfunktion „verstehen“, z.B. Filterung auf Objekte und auf Properties
    • Einrichten eines Sync für Testuser
    • Wie werden Benutzer, Verteiler, Kontakte, Verschachtelte Verteiler angelegt, aktualisiert, gelöscht
    • Wie werden Mailadressen und andere AD-Felder behandelt
    • Monitoring des DirSync
  • Authentifizierung
    Eine Anmeldung mit unabhängigen Kennworten ist nicht ratsam und ein Kennwort-Sync nicht nutzbar (SHA-1/MD-5 zu schwach)
    • Bereitstellung ADFS für G Suite
    • Integration G Suite mit ADFS
    • Test verschiedener SingleSignON-Szenarien mit den Testusers
      Intern, Domain Joined, Standalone-PC, abgelaufenes Kennwort, gesperrtes Konto, Windows/IOS/Android etc.
  • Nutzung und Datenmigration Exchange
    • Einrichtung Outlook mit G Sync Suite
    • Migration der Daten als Admin bzw. User
    • Usability Tests
  • Google Docs
    • Datenablage und Nutzung mit Google Docs
  • Verwaltung
    • Kontrolle der Delegierung von Adminrechten
    • Usability der Admin-Konsole
    • Nutzung der APIs für Reporting und Automatisierung.

Veränderungen

Mit dem Wechsel zu einer Cloud-Lösung wird neben neuen Funktionen auch das Ziel verfolgt, die Kosten zu reduzieren. Mit dem Umzug Richtung G Suite sind einige Änderungen möglich. Die großen Änderungen sind:

  • E-Mail, Kalender und Kontakte gehen zu GMail
  • Dateien und Dateibearbeitung geht zu Google Drive

Damit können einige bislang lokal erforderlichen Dienste komplett entfallen oder deutlich kleiner dimensioniert werden. Der Rückbau und die Anpassungen sind aber zumindest einmalig mit erhöhten Kosten verbunden.

  • Wegfall Spamfilter
    Eingehende Mails können direkt bei den Mailservern von Google abgeliefert werden und werden dort auf Spam/Viren geprüft. Wie bei Office 365 vereinfacht sich das Setup aber bedeutet zugleich auch weniger Eingriffsmöglichkeiten.
  • Blackberry/MDM
    Das Management der Clients wird zu G Suite verlagert und ist den dort vorhandenen Möglichkeiten unterworfen. Eigene MDM-Lösungen sind zwar weiterhin möglich aber sind mit Zusatzkosten verbunden.
  • Kein Reverse Proxy
    Der Zugriff von remote Usern erfolgt direkt gegen Google. Damit entfallen alle Veröffentlichen bezüglich Exchange (WebMail, ActiveSync etc.)
  • kein Exchange Server
    Ohne lokale Postfächer ist auch keine große Exchange Umgebung mehr erforderlich. Dies führt weiterhin zu Einsparungen beim Backup (keine Exchange Agenten) und Monitoring. Allerdings wird auch zukünftig zumindest ein Basis-System für das Routing von Mails zwischen internen Systemen und den Google Systemen erforderlich sein. Ansonsten müssten alle ERP/CRM-Systeme selbst Verbindungen zu Google aufnehmen
  • Regeln, Disclaimer etc.
    Alle bisher in Exchange konfigurierten Regeln u.ä. sind im Rahmen der Möglichkeiten nun in der G Suite zu pflegen.
  • Google Drive
    Je intensiver die Dateiablage „Google Drive“ genutzt wird, desto weniger wird der Dateiserver benötigt und kann zumindest verkleinert werden. Neue Systeme für „Sharing mit externen Firmen“ müssen gar nicht erst aufgebaut werden, da diese Funktion in Google Drive schon enthalten ist.

Einschätzung

Die G Suite ist genial für Startups, die mit einem Browser umgehen können und ziemlich unabhängige Benutzer haben. Durch die Integration eines Verzeichnisabgleich und Authentifizierung ist es sogar möglich die Verwaltung mit Hilfe eines lokal vorhandenen Active Directory zu koppeln. Das System „Google“ basiert intensiv auf webbasierten Diensten, die mit dem Chrome-Browser arbeiten und ohne umfangreiche lokale Server auskommen. Dieser „100% Cloud-Ansatz“ hat aber genauso seine Schwachstellen wie ein 100% on-premises Einsatz. Auch mit Office 365 kann ich  genauso arbeiten wie mit der G Suite. Dokumente in OneDrive lassen sich im Browser mittels WordApp und Co. bearbeiten und selbst OWA kennt einen „Offline mode“, wenn Outlook nicht gewünscht wird. Die G Suite Basic (4€) ist auf 30 GB pro Benutzer limitiert und enthält keine Teamanlagen. Erst ab G Suite Business (8€) ist der Platz groß und sind Teamablagen möglich. Diese Version entspricht am ehesten Office 365 E1. Die Kosten von 23€ (G Suite Enterprise) erscheinen mir etwas hoch, wenn ich diesen eine Office 365 E3-Lizenz (20€) zzgl. Audiokonferenzeinwahl gegenüberstelle, die sogar noch Office als lokale Anwendungen enthält.

Weitere Links