Beiträge von Arno

    a) Um eine Migration auszuführen sollte auf dem neuen Server David komplett installiert sein. Anlegen von Benutzern ist zu diesem Zeitpunkt noch nicht nötig, damit entfällt auch die Notwendigkeit, Rechte einzutragen. Mit erfolgter Installation ist der Ordner David vorhanden.

    b) Benutzer werden bei der Migration auf dem neuen Server automatisch angelegt. Auf dem alten Server muss der Servicelayer alle Benutzerverzeichnisse zumindest LESEN können. Ein Check ist durch Vollständigkeitsprüfung der letzten StrongBox Sicherung möglich.

    c) Die Geschwindigkeit variiert sehr stark je nach dem, ob SSDs im Einsatz sind und welche. Da eine Migration üblicherweise via LAN erfolgt kommt der zwischengeschaltete Switch auch als Flaschenhals in Betracht. Obwohl die theoretischen Daten eines Gigabit-Switches sehr viel höhere Geschwindigkeiten angeben ist in der Praxis beim Kopieren via LAN von einem Windows-System zum anderen nur ein Durchsatz von bis zu 30MB/s realistisch, wenn beide Rechner mit SATA3-SSDs ausgestattet sind. Darauf haben des weiteren die Bestückung der Netzwerkkarten, die CPUs, die RAM-Bestückung, die Kabelqualität und die verwendeten Virenscanner Einfluss.
    Beschleunigungs-Möglichkeiten gibt es durch Bündelung mehrerer LANs sowie durch Einsatz von SSDs mit NVMe M.2 Anschluss auf dem Zielrechner. Letztere müssen mindestens über einen PCIe Interface Anschluss Typ 3 mit 4 Lanes laufen, um die mögliche Schreibrate voll nutzen zu können.

    Weitere technische Infos zur Auswahl und Auslegung von SSD-Speichern siehe
    https://www.elektronik-kompendium.de/sites/com/0904051.htm

    Die Performance-Probleme beim RPD fallen mir in diesem Fall auf.
    Das ist ein sehr ungewöhnliches Phänomen.
    Ich vermute, dass die unterschiedlichen Zeiteinstellungen der drei Server dabei eine Rolle spielen.

    Denn wenn die Uhrzeiten auf den Servern nicht identisch sind, dann sind Netzwerkprobleme wie lange Antwortzeiten fast normal.

    Der Flaschenhals, der zu Problemen bei RDP-Verbindungen führt, ist meistens mangelnde Upload-Geschwindigkeit des Servers, mit dem der RPD Client verbunden ist.
    Nota bene: Bei ADSL ist die verfügbare Upload-Geschwindigkeit um den Faktor zehn kleiner als die Download-Geschwindigkeit. Also als erstes mehr Sendekapazität zur Verfügung stellen Das geht entweder durch Bündeln mehrerer Internetanschlüsse gleichzeitig oder durch Umstellung auf SHDSL (Anbeiter z.B. QSC / PLusnet). Im Einzelfall kann es auch helfen, die Leitungsqualität zu überprüfen und gegebenenfalls den Anschluss instand setzen zu lassen. Einige Bintec Router enthalten ein Prüfprogramm, mit dem ansatzweise Leitungsprobleme wie FEC- und HRC-Fehler protokolliert werden. Die sind dann im Monitoring sichtbar. Eine Leitungsprüfung mit einem speziell dafür ausgelegten Messgerät können diese einfach gestrickten Protokolle aber nicht ersetzen.

    Ein wenig Licht ins Dunkel kann schon ein vergleichender Ping-Test bringen. Dazu wird von einem entfernten Client aus zunächst eine bekannte Domain wie Google.com oder BMW.com gepingt. Anschließend folgt zum Vergleich eine Ping-Serie auf die drei Server.

    Last not least lohnt ein Check, ob nicht ein Virenscanner alle gesendeten Daten unnötigerweise überprüft. Auch das kommt als Fehlerquelle in Betracht, wenn Remotedesktop-Zugriffe so langsam sind wie beschrieben arbeitet.

    Ja, die Active Protection war aktiv mit "Wiederherstellen aus Cache". Ich habe zwar noch nicht im Logging gefunden, aber die Einstellungen habe ich gerade vorsichtshalber geändert (Prozess stoppen).
    Zudem werde ich vorläufig die automatischen Windows System-Updates auf dem Server deaktivieren und monatlich manuell anstoßen.

    Letzten Freitag (01.3.2019) rief mich morgens ein Kunde, der David mit aktuellem Rollout und 5 Benutzern einsetzt, ganz entgeistert an: "Ich kann meine eMails nicht mehr lesen, außer dem Betreff ist nicht mehr drin!"
    Gefundene Ursache: Irgendwie hatten sich Acronis 12.5 und das neue Funktionsupdate für Windows Server 2016 so verwurschtelt, dass trotz 32 GB RAM nicht mehr genug Arbeitsspeicher zur Verfügung stand. Und in der Folge baute David seine .dat Files nicht mehr richtig auf. Bei allen vier Usern, in denen neue eMails eingetroffen waren, dasselbe Bild: keine Inhalte mehr. In der Nacht vom 28.2. auf 01.3. nach dem Crash muss die Datenträgerbereinigung ganze Arbeit geleistet haben …

    Nach einem Serverneustart war zwar wieder genug Arbeitsspeicher frei. Aber die eMail-Inhalte waren erst mal weg. Zum Glück hatte ich dem Kunden Server eine tägliche StrongBox Sicherung eingerichtet. So konnte ich die meisten Daten wiederherstellen.

    Bleibt die aber Frage: Wie lässt sich so etwas verhindern?

    Der Preis für die Basic Edition ist viel zu hoch.
    Bei knapp 80,- € riskierten es etliche Kunden, mal einen Versuch mit David zu wagen.
    Aber nun mehr als das Dreifache? Das ist überzogen.

    Ich selbst habe nur noch eine 1 User Lizenz (David Pro) mit einem Faxport im Einsatz. Die ist für meine zwei Webshops und den Support alter Bestandskunden völlig ausreichend. Hoffentlich steigt deren SiteCare Preis nun nicht auch noch.

    Schon seit einem halben Jahrzehnt bin ich kein Tobit-Partner mehr, teile mir aber bis dato die Support-Arbeit mit einem noch aktiven Tobit Partner. Doch im letzten Jahr sind die Klagen von Kunden sehr vernehmlich geworden, dass Tobit zu teuer geworden ist. Wenn nun eine so kräftige Preiserhöhung kommt, wie sie aus den aktuellen Veröffentlichungen des Herstellers hervorgeht, dann wird das Ergebnis eine Katastrophe.

    Allerdings: Das aktuelle Rollout 297 ist problematisch! Ich erlebe Fälle, wo nach dessen Installation das bestehende selbst erstelle Zertifikat auf Smartphones nicht mehr akzeptiert wird. Folglich sind die Mails auf den Smartphones nicht mehr lesbar (iPhone).

    Abhilfe: Zurücksetzen der David Installation auf das vorherige Rollout. Danach lief bis jetzt alles wieder normal.

    Ihre Hardware-Firewall muss den gewünschten Ports ein- und ausgehend auf die IP des David-Servers (=Windows Servers) durchlassen. Solange diese Port-Weiterleitung nicht explizit in der Firewall (meist identisch mit der Gateway-Hardware) eingetragen ist können darüber keine Daten fließen. Meist ist für jeden TCP-Port eine eigene Regel in der Firewall nötig.

    Während der Testphase sollte die Software-Firewall des Server-Betriebssystem komplett deaktiviert sein.

    Rechte Maustaste auf die zu löschende Ablage.
    Dann "Im Explorer öffnen", alle Inhalte löschen. [Vorsicht: weg ist weg!]

    Anschließend Eigenschaften des Ordners öffnen und bei Dienste den Haken oder das graue Feld herausnehmen bei "Dateien zusammenfassen".
    Nächtliche Bereinigung abwarten. Am nächsten Morgen lässt sich auch der Ordner selbst löschen.