Vorspiel

Ich habe in letzter Zeit auf Arbeit mit einigen Rechnern gekämpft, die die AD-Gruppenrichtlinien nicht mehr ausführen wollten, genau genommen gar keine AD-Verbindung mehr hatten. Die Anzahl der Geräte, die sich bei meinem Deployment-Manager gemeldet haben, sank immer weiter.
Mit den PCs schien ansonsten alles in Ordnung: Domänenmitgliedschaft, Internet, Intranet, Serververbindung mit Netzlaufwerken, alles da.
Wie kommt’s?

weiterlesen

Intro

Das Deployment von Adobe Reader DC im Windows Netzwerk via GPO Batch-Startscript ähnelt der Verteilung des alten Adobe Readers sehr – dennoch fasse ich die wichtigsten Steps hier zusammen.

Vorbereitung

Ihr braucht für die Verteilung immer die DC-Basisversion (als .msi) und das aktuellste, gewünschte Update (als .msp).
Außerdem, um die Reader Installation vor dem Deployment anzupassen, den installierten Reader DC Customization Wizard.

Step-by-Step

  1. Lokale AIP-Installation (z.B. C:\adc1516\) der Basisversion mit:

    Das Bild zeigt den Reader DC Installationsdialog, der durch die AIP gestartet wurde
  2. Aktuellsten Patch in die lokale AIP-Installation Slipstreamen (lokalen .msi Pfad beachten):

    Das Bild zeigt den CMD Befehl um das aktuelle Reader DC Update in die lokale AIP Installation zu slipstreamen
  3. Im lokalen AIP Ordner C:\adc1516 eine leere setup.ini Datei erzeugen und die AcroRdrDC1500720033_de_DE.msi in AcroRead.msi umbenennen (Letzteres ist nur eine kosmetische Anpassung).
  4. Mit dem Adobe Reader DC Customization Wizard die C:\adc1516\AcroRead.msi öffnen und beliebig anpassen. Änderungen wie vorgegeben als AcroRead.mst speichern.
    Das Bild zeigt den Adobe Reader DC Customization Wizard
  5. (Es müssten jetzt 3 Dateien und 4 Ordner in C:\adc1516\ existieren.) Den lokalen AIP-Ordner auf euer Deployment-Laufwerk verschieben.
    Das Bild zeigt die fertige Reader DC Deployment Installation im Deployment Share
  6. Deployen mit der .msi und .mst:

infos, infos, infos, via

Skript und Deploy

Das Deployment habe ich seit Reader 11 etwas verändert. Statt „complete-Ordner“ setze ich nun auf eine Versionsüberprüfung der Programm-exe. Das ist dynamischer und lässt sich differenzierter behandeln. Im Falle von Reader DC ist die Versionierung jedoch etwas seltsam. Beispielsweise lautet das aktuellste Update „AcroRdrDCUpd1501720053.msp“, nach der Installation wird die Dateiversion der .exe jedoch mit 15.17.20050 angegeben. Möglicherweise haben hier die Entwickler geschlampt.

Jedenfalls ist für die Verteilung mit Versionsüberprüfung noch ein Zwischenschritt notwendig:
Schaut im gerade erstellten lokalen AIP-Ordner, bzw. den schon aufs Deployment-Laufwerk kopierten Ordner die Eigenschaften Datei AcroRd32.exe an (liegt unter .\program files\Adobe\Acrobat Reader DC\Reader\) – im Tab Details steht die Versionsnummer, die ihr ins Skript und somit auch als Ordnernamen im Deployment-Laufwerk angeben müsst:
Das Bild zeigt die Dateieigenschaften von AcroRd32.exe und die Verweise auf das Skript und das Deploymentlaufwerk
Außerdem wird die VersionCompare.exe benötigt.

Hier nun das Script:
Code anzeigenDen Code könnt ihr bequem mit den Links/Rechts Pfeiltasten horizontal bewegen.

Alternatives Deployment

Auf der Seite 404techsupport.com habe ich einen noch einfacheren Deployment-Guide gesehen. Dort wird nur anhand des aktuellsten Installers gearbeitet – leider hatte ich noch nicht die Zeit dieses Deployment zu testen. Das hole ich sicher noch nach und Update dann hier.
Einzige Einschränkung: Das Deployment funktioniert nur über .exe, ist also nicht für das normale GPO Softwaredeployment via .msi geeignet.
Hier die Zusammenfassung, die der Autor mir per Mail zukommen ließ:

I download the latest executable from Adobe’s FTP site for Adobe Reader DC and deploy that with a script.
ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/1501620039/

I created a transform using the Adobe Customization Wizard and the .msi version of the installer.
My script then installs the executable and uses the transform as a parameter.

(The script runs at startup assigned by Group Policy. It checks a network location for a „receipt“ for that computer to see if it has run before, and if not, executes the above command. I empty the „receipts“ folder after I download the new installer to the share so that the script executes on their next startup.)

If that works for your deployment options, it’s pretty straight-forward and avoids the annoying .msp patching (security patch or quarterly patch?). If you need an .msi to deploy, you are probably stuck with your steps of creating the admin install.

Kurz notiert:
Dank PowerShell lassen sich bei Microsoft Exchange – in meinem Fall Exchange Online, also ein hosted Exchange – Änderungen gleich für mehrere oder sogar alle Nutzer ausführen. Vor allem bei Änderungen, die normalerweise nicht über die Adminoberfläche administrierbar sind, sondern über den Nutzer direkt eingestellt werden müssen, lohnt sich das enorm.

Verbindung zu Exchange Online in PowerShell herstellen

In PowerShell folgende Befehle nacheinander eingeben:

An dieser Stelle dann die Mail-Credentials eines Exchange Admins eingeben.

Speichert die Verbindung zu Exchange Online mit den Credentials in ein Objekt

Lädt das Session Objekt

Anschließend könnt ihr auf dem Exchange Befehle ausführen, beispielsweise Get-Mailbox:
microsoft-exchange-online-changes-to-multiple-or-all-users-get-mailbox

In den folgenden Beispielen soll die Abwesenheitsmeldung bzw. Automatische Antwort eingestellt werden. Diese Einstellung eines Nutzers lässt sich mit folgenden Befehl abrufen:

Änderungen für einzelne Benutzer

Aktivieren ohne zeitliche Einschränkung:

Aktivieren mit Start- und Endzeitpunkt:

(via)

microsoft-exchange-online-changes-to-multiple-or-all-users-set-mailboxautoreply

Änderungen für mehrere/alle Benutzer

Anhand des Pipe-Operators | können wieder Ausgaben eines Befehls an den nächsten Befehl zur Weiterverarbeitung übergeben werden.
Alle Benutzer:

Über Get-Mailbox werden alle Mailkonten geladen und an den Set-Befehl übergeben, der dadurch keinen Identity-Parameter mehr braucht.
Hinweis: Die Massenverarbeitung dauert natürlich entsprechend lange – für die 30 Nutzer bei uns hat der Befehl 4 Minuten gebraucht. Also nicht ungeduldig werden.

Mit Benutzervorauswahl:

Somit werden Nutzer erst durch den where-Befehl gefiltert, deren Postfächer geladen und weitergegeben. (via)

Typisches Problem – es funktioniert nicht

Wichtig:
Damit AutoReply-Regeln tatsächlich auch funktionieren, müssen in den Mailkonten auch wirklich E-Mails eingehen.
Bei Konten, die ihre E-Mails nur via SMTP weiterleiten und keine lokale Kopie der Mails in ihrem Postfach empfangen, funktioniert das Auto-Reply deswegen nicht.
Neben den AutoReply-Einstellungen muss demnach auch die Einstellung, dass beim Weiterleiten der Mails eine lokale Kopie behalten werden soll, gesetzt werden.
microsoft-exchange-online-changes-to-multiple-or-all-users-check-forwarding-settings

Einen Überblick über die Weiterleitungseinstellungen aller Nutzer bekommt ihr mit diesem Befehl:

Mit diesem schnellen Überblick könnt ihr euch entweder selbst die Nutzer raussuchen, die eine Weiterleitung eingerichtet haben jedoch keine lokalen Kopien in ihr Postfach kriegen (und somit auch keine Automatische Antwort abschicken).
Oder ihr nutzt einfach folgenden Befehl. Dieser aktiviert diese Einstellung der lokalen Kopie für alle Benutzer, die eine Weiterleitung (intern sowie extern) eingerichtet haben:

(via)

Fehler

Folgender Fehler kann bei WordPress auftreten, vermutlich nur bei bestimmten Hostern, nachdem es installiert oder hosterübergreifend umgezogen wurde:
Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden sowie den Fehler, dass diese nicht korrekt seien - egal, welche Daten man eingibt. Das liegt an fehlerhaften Besitzrechten nach der WordPress Installation auf einigen Hostern wie beispielsweise auch All-Inkl und Hosteurope.
Der Fehler erscheint vermutlich bei der Installation oder Aktualisierung von Plugins oder Themes.

Erklärung

Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden. Das Phänomen tritt auf, wenn ihr WordPress von Hand auf euren FTP hochgeladen und danach die Installation ausgeführt habt. Dadurch ist das WordPress Core mit den Besitzerrechten eures FTP Nutzers, mit dem ihr die WordPress Dateien hochgeladen habt, versehen. Alle Tätigkeiten aus dem WordPress System heraus, also beispielweise das Installieren von Plugins über die WordPress „Plugins“ Oberfläche, werden jedoch server-intern von einem anderen Nutzer ausgeführt. Dieser Nutzer heißt je nach System oftmals PHP-User, www-User, www-data oder ähnlich. Nun fehlen dem Nutzer aber die Zugriffsrechte auf die entsprechenden Ordner.

Lösungen

Es gibt mehrere mögliche Lösungen:

1)
Gebt bei der WordPress Nachfrage die FTP-Nutzerdaten ein, mit denen ihr WordPress hochgeladen habt. Den Nutzer könnt ihr, falls ihr es nicht mehr genau wisst, vielleicht mit dem WebFTP-Tool eures Hosters auslesen:
Das Bild zeigt die Oberfläche eines WebFTP Programms mit markierten Besitzerinformationen eines Ordners
Im besten Falle führt WordPress danach alle Plugin Aktionen ohne Klagen aus und ihr hört nie wieder von dem Problem. Aber dann wärt ihr wahrscheinlich auch gar nicht hier gelandet.

2)
Mein zweiter Tipp ist eigentlich der langfristig sicherste: installiert WordPress nicht von Hand sondern über die 1-Click-Install-Methode eures Hosters. Praktisch jeder Webhoster bietet die Installation von bekannter Software auf seinem System an, WordPress ebenfalls. Dabei richtet der Hoster ein fertig installiertes und eingerichtetes System für euch ein, meistens mit nur wenigen Klicks. Dieses System hat definitiv keine Rechteprobleme, ist nun aber frisch installiert. Je nachdem, wie jung oder alt euer Blog ist, kostet es nun weniger oder mehr Aufwand, die Inhalte in das neu installierte System zu transferieren. Aber diese Lösung ist am sichersten und wird keine zukünftigen Probleme mehr machen, ich empfehle das also.
Export/Import: Der Export besteht im Grundlegenden aus 2 Typen: Daten (Beiträge, Kommentare usw), Plugins und Themes.
Daten: Benutzt entweder die WordPress eigene Export-Funktion unter „Werkzeuge -> Daten exportieren“ oder exportiert eure komplette WordPress Datenbank (SQL Export via phpMyAdmin). Diesen Export dann im neuen WordPress bzw. dessen Datenbank.
Plugins/Themes: Entweder ihr installiert im neuen WordPress die Komponenten von Hand (je nachdem wieviele es sind), oder ihr zieht euch direkt vom FTP die Ordner „plugins“ und „themes“ und überschreibt einfach diese Ordner in eurem neuen WordPress System.
Anschließend müsste der neue WordPress Blog die Plugins, Themes (die beide ggf. noch aktiviert werden müssen) und Daten enthalten.
Ich werde aber demnächst nochmal einen ausführlichen Beitrag über gute WordPress Backup Methoden schreiben und eine komplette Backup Lösung konzipieren.

3)
Tragt in eure .htaccess Datei in der Root eures WordPress Blogs (also direkt im obersten Ordner, beispielsweise „/blog/“) folgende Zeile ein:

Hintergrund: Link

4)
Ändert die Besitzrechte der Ordner plugins, upgrade und themes in den PHP-User eures Hosts. Nutzt dafür vom Hoster zur Verfügung gestellte Möglichkeiten der Besitzrechteveränderung, vermutlich in eurem Admin-Backend. Überprüft, dass die Ordner die FTP-Rechte 755 und Dateien 644 haben. Anschließend fügt ihr eurer wp-config.php noch eine Zeile hinzu:

Diese Lösung ist vermutlich nur ein Pflaster für die Platzwunde – das hält nicht lang. Probiert lieber die vorherigen Lösungen, notfalls Lösung 2. Weitere Hinweise auf dieser, dieser oder dieser Seite.

Neu in meiner Software-Deployment Auflistung ist ab jetzt KeePass 2, eine ziemliche gute und erweiterbare Passwortmanagement-Freeware.
Zu KeePass selbst werde ich in Zukunft noch einige Artikel schreiben, von der Installation bis zur Integration in Browser und Smartphone. Jetzt erstmal schnell das Deployment im Windows Active Directory via Batch Script, im üblichen Stil.

Vorbereitung

Das Bild zeigt die vielen Deploymentparameter und -optionen des KeePass 2 InstallersDer .exe Installer von der Homepage (Pro Version) liefert beim Aufruf mit dem Parameter „/?“ eine lange Liste von Optionen zur Anpassung der Installation. Diese findet ihr hier auch nochmal zur besseren Lesbarkeit in HTML Form.
Praktisch: Ihr könnt mit allen Parametern die Installation anpassen und bei der ersten Installation mit dem Parameter /SAVEINF=filename das Set an Optionen in eine Konfigurationsdatei speichern. Für die nächste Installation reicht als Parameter dann nur noch /LOADINF. So lassen sich beispielsweise unterschiedliche Deploymentprofile erstellen und nutzen.

Plugins

Eine der Stärken von KeePass ist die starke Erweiterbarkeit mit Hilfe der vielen Plugins und Tools. Die Installation und Verteilung ist bei fast allen relativ einfach: es reicht schon die entsprechende Plugin-Datei (z.B. .plgx) in das Programmverzeichnis zu legen, ggf. auch in einen seperaten „plugins“ Unterordner für eine verbesserte Übersicht. Beim nächsten Start von KeePass wird das Plugin automatisch erkannt und geladen.
Aus diesem Grund kopiert das Deployment-Script benötigte Plugins einfach nur in den Installationsordner – fertig!

Deployment

Aktuell: Version 2.34 via .exe
Das im Skript verwendete Programm VersionCompare ist eine Eigenprogrammierung und hier als Download verfügbar.

Code anzeigenDen Code könnt ihr bequem mit den Links/Rechts Pfeiltasten horizontal bewegen.

Dieser Beitrag ist eine Ergänzung bzw. Erweiterung des vorherigen Posts „FTP-Backup-Lösung mit PHP“. Die große Neuerung der Version 1.2 ist die Funktion MySQL Datenbanken sichern zu können. Auch hier wird ein Backup erstellt, überschüssige Backups (wenn mehr vorhanden sind als der gewünschte Maximalwert) werden gelöscht und neue Backups ggf. zu einem externen Server übertragen. Mit Version 1.2.1 gibt es zusätzlich die Möglichkeit, ALLE Ordner der Root-Ebene, mit Ausnahmen, zu sichern und Version 1.2.2 ermöglicht detailliertere Ausnahmen.

Features

Diese Lösung (v1.2.2) bietet nun folgenden Funktionsumfang:

  • beliebig viele Ordner des All-Inkl Accounts in einzelne .tar.gz Archive sichern
  • oder: alle Ordner der Root-Ebene, mit möglichen Ausnahmen, sichern
  • Detailliertere Ausnahmen mit Datei- und Ordnermasken wie z.B. „*.tar.gz“
  • Einschränkung der Anzahl aufgehobener Backups – älteste Backups werden automatisch gelöscht
  • detaillierte Ausgabe inklusive benötigter Zeit
  • E-Mail Benachrichtigung
  • Farbliche Hervorhebung
  • Verbesserungen des Backup Prozesses, zusätzliche Überprüfungen und Debug Infos bei Fehlern
  • Verbinden eines externen FTP Server und Kopieren aller neuen Backups
  • Angabe eines beliebigen FTP Ports
  • Verbindung über FTPs (SSL FTP) Port 21 wird verwendet, unsicheres FTP nur noch als Fallback
  • detailliertere Informationen über die Backups in der Benachrichtigungsmail
  • Backup von beliebig vielen MySQL Datenbanken von localhost, Aufräumen der Backups und Export an externen Server
  • E-Mail Anpassungen über Parameter möglich – Betreff, Anmerkungen, Details
  • ausführliche Ausgabe aller Backups im Skript und per Mail

Zwischen den Zeilen 37 und 82 findet ihr alle Variablen, die ihr anpassen müsst/könnt.

Zur Datenbanksicherung ist zu sagen, dass diese auf den Hoster All-Inkl optimiert ist. Sie sichert nur Datenbanken von localhost und benötigt den PHP Befehl „exec()“ sowie die Komponenten „mysqldump“ und „gzip“, die auf All-Inkl Servern erlaubt bzw. installiert sind. Auf anderen Hostern müssen daher ggf. diese Möglichkeiten geschaffen oder die MySQL Sicherung (Zeile 190-191) verändert werden.

Screenshot

Das Bild zeigt die Ausgaben des Backup Skripts und die versendete E-Mail Benachrichtigung

Code

Schaut für Code-Alternativen oder ein weniger komplexes System auch auf die Version 1.1 und 1.0

Update 08.2017: Version 1.2.2 nur noch als Download
Code/Download der backup.phpx

Sicherheit: Absicherung mit .htpasswd

Das Verzeichnis, in dem die backup.php und die Backups liegen, sollte natürlich mit einer .htpasswd abgesichert werden. Mit einer eingerichteten .htpasswd Datei ist zuerst ein Login nötig, eh man auf bestimmte Bereiche des Webspaces zugreifen darf:
Das Bild zeigt eine Login Datenabfrage beim Aufruf der Backup URL
Die Datei .htpasswd enthält hierbei die Login Daten und in der .htaccess des Backup Unterordners wird festgelegt, dass eine .htpasswd diesen Ordner schützt. Die .htpasswd generiert ihr euch am besten mit diesem Generator und baut sie dann folgendermaßen in die .htaccess dieses Ordners ein:

Sicherheit: Absicherung mit .htaccess

Da wir schonmal bei .htaccess sind, erhöhen wir die Sicherheit mit ein paar weiteren grundlegenden Zeilen:

Dadurch werden Zugriffe auf bestimmte Dateitypen (auch die Backup Dateien), Verzeichnisse und Zugriffe mit sicherheitskritischen Merkmalen unterbunden. Alle diese nicht validen Zugriffe bekommen die index.htm serviert, welches einfach nur eine leere HTML Datei ist. Somit wird den Abfragenden auch kein detaillierter Grund gegeben, warum der Zugriff fehlschlug.

Automatisierung mit All-Inkl Cronjobs

Zu guter Letzt hilft diese Sicherungslösung natürlich nur, wenn sie automatisiert wird. Auch dies ist stark abhängig von eurem Hoster, System, dem Anwendungsbereich usw.
Im Falle von All-Inkl als Webhoster, könnt ihr die Cronjob Funktionalität im KAS (KAS -> Tools -> Cronjobs) benutzen:
Das Bild zeigt die Cronjob Einrichtungsoberfläche von All-Inkl

Dieser Beitrag ist eine Ergänzung bzw. Erweiterung des vorherigen Posts „FTP Backup Skript in PHP“.

Folgende Änderungen werde ich hier besprechen:

  • Erweiterung des Skripts
  • Sicherheit: Absicherung mit .htpasswd
  • Sicherheit: Absicherung mit .htaccess
  • Automatisierung mit All-Inkl Cronjobs

Erweiterung des Backup Skripts

Das neue Skript bietet nun neue Funktionalitäten:

  • Farbliche Hervorhebung
  • Verbesserungen des Backup Prozesses, zusätzliche Überprüfungen und Debug Infos bei Fehlern
  • Verbinden eines externen FTP Server und Kopieren aller neuen Backups
  • Angabe eines beliebigen Ports
  • Verbindung über FTPs (SSL FTP) Port 21 wird verwendet, unsicheres FTP nur noch als Fallback
  • detailliertere Informationen über die Backups in der Benachrichtigungsmail

Nun werden also von beliebig vielen Ordner des FTP-Root Backups erstellt, gegebenenfalls aufgeräumt wenn mehr Backups existieren als aufgehoben werden sollen und anschließend alle neuen Backups auf einen externen FTP Server kopiert. Für den Upload wird der passive FTP Modus verwendet, da dieser in den seltensten Fällen Probleme macht. Sollte der Wechsel zum passiven FTP fehlschlagen, wird dennoch aktives FTP probiert.
Alle nötigen Informationen werden in den Variablen in Zeile 16 bis 25 angegeben. Format und Hilfe steht jeweils dabei, eigentlich sollte da alles klar sein.

Die Erweiterungen machen aus dem Skript eine beispielhafte Backup-Lösung für FTP Inhalte. Auch hier am Beispiel von All-Inkl als Hoster. Wer die Lösung unabhängig von All-Inkl einsetzen möchte, wird das Archive_Tar PHP Modul und irgendeine Art von Cronjob-Funktionalität brauchen.

Screenshot

php-ftp-backup-neu

Code

Achtung: Update (09.06.2015): Dieses Skript ist Version 1.1, basierend auf dem grundlegenden Backup Skript aus diesem Artikel. In Version 1.2 (diesen Artikel) lassen sich nun auch MySQL Datenbanken mitsichern.

Update (02.06.2015): Anpassung der Variablennamen zur besseren Lesbarkeit, Fehlerkorrekturen, verbesserte FTP-URI-Verarbeitung, Portangabe möglich, Verbindung über FTPs (FTP über SSL über Port 21) möglich (mit Fallback zu unsicherem FTP wenn FTPs nicht funktioniert), erweiterte Informationen über die erfolgten Backups in der Benachrichtigungsmail, kleine Optimierungen
Code anzeigenDen Code könnt ihr bequem mit den Links/Rechts Pfeiltasten horizontal bewegen.

Sicherheit: Absicherung mit .htpasswd

Das Verzeichnis, in dem die backup.php und die Backups liegen, sollte natürlich mit einer .htpasswd abgesichert werden. Mit einer eingerichteten .htpasswd Datei ist zuerst ein Login nötig, eh man auf bestimmte Bereiche des Webspaces zugreifen darf:
Das Bild zeigt eine Login Datenabfrage beim Aufruf der Backup URL
Die Datei .htpasswd enthält hierbei die Login Daten und in der .htaccess des Backup Unterordners wird festgelegt, dass eine .htpasswd diesen Ordner schützt. Die .htpasswd generiert ihr euch am besten mit diesem Generator und baut sie dann folgendermaßen in die .htaccess dieses Ordners ein:

Sicherheit: Absicherung mit .htaccess

Da wir schonmal bei .htaccess sind, erhöhen wir die Sicherheit mit ein paar weiteren grundlegenden Zeilen:

Dadurch werden Zugriffe auf bestimmte Dateitypen (auch die Backup Dateien), Verzeichnisse und Zugriffe mit sicherheitskritischen Merkmalen unterbunden. Alle diese nicht validen Zugriffe bekommen die index.htm serviert, welches einfach nur eine leere HTML Datei ist. Somit wird den Abfragenden auch kein detaillierter Grund gegeben, warum der Zugriff fehlschlug.

Automatisierung mit All-Inkl Cronjobs

Zu guter Letzt hilft diese Sicherungslösung natürlich nur, wenn sie automatisiert wird. Auch dies ist stark abhängig von eurem Hoster, System, dem Anwendungsbereich usw.
Im Falle von All-Inkl als Webhoster, könnt ihr die Cronjob Funktionalität im KAS (KAS -> Tools -> Cronjobs) benutzen:
Das Bild zeigt die Cronjob Einrichtungsoberfläche von All-Inkl

All-Inkl bietet sogar das Zusenden aller Skriptausgaben. Ihr erhaltet also zusätzlich zu dem kurzen E-Mail-Bericht, der im Skript generiert werden kann, noch eine weitere Mail mit allen Ausgaben. Diese sind dann zwar nicht mehr farbig, aber was solls:
Das Bild zeigt die Cronjob E-Mail mit den Skriptausgaben

Danke an Kenny für das wertvolle Feedback im letzten Artikel, das dazu beigetragen hat, dass ich diese Erweiterung nochmal gepostet habe. Meinst du, dass das jetzt eine Basic Backup Lösung sein könnte? Das einzige, was noch fehlt, ist das Backup Management auf dem externen FTP Server, damit der nicht überläuft. Aber das ist nun wirklich Aufgabe der Admins zu entscheiden und zu verwalten, wie lange Backups aufgehoben werden sollen.