Hmm, Beitrag bearbeiten nicht angenommen.
Ich habe die Wiederholungszeiten enger zusammengefasst.
Was mir aber jetzt speziell aufgefallen ist, es sind nur *.t-online Empfängeradressen welche im Transit hängen bleiben. Sehr merkwürdig. Alle Mails sind "Antworten" Mails.
Gruß flic
Hmm, könnte sein.
Auf dem alten David-Server lief Avira, auf dem neuen Server (Server2019) habe ich erstmal die Boardmittel von Windows gelassen (Defender). Hat der ein solches Verhalten?
Danke für die schnelle Antwort.
Wie wäre de richtige Richtung? Mehr Versuche in einem längeren Zeitraum oder nur den Zeitraum erhöhen?
Hallo
Ein weiteres Problem...
Kunden senden uns Mails zu bei denen der Dateianhang nicht geöffnet werden kann, *.xlsx. Wenn der kunde die Mail ein 2. oder 3. mal versendet, ohne jegliche Änderung an der Mail oder am Anhang, ist der Anhang vorhanden und kann geöffnet werden.
Wo könnte da der Haken sein?
Danke
flic
Hallo
Wie habe das Problem das Mails im Transitverzeichnis liegen mit der Meldung "Verbindungsfehler". Als Versandzeit werden Zeiten gelistet wo definitiv niemand arbeitet (nachts).
Die Adressen bzw. betreff und Inhalt sind schon firmenbezogen, also kein Virus o.ä.
Woran könnte das liegen bzw. an welcher Ecke müssten wir nach dem Grund suchen?
Danke
flic
Danke, wenn man eben blind ist...
Hallo
Wir brauchen zwei zusätzliche User-Lizenzen. Ich finde nirgendwo eine Möglichkeit das als Kunde direkt zu machen. Auch nicht unter david.tobit.net.
Also woher nehmen?
Gruß Holger
Ich habe es relativ einfach mittels strongbox hinbekommen.
Eingang auf alten Server selektiv gesichert, auf dem neuen Server das Strongbox Image gemapt und die entsprechenden Mails in den Eingang kopiert.
Das mit dem exportieren werde ich mir merken.
Danke nochmal.
Hallo
Bei der Umstellung auf einen neuen David-Server ist heute ein kleines Missgeschick passiert.
Das Pollen im Grabbing-Server (und Postman-Dienst) waren seit gestern 21 Uhr abgeschaltet (22 Uhr erfolgt Datensicherung). Der Transfer auf den neuen Server per Strongbox-Image ging relativ problemlos.
Der Rechner mit dem alten Server musste heute einmal neu gestartet werden, bevor der neue Server online ging. Leider hatte ich vergessen den Haken für "bei Start verbinden) im Grabbing-Server raus zu nehmen. Somit hat der alte Server bei diesem einmaligen Start einmal die ganzen gelagerten Mails herunter geladen, über 100 Stück.
Hat jemand einen Trick wie ich die nachträglich auf den neuen Server übertragen kann?
Danke Holger
Hallo
Ich habe es hinbekommen.
Strongbox Image auf David Neuinstallation zurückgespielt. User mit gleichem Namen neu angelegt. Es wurden die User mit gleicher ID angelegt, jedoch falsch zugeordnet (User A hatte die ID von User B usw.). Danach die Logins den entsprechenden ID's zugeordnet und alles war ok. Vielleicht Zufall, oder System 
Holger
riawie
Danke für die Antwort.
Der alte Server bleibt noch im Netz und der Neue ist kpl. eingerichtet. Einzig David und ein paar Verzeichnisse müssen noch umziehen. Den DC nochmal umzubenennen um David zu portieren wage ich nicht.
Wundersam ist es, dass es bei einem User geklappt hat.
Bleibt wohl nur Weg 1, es sei denn es hat noch jemand eine Idee.
Hallo
Wir haben eine Umzug auf einen neuen Server (Essentials2019) geplant.
David wurde neu installiert und die Daten mittels Strongbox kpl. Backup zurückgesichert. Beim Wiederanlegen der Benutzer mit gleichem Namen werden teilweise neue Archivnamen vergeben. Bei einem User wurde das gleiche Archiv wieder erstellt/zugewiesen (z.B. 10010000), bei zwei weiteren Benutzern wurden neue Archivnamen erstellt (z.B. alt 10008000 - neu 10008010).
Wie kann ich es so zurechtbiegen, dass der alte Archivname verwendet wird?
Der Umzug soll am Wochenende Stattfinden und nur das aktuelle Strongbox-Image wiederhergestellt werden.
Danke Holger
Oups, ganz vergessen wegen der Strongbox-Geschichte.
Besten Dank, Punkt 2 war es, hat geholfen.
Hallo
David soll in nächster Zeit auf einen neuen Server (2019 Essential) umziehen. Das Ganze wieder per strongbox-Image.
Momentan teste ich die das Verfahren auf Windows Server um sicher zu gehen.
David wurde auf dem Server neu installiert und ein Strongbox-Image zurückgesichert. Hat auch problemlos funktioniert. Ich möchte ein paar alte Benutzerverzeichnisse löschen von Usern welche es nicht mehr gibt aber noch im Image waren. Ich bekomme jedoch immer die Meldung:
"Das Löschen von Einträgen in diesem Ordner ist nicht erlaubt."
Ich bin Administrator, Domänenadministrator usw. Warum kann ich als "oberster Dienstherr" nichts löschen?
Oder hab ich irgendwelche Rechtezuweisung nach der David-Installation vergessen?
Danke Holger
Hallo
Ok, ArcUtil wäre eine Möglichkeit. Aber David läuft problemlos außer der Sicherung-
Vorgehensweise:
David-Dienste kpl. stoppen
Archiv-Verzeichnis kpl. kopieren
ArcUtil ausführen
hoffen...
Wenn nicht, kopiertes Archiv-Verzeichnis zurück kopieren
So richtig?
Wobei das doppelte Benutzer-Verzeichnis im TIC ja eigentlich nur eine Verknüpfung darstellt.
Übers WE mal etwas experimentiert, die großen Images ab 331 lassen sich nicht wiederherstellen (wobei ich die Images mounten kann). Ich habe das Restore nach 19 bzw. 15 Stunden abgebrochen. Die kleinen Images vor 331 sind in 2,5h funktionsfähig wiederhergestellt. Die Strongbox-Images nach dem Update auf 331 sind also absolut nutzlos.
Eigentlich sollte, jetzt nach Ostern, David auf einen neuen Server (2019 Essential) umziehen, aber mit den defekten Images sehe ich da momentan keine Chance.
Da gibt es noch ein paar andere Probleme mit nicht löschbaren Benutzerverzeichnissen, aber das ist OT und sprengt den Rahmen.
Hat jemand noch irgendwelche Ideen? 
THX & Gruß Holger
Hallo
Ich habe mir die Images mal angeschaut und festgestellt, dass das Benutzer-Verzeichnis 2x vorhanden ist.
Check beim David-Server, da ist das Benutzer-Verzeichnis ebenfalls 2x vorhanden. (Das scheint schon länger so zu sein, aber wenn es funktioniert, denkt keiner darüber nach bzw. wundert sich.)
Das eigentliche Verzeichnis "Archive\User" ist jedoch nur einmal real vorhanden. Das kpl. David-Verzeichnis hat 77 GB, wovon 62 GB auf das Archive-Verzeichnis entfallen.
Kann es sein dass David mit rollout 331 das USER-Verzeichnis wegen des doppelten Benutzer Archiv 2x sichert?
Nun steh' ich da , wie bekomme ich eines der beiden Benutzer-Archive weg? Ohne die Archiv-Struktur zu zerstören. Einfach löschen ist mir zu gefährlich. Oder besser die Archive.dir editieren und den 2. Benutzer-Eintrag (nach media) am Ende löschen?
Ich habe die Dateien mal angehängt.
Wegen dem Service-Layer Problem (siehe Post#1) hatte ich das User-Verzeichnis auf Geheiß vom Tobit-Support umbenannt. Das Archiv war aber nicht das Problem, also wieder in "User" umbenannt. Nach Update auf 331 läuft David seit letztem Samstag wieder ohne Probleme, kein Problem in der Archivstruktur. Außer dem Update wurden keine weiteren Veränderungen vorgenommen. Nur die Backups waren doppelt so groß und lassen jetzt die Platte an ihre Grenzen kommen.
Ich habe mir jetzt ein altes kleines und ein neues großes Backup kopiert. Kann man die *.stbox Sicherungen extern auspacken? Ein ZIP-Format ist es nicht, RAR auch nicht. Ich möchte mir den Inhalt beider Sicherungen genauer ansehen.
Hallo
Die Images sind Vollbackups und hatten vor dem Update eine Größe von rund 45 GB (langsam über die Jahre angewachsen). Nach dem Update plötzlich rund 100 GB.
Der Job lief seit 04/2018 problemlos. Ich habe den Job schon gelöscht und neu erstellt, gleiches Ergebnis.
Gruß Holger
Hallo
Wie in der Überschrift geschrieben, sind seit der Installation des Rollout 331 die Strongbox-Images doppelt so groß. Von 45GB auf fast 100 GB angewachsen. Woran kann das liegen?
Irgendwelche dump- oder Protokolldateien wegen des Servicelayer-Problems (siehe hier )? Aber welches Protokoll schreibt 40 GB? 
Danke Holger
Hallo
Ich hatte den Download aus dem DavidAdmin gestartet, da aber der Servicelayer immer wieder abstürzte, fing der Download immer wieder von vorn an. Ich habe dann das Rollout direkt heruntergeladen. Da das Problem nicht am Archiv lag und im Eventlog nichts erkennbar war, habe ich das Rollout manuell gestartet. Danach lief der ServiceLayer wieder dauerhaft ohne Absturz. 
Nochmals Danke
Holger
