Microsoft 365 Move-Programm

Microsoft 365 Move-Programm: Microsoft bietet seit Dezember 2019 die Microsoft 365 Produkte aus seinen Schweizer Rechenzentren an. Das war damals eine grosse Sache und ist immer noch ein wichtiges Verkaufsargument für ihre Cloud-Plattform, insbesondere für Unternehmen, die strenge Anforderungen an die Datenaufbewahrung haben.

Wenn Sie Microsoft 365 nach dem 19. Dezember 2019 mit einer schweizerischen Rechnungsadresse erworben haben, liegen Ihre Office 365 Daten bereits auf den schweizerischen Rechenzentren und Sie nutzen von dort aus Services, wie z.B. Exchange Online, SharePoint Online, OneDrive for Business oder Teams. Haben Sie Ihren Tenant vor dem 19. Dezember 2019 eröffnet, liegen Ihre Daten wahrscheinlich noch in den europäischen Rechenzentren und Sie können eine Verschiebung der Daten in die Schweiz beantragen.

Wenn Sie umziehen möchten, müssen Sie sich aber beeilen – die Option ist nur noch bis zum 30. Juni 2020 verfügbar.

Die Verschiebung können Sie als Kunde oder wir als CSP-Partner im M365 Admin Center beantragen. Weitere Informationen zum Microsoft 365 Move-Programm finden Sie hier.

Data Residency Office 365

Nur Kunden, die sich für das Umzugsprogramm eingeschrieben haben, werden im Laufe der Zeit migriert. Eine automatische Migration in die Schweiz wird es nicht geben. Die Migration hat für Sie keine Auswirkungen und spielt sich vollumfänglich im Hintergrund ab. Lizenzpreise und Vertragsbedingungen bleiben auch gleich wie bisher.

Gerne sind wir Ihnen bei der Beantragung behilflich.

TIP-OF-THE-WEEK #5 SharePoint Online

TIP-OF-THE-WEEK #5 SharePoint Online: Wir hoffen, dass Sie trotz Neuschnee gut in den Frühling gestartet sindDiese Woche haben wir einen kleinen Tipp für SharePoint Administratoren
In diesem Beitrag werden wir Ihnen zeigen, wie Sie ein ziemlich mühseliges Problem in SharePoint Online-Sites umgehen können. 

Dabei geht es um den Umstand, dass normale Benutzer der SharePoint-Site, Webseiten einschliesslich der SharePoint Homepage bearbeiten/editieren können.  In SharePoint werden Webseiten wie alle anderen Inhalte (bspw. Dokumente) behandelt. Das bedeutet, wenn Benutzer über die Berechtigungsstufe «Bearbeiten» oder «Mitwirken» verfügen, (Benutzer in der Mitgliedergruppe), können sie nicht nur Dokumente aus einer Dokumentbibliothek hinzufügen, bearbeiten oder löschen, sondern auch die Seiten der Site verändern. 

In einigen Fällen ist dies unter Umständen erwünscht, beispielsweise wenn die Seiten der Site als Wiki verwendet werden, ist dies genau das, was die Benutzer tun sollen, nämlich Inhalte auf den Seiten bearbeiten.  

Wenn Sie aber beispielsweise ein Site-Inhaber einer Projekt-Site sind, möchten Sie nicht, dass Ihre Benutzer die Startseite, welche Sie mit viel Zeit und Schweiss aufgebaut haben, verändern. Es ist eine Sache, wenn Herr Muster ein Dokument aus einer Bibliothek löscht, ganz anders sieht es aus, wenn Herr Muster die Startseite des Hauptprojektes löscht und sie für alle Benutzer «kaputt» macht 

Jetzt, da klar ist, worüber wir sprechen und wieso es wichtig sein kann, wollen wir sehen, was es für Optionen gibt, um diesem Ärgernis aus dem Weg zu gehen. 

Option 1: Verhindern Sie das Bearbeiten aller Seiten 

Wenn Sie die Bearbeitung aller Seiten Ihrer Website verhindern möchten, ist das mühelos zu bewerkstelligen. Alle Seiten einer Site werden in der Site Pages-Bibliothek gespeichert. Diese verhält sich analog zu einer Dokumenten-Bibliothek einfach nur für Seiten. Standardmässig erbt sie die Sicherheitseinstellungen der Site. Wenn Sie also verhindern möchten, dass Teammitglieder die Seiten einer Website bearbeiten, müssen Sie die Vererbung aufheben und diese Bibliothek für die Mitglieder Gruppe schreibgeschützt machen. So gehen Sie am besten vor:

  1. Klicken Sie auf einer Site auf das Zahnradsymbol und dann Websiteinhalte. 
  2. Klicken Sie anschliessend auf die Websiteseiten Bibliothek. 
    TIP-OF-THE-WEEK #5 SharePoint Online
  3. Als Nächstes müssen Sie die Vererbung der Berechtigungen für diese Bibliothek aufheben. Klicken Sie dazu auf das Zahnradsymbol und dann Bibliothekseinstellungen. 
  4. Klicken Sie anschliessend auf «Berechtigungen für Dokumentbibliothek». 
  5. Wie Sie der angezeigten Nachricht entnehmen können, erben Seiten standardmässig die Berechtigungen des übergeordneten Objekts (Site). Deshalb können standardmässig alle regulären Teammitglieder alle SharePoint-Seiten bearbeiten.  
  6. Um die Vererbung aufzuheben, klicken Sie auf «Berechtigungsvererbung beenden». Wenn eine Warnmeldung angezeigt wird, klicken Sie auf OK. 
  7. Aktivieren Sie das Kontrollkästchen neben «Mitglieder von XXXX» und klicken Sie dann auf Benutzerberechtigungen bearbeiten. 
  8. Zum Schluss deaktivieren Sie das Kontrollkästchen neben «Bearbeiten» und markieren Sie es bei «Lesen» 
  9. Jetzt können die User keine Seiten mehr editieren oder löschen.  

OPTION 2: Blockieren Sie die Bearbeitung einer spezifischen Seite 

Option 1 ist simpel und rasch umgesetzt, aber möglicherweise nicht die richtige Lösung für Sie. Wenn Benutzer keine Seiten bearbeiten dürfen, können sie kein Wiki mehr erstellen und bearbeiten oder eine Neuigkeit veröffentlichen (in modernen Seiten ist jede Neuigkeit eine neue Seite). Die beste Lösung für ein solches Szenario wäre, ausschliesslich die Startseite für Bearbeitungen durch reguläre User zu sperren.  Dies können sie folgendermassen bewerkstelligen:  

  1. Navigieren Sie zur Site Pages-Bibliothek (Zahnradsymbol  Websiteinhalte – Websiteseiten). 
  2. Aktivieren Sie das Kontrollkästchen neben der Seite, deren Bearbeitung Sie einschränken möchten.  
  3. Klicken Sie dann auf das kleine umrundete «i» und dann auf Zugriff verwalten. 
    blank
  4. Klicken Sie auf die Dropdown-Liste neben «Mitglieder von XXXX» und ändern Sie dann «Bearbeiten» zu «Kann Anzeigen» 

Wir hoffen, wir haben Ihnen damit stundenlanges Nacharbeiten erspart. 😉 Im Fall der Fälle ist es aber in jedem Falle sinnvoll auch für Office 365, insbesondere SharePoint Online ein Backup zur Verfügung zu haben mit dem man gelöschte Daten einfach wiederherstellen kann. Wir bieten dafür eine entsprechende Lösung Skykick Datensicherung für Office 365 – gerne stehen wir Ihnen für Fragen zur Verfügung.  

Ihre TwinCap First AG 

Automatisierung von SharePoint mit Power Automate – Die Basics

blank

Automatisierung von SharePoint mit Power Automate – Die Basics: ​Mit Flow hat uns Microsoft ein mächtiges Werkzeug zur Verfügung gestellt. Es passt hervorragend zu unserem Motto «do more, work less». In diesem Beitrag möchte ich über die Erfahrungen beim Erstellen eines Flows schreiben.

Ausgangslage

Seit Kurzem verwenden wir intern eine SharePoint Communication Site (sehr empfehlenswert!), auf welchem unter anderem ein «News»-Webpart eingebaut ist. Die Geschäftsleitung möchte dort News publizieren, welche firmenweit von Interesse sind. Dies funktioniert soweit auch prima, nur gibt es keine Möglichkeit, diese News auch in Microsoft Teams anzeigen zu lassen.

Das Problem

Somit muss sich die Geschäftsleitung darauf verlassen, dass die Mitarbeiter regelmässig auf die SharePoint Site schauen und nach News Ausschau halten, was erfahrungsgemäss ziemlich sicher nicht geschehen wird. 😉

SharePoint Portal

Bühne frei für Power Automate!

Mit Flow sollte es möglich sein, nach der Erstellung eines Elements automatisch eine Nachricht an das Team in Microsoft Teams zu senden. Die Connectoren dafür sind vorhanden, es müssen somit nur die Reihenfolge und die richtigen Felder definiert werden.

Dies ist, wie sich herausgestellt hat, gar nicht so einfach zu bewerkstelligen. Der Ablauf sollte so aussehen:

Der Ablauf

  1. Wenn ein neuer News-Beitrag gepostet wird, dann …
  2. … sende eine Nachricht an das Team in Microsoft Teams

Zum News-Beitrag: Auf den ersten Blick unterscheidet SharePoint nicht zwischen einer normalen Page und einem News-Beitrag. Für unseren Flow bedeutet das, dass wir eine Möglichkeit suchen müssen, um zwischen einer Page und einem News-Beitrag zu unterscheiden. Denn wir möchten das Team nur dann informieren, wenn es Neuigkeiten gibt. Eine Webrecherche hat ergeben, dass sich «News» durch das Vorhandensein von zwei Feldern von Pages unterscheiden:

  • «Promoted State»
  • «First Published Date»

Mit «Promoted State» kann gesagt werden, ob es sich bei einer Page um eine «News» handelt oder nicht. Mit «First Published Date» hingegen kann eingesehen werden, wann die «News» publiziert wurde. Wir werden beide Felder verwenden müssen, um einen guten Workflow mit Flow erstellen zu können.

Flow erstellen

Jetzt wo die technischen Details geklärt sind, machen wir uns ans Eingemachte:
Um die Erstellung eines Flow so einfach wie möglich zu machen, gehen wir auf die SharePoint-Site, auf «Site Contents» und anschliessend auf «Site Pages». Von dort aus kann dann ein Flow erstellt werden:

SharePoint

Im rechts erschienenen Fenster wählen wir den Flow «Post a message to Teams for a selected item». Nun gelangen wir zur Flow-Bearbeitungsseite:

blank

Mit einem Klick auf «Edit» in der ersten Aktion erhalten wir die ID der «Liste». Diese werden wir benötigen, um auf die entsprechende Ressource zugreifen zu können. Dementsprechend kopieren wir uns diese weg. Weil diese Vorlage nicht ganz dem entspricht, was wir erreichen möchten, schliessen wir diesen Flow wieder und erstellen einen neuen mit dem Knopf «Create from blank»:

blankHier wählen wir den Trigger «SharePoint: When an item is created» und werden auf die Flow-Erstellungsseite weitergeleitet:

blank

Im Feld «Site Address» wählen wir im Dropdown-Menü die entsprechende Site aus und fügen den «List Name» von vorhin ein (mit dem «Umweg» über ein Template spart man sich das Heraussuchen der ID 😉 ). Der Flow wird also ausgelöst, wenn ein neues Element auf unserer SharePoint-Site erstellt wird.

Damit unser Flow nicht bei jedem beliebigen Element ausgeführt wird, muss dieser unterscheiden können, ob es sich bei der erstellten Site um eine News Site handelt oder nicht. Dazu erstellen wir eine «Condition»:

blank

Diese überprüft, ob der Wert im Feld «Promoted State» (ein Float) ein Wert grösser als 0 steht. Wenn ja, dann handelt es sich um einen News-Beitrag. Wenn nicht, dann um eine «normale» Page.
Hinweis: Ich habe es mit einer Condition versucht, die überprüft ob das Feld Promoted State leer ist oder nicht. Das hat aber nicht geklappt, weil der Datentyp nicht kompatibel ist. Auch das Umwandeln in einen String klappt nicht, weswegen ich bei der oben beschriebenen Lösung verblieben bin.

Innerhalb des «If no»-Bedingung muss nichts stehen, weil bei der Erstellung einer normalen Page in unserem Fall nichts unternommen werden soll.

In der «If yes»-Bedingung hingegen geht es mit einer «Do until»-Schleife weiter:

blank

Kleiner Exkurs: eine «Do until»-Schleife führt die innerhalb der Schleife angegebenen Aktionen solange aus, bis eine bestimmte Bedingung erfüllt wurde oder die Schleife eine bestimmte Anzahl male durchgeführt wurde.

Bevor es technisch weitergeht, eine kurze Erklärung, wieso diese Schleife überhaupt notwendig ist: Der Trigger «When an item is created» wird ausgeführt, sobald SharePoint das Objekt erstellt hat. Flow wartet somit nicht bis der News-Beitrag «publiziert» wurde oder überhaupt eine Überschrift hat. Dies ist natürlich problematisch, weil bei der Erstellung einer News doch einige Zeit vergehen kann. Aus diesem Grund muss überprüft werden, ob die News überhaupt publiziert wurde, bevor die Nachricht an das Team gesendet wird.

Bevor wir nun aber mit der Erstellung der Bedingung beginnen, erstellen wir die Aktionen, welche während der Schleife ausgeführt werden sollen. Wir machen dabei folgendes:

  • SharePoint Get item
  • Delay

Mit SharePoint Get item lesen wir das von SharePoint erstellte Objekt erneut ein. Dies müssen wir deshalb tun, damit Flow die Änderungen des Felds «FirstPublishedDate» überhaupt mitbekommt. Mit Delay hingegen definieren wir eine einfache Wartezeit, bevor die Bedingung der Schleife erneut überprüft wird.

Bei der Aktion «Get item» definieren wir auch wieder die Site und die Liste (wie beim Trigger) und geben zusätzlich die ID mit, welche vom Trigger durchgegeben wird:

blank

Die Delay-Funktion ist selbsterklärend:

blank

Um die Anzahl von Versuchen zu definieren, welche die Schleife durchführen wird, müssen wie den Inhalt der Felder unter «Change limits» anpassen:

blank

In diesem Fall wird die Überprüfung 60-mal durchgeführt, bevor die Schleife verlassen wird.

Nun zu der Bedingung: Power Automate bietet einige Funktionen, die (noch) nicht über das GUI verwendet werden können. Die Funktion «empty» ist eine solche. Mit dieser kann überprüft werden, ob ein Feld leer ist oder nicht. Somit müssen wir in den «Advanced mode» wechseln und das Feld wie folgt ausfüllen:

blank

Wichtig ist hierbei, dass das Feld «FirstPublishedDate» von der Aktion «Get_item» und nicht von der ersten Aktion «When an item is created» verwendet wird! Bei der Erstellung des Objekts hat unser News-Beitrag noch kein «FirstPublishedDate», weil dieser noch nicht publiziert wurde. Sobald sich das ändert und die Aktion «Get item» ausgeführt wird, wird die Bedingung oben erfüllt.

Die «Do until»-Schleife überprüft in unserem Fall für 60 x 5 Minuten, ob die News publiziert wurde. Wenn diese Zeit verstreicht, ohne dass die News publiziert wurde, dann bleibt das Feld «FirstPublishedDate» leer und wir können mit einer weiteren Condition entscheiden, was mit der Site passiert.

Nun da wir die «Do until»-Schleife fertig haben, können wir mit einer weiteren Condition (diese muss zwingend ausserhalb der «Do until»-Schleife sein!) fortfahren:

blank

Auch hier wechseln wir wieder in den «advanced mode» um die «empty»-Funktion verwenden zu können. Wir überprüfen somit, ob das Feld «First Published Date» leer ist. Wenn ja, dann möchten wir den unveröffentlichten News-Beitrag löschen (fünf Stunden sollten genügen, um einen News-Beitrag fertigzustellen ;-)). Wenn nein, dann soll das Team informiert werden.

In der «If yes»-Bedingung erstellen wir die Löschen-Aktion. Die Felder können wir mit denselben Eingaben wie weiter oben ausfüllen:

blank

Die letzte Aktion bestehe darin, nach Erstellung und Publizierung der Site eine Nachricht an das Team in Microsoft Teams zu senden. Dazu erstellen wir eine «Teams Post message» Aktion in der «If no»-Bedingung. Im Dropdown-Menü können wir das Team und den Kanal auswählen. Im Feld «Message» können wir nun die Felder angeben, welche wir möchten. In unserem Fall wird der Titel der News und ein Link zur zugehörigen SharePoint-Page gepostet:

blank

Das wars, der Flow ist soweit fertig erstellt und kann nun mit dem Knopf «Create flow» oben rechts erstellt werden.

Test durchführen

Bevor wir allen von unserem tollen Flow berichten, müssen wir das Ganze noch testen. Dazu gehen wir wie folgt vor:

  • News erstellen und publizieren
  • Nachricht in Teams kontrollieren
  • Weitere News erstellen aber nicht publizieren
  • Nach Ablauf der Zeit (evtl. Wartezeit in der Schleife verkürzen, damit ihr nicht fünf Stunden warten müsst) kontrollieren, ob die unveröffentlichte Page gelöscht wurde
  • Neue Page (keine News!) erstellen und kontrollieren ob Flow korrekt entscheidet und diese ignoriert

Einige Beobachtungen

Die Hilferessourcen von Microsoft sind, wenn überhaupt, nur sehr spärlich vorhanden, was bedeutet, dass viele Dinge durch ausprobieren herausgefunden werden müssen. Bedingungen stellen erfahrungsgemäss die grösste Fehlerquelle dar, weswegen es sich anbietet, diese gründlich zu testen. In diesem Fall habe ich nach jeder Bedingung eine angepasste Nachricht in Microsoft Teams posten lassen. Wenn also die Nachricht «Die Seite wurde nicht veröffentlicht» gepostet wird obwohl die Veröffentlichung bereits stattgefunden hat, dann weiss ich, dass ich die Bedingung nochmals überprüfen muss.

Danke fürs Lesen/Teilen/Kommentieren! 🙂

SharePoint Online Backup & Restore

SharePoint Online Backup & Alternativen

SharePoint Online Backup & Restore

SharePoint Online Backup & Restore ist unter Office 365 ist aus unserer Sicht eines der Themen, welches noch nicht die notwendige Aufmerksamkeit geniesst. Selbstverständlich kennt der geübte SharePoint-Administrator die eingebauten Schutzmechanismen. Manchen Unternehmen genügt dieser Office 365-Selbstschutz. In einer On-Premises-Welt gehören zudem 3rd-Party Backup-Tools. Dies ermöglichen es einem, auch granular Daten, über einen Zeitraum von mehr als 30 oder 90 Tage in der Vergangenheit hinaus, wiederherzustellen. Dort gehört dies zu Standard-Ausrüstung.

Dieser Blog befasst sich mit den Fakten und Möglichkeiten rund um SharePoint Online. Da sich die Dienste von Office 365 in stetiger Weiterentwicklung befinden, mögen nicht alle in diesem Blog getätigten Aussagen immer und ewig Beständigkeit haben. Grundsätzlich ist festzuhalten, was für SharePoint Online in Sachen Built-In-Werkzeugen gilt, gilt auch für OneDrive for Business. Auch den Office 365 Groups, welche ebenfalls den Speicher von SharePoint Online nutzen, stehen für die SharePoint-Inhalte dieselben Wiederherstellungs-Mechanismen zur Verfügung. Office 365 Groups selbst bleiben nach Ihrer Löschung für 30 Tage in einen «soft-deleted» Status. In diesem Zeitraum können Office 365 Groups inkl. deren gesamter Inhalt auch mit dem built-in-tools wiederhergestellt werden. Während unter Exchange Online kein herkömmliches Backup «out of the box» durchgeführt werden kann, passiert unter SharePoint Online in Sachen Backup zumindest im Hintergrund das eine oder andere.

Was Microsoft im Hintergrund macht

  • Microsoft macht alle 12 Stunden einen Backup aller Site Collections
  • So kann Microsoft bis auf 14 Tage zurück, Daten wiederherstellen
  • Zudem kann Microsoft jeweils «nur» die ganze Site Collection unter der ursprüngliche URL wiederherstellen (bestehende Daten werden also überschrieben)
  • Ein solcher Restore kann nur über einen Service Request, welcher über das Office 365-Portal eröffnet werden muss, realisiert werden
  • Bis ein solcher Restore von Microsoft durchgeführt wurde, können gut und gerne 2 – 4 Tag vergehen

Restore von Site Collections

Das Wiederherstellen von Site-Collections kann vom Site Collection Administrator auch selbst durchgeführt werden. Sofern sich eine Site Collection dann noch im Site Collection-Papierkorb befindet. Nach 30 Tagen werden Site Collections aus dem erwähnten Papierkorb endgültig gelöscht. Löschungen von SharePoint-Inhalt aus Sites, Listen, Libraries oder Folders werden zuerst in den «Papierkorb» (First Stage Recycle Bin) verschoben. Eigene Daten kann ein Benutzer bis auf 93 Tage zurück selber wiederherstellen oder auch vom Papierkorb löschen. Zu bemerken ist, dass die Daten im Papierkorb zu den Storage Quotas angerechnet werden.

Daten, welche vom Papierkorb gelöscht werden, landen im «endgültigen Papierkorb» (Second Stage Recycle Bin). Dort werden die Daten nach maximal 93 Tagen nach ihrer effektive (ersten) Löschung entfernt. Ab diesem Zeitpunkt sind die Daten unwiderruflich gelöscht. Die Daten im «endgültigen Papierkorb» werden nicht der Storage Quota angerechnet. Wiederherstellungen aus dem endgültigen Papierkorb können vom Site Collection Administrator durchgeführt werden.

Second Stage Recycle Bind
Spätestens beim Löschen aus dem Second Stage Recycle Bin wird auf die
maximale Retention-Time von 93 Tagen aufmerksam gemacht

Eine weitere erwähnenswerte Wiederherstellungs-Methoden unter SharePoint Online ist das «Versioning», welches automatisch aktiv ist und es einem erlaubt per default bis auf 500 Versionen eines Dokumentes zurück zu greifen. Natürlich kann von SharePoint Online jederzeit via Windows Explorer ein Offline-Backup erstellt werden. Diese Methode ist jedoch schwerfällig, zudem verliert man die Meta-Daten auf Dateien, die durch ein Offline Backup gesichert wurden.

Aufgrund der bis hierhin beschriebenen Möglichkeiten kann mal leicht die wichtigsten Nachteile der Backup/Restore-Möglichkeiten identifizieren:

  • Die Generationen wiederherstellbarer Daten sind begrenzt (zwischen 14 und 93 Tagen)
  • Daten die man wiederherstellen muss, können nicht granular zurück gesichert werden, viel mehr werden bestehende Site Collections unter möglicherweise aktiv genutzten URL’s überschrieben

SkyKick Cloud Backup for Office 365

Unter SharePoint On-Premises schliessen an dieser Stelle 3rd Party Backup-Tools die Lücken. Jedoch sind dieselben Tools aktuell nicht oder noch nicht für SharePoint Online zu gebrauchen. Anstatt nun Link-Sammlung von potentiellen Anbietern aufzulisten, stellen wir einen Anbieter vor. Wir arbeiten für Office 365-Backup und Restores mit Skykick. Respektive haben mit dessen Lösung schon diverse Kunden bedient. Die Werkzeuge der Cloud-Lösung von SkyKick bestechen durch eine äusserst einfache Bedienung und höchst interessanten Funktionalitäten (dies trifft für SharePoint Online, OneDrive for Business aber auch Exchange Online und zu):

  • Die Sicherungen können bis 6 x täglich erfolgen
  • Die Sicherungen können bis zu definierten Zeitspannen oder unlimitiert aufbewahrt werden
  • Der Backup der Daten erfolgt auf sicheren Azure Storage
  • Gelöschte oder neu erstellte Daten wie Site Collections oder Mailboxen werden automatisch erkennt und nicht mehr, bzw. eben neu gesichert

Skykick Dashboard
SkyKick Restore-Oberfläche für SharePoint Online

Fairerweise ist hierbei zu bemerken, dass auch Skykick noch nicht in der Lage ist  Office 365 Groups zu sichern oder wiederherzustellen, jedoch wird auch diese Funktion demnächst integriert werden.

Fazit

Wer SharePoint Online nutzt, dem stehen, ohne das hinzufügen von 3rd  Party-Tools, limitierte Backup/Restore-Möglichkeiten zur Verfügung. Wer diese Limitationen überwinden möchte, entsprechende Anforderungen im Bereich Aufbewahrungspflicht hat oder schlicht eine einfache Methode zur granularen Wiederherstellung von Daten aus SharePoint Online und OneDrive for Business will, sollte  sich mit Office 365 kompatiblen Zusatzlösungen wie z.B. derjenigen von SkyKick befassen.

Liebe Blogleser/innen, Sie haben den obigen Blogartikel gelesen, herzlichen Dank hierfür. Wie Sie wissen entwickeln sich Cloud und SaaS Lösungen rasant weiter. Zum Zeitpunkt des Artikels war der Inhalt bestimmt aktuell, es kann aber sein, dass die Infos bereits überholt sind. Da wir geschriebene Blogs nur selten anpassen, haben wir Ihnen anbei den Link zu unserer Skykick Seite mit allen aktuellen Informationen zu der Skykick Backup Lösung bereitgestellt.