Bereinigung eines Verzeichnisses funktioniert nicht mehr

  • Hallo,

    vielleicht hat noch jemand einen TIPP:

    Es wird bei mir ein Verzeichnis nicht bereinigt:

    und zwar handelt es sich um ein Archive das diverse Spammails enthält:
    \\server4\david\Archive\USER\28\

    dieses Verzeichnis wächst täglich, jetzt wieder 1509 Dateien. "obwohl alles in David gelöscht wurde"

    Das Problem: lösche ich die Mails in dem Verzeichnis, sind diese in Tobit zwar weg, auf Dateiebene verbleiben die aber.

    Ich dachte , vielleicht sind die zu neu, aber Dateien ZB vom 19.02 die auch am 19.02 gelöscht wurden verbleiben in diesem Archive.
    heute ist der 24.2

    Ich dachte OK vielleicht ist eine Archive DAT defekt... so habe ich ein neues frisches Verzeichnis angelegt: Hier mittlerweile "28"

    ich habe darauf geachtet das es eine komplette neue "Zahl" enthält. Aber auch dieses frische Verzeichnis wird in die tägliche Bereinigung NICHT miteingeschlossen.

    Ich habe die Bereinigung beobachtet: Diese startet korrekt und endet korrekt.


    Finish purging Archive

    Elapsed Time
    11:29

    Total Archives
    20.314

    Total Entries
    1.401.285

    Entries purged
    691

    Bytes deleted
    83.685.443

    Auto Archive
    224

    Es scheint dieses Verzeichnis überhaupt nicht berücksichtigt zu werden. WTF!

    Hat jemand einen TIPP?

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

    Einmal editiert, zuletzt von kingcopy (24. Februar 2014 um 11:15)

  • Hast du dir schonmal einen detailierten Purge Bericht angesehen?

    MSGMAILNAMES ?

    ****************
    Wohl bald ehemaliger "Tobit Partner" :cursing: 2001 - bald wären es 20 Jahre...<X So geht man nicht mit seinen Partnern um !! Stichwort _Provisionen_.
    ****************

  • Ich kann die Datei nicht finden....

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Den Purgin Report bekomme ich nicht obwohl PostMasterEmailAddr = admin@xxxxxxx.xx in der David.ini festgelegt ist....

    Kann man den TAG irgendwo setzen?

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Zitat

    Hallo Kingcopy,

    der Purging Report wird per E-Mail an der Postmaster als Textdatei verschickt.

    Michael

    So einfach ist das leider nicht - damit der Report verschickt wird, muss das explizit eingeschaltet werden.

    Du musst in der David.ini einen Eintrag machen, wo du die E-Mail Adresse angibst an die der Purging Report gesendet werden soll:

    MSGMAILNAMES = <E-Mail Adresse>

    Danach den Service Layer neustarten.

    In diesem Knowledge Base Artikel ist das noch mal genau beschrieben: Q-109.958

  • Danke Basti habe nun den Report:

    Im Report wird der Ordner überhaupt nicht berücksichtigt, allerding sehe ich einige invalide Archive Path..
    Die werde ich eerstmal abarbeiten und schauen wie die Purging sich danach verhält.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Ich habe hier alles versucht.

    Die Purgin Report enhält keine Fehler mehr.

    dennoch werden tatsächlich neue Verzeichnisse die erstellt werden in der Purging nicht mehr berücksichtigt.
    Es finden sich die Einträge NICHT im Purgin Report.

    Ich frage mich wieviele Verzeichnisse im Mailsystem ebenfalls nicht mehr bereinigt werden.

    ich glaube ich habe hier einen generellen "von Natur aus nicht existierenden" neuen Fehler gefunden.

    Dann brauchen sich die Leute nicht zu wundern wenn die Server nach jahren durch 1 Millionen Tote Dateien Verzeichnisse, langsam werden!

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Der Fehler ist absolut nicht neu.

    Fast jede zweite Woche stelle ich ähnliche Probleme bei meinen Bestandskunden fest:
    Alle im David-Infocenter vorhandenen Einträge sind gelöscht.
    Trotzdem sind auf Windows-Ebene tausende verwaiste Dateien zu finden.

    Erfolgversprechende Maßnahme, wenn meine Bestandskunden solche bleiben sollen:
    Ich befasse mich intensiver mit Microsoft Exchange.

    Mein Partnervertrag mit Tobit.Software endet im Mai. Ich kann generell keine Empfehlung mehr für Tobit-Produkte geben, da mir seit Jahresanfang 2014 die schon seit mehr als zwei Jahren bestehenden massiven Datenschutz-Verstöße des Herstellers bekannt sind. Der gesetzlichen Verpflichtung, bekannte Datenschutz-Probleme den Kunden mitzuteilen, ist die Tobit.Software AG nicht nachgekommen.
    Solange diese Datenschutzprobleme nicht behoben sind widerspricht es meiner Berufsehre als Ingenieur und Sachverständiger, für die betroffenen Produkte eine Empfehlung zu geben.

    2 Mal editiert, zuletzt von Arno (15. März 2014 um 13:37)

  • Von mehreren David-Nutzern wurde ich nach Details zu den oben angesprochenen Datenschutz-Probleme befragt.

    Die Informationen wurden mir erstmals in KW 49-2013 und dann detailliert in KW 01-2014 zugetragen, und dies von Seiten Dritter, die weder Mitarbeiter noch Partner der Tobit.Software AG sind.
    Es haben ergo Personen Zugang zu Informationen erhalten, die nicht für sie bestimmt sind.
    Die Sicherheits-Interessen meiner Bestandskunden, zu denen Industriebetriebe gehören, muss ich absolut ernst nehmen.
    Damit ausreichende Sicherheitsmaßnahmen getroffen werden können erfolgt an dieser Stelle eine Veröffentlichung der am 16.3.2014 bestehenden gravierenden Sicherheitslücken:

    1) Der Link bringt zu JEDER Site-ID das vom Hersteller im Lizenzschlüssel vergebene Kennwort CCCCC
    AAAAA und BBBBB stehen dabei für die ersten beiden Blöcke des Lizenzschlüssels. Der dritte Block CCCCC wird als Ergebnis des Linkaufrufs geliefert.

    Link 1 funktioniert auch bei djukebox-Systemen. Deren Passwort ist bis dato gemäß Support-Mitteilung gar nicht änderbar. Mir liegen die Reklamation eines djukebox-Bestandskunden vor, bei dem die eingetragenen Bankdaten von Seiten bislang unbekannter Dritter geändert wurden.
    Ob die einfache Anzeige des vom Hersteller vergebenen Passworts auch für die Software-Produkte chayns und Radio.fx zutrifft ist noch zu prüfen.

    2) Mit dem Link erhält JEDER, der Kenntnis von der Site-ID hat, das vom Nutzer der Lizenz GEÄNDERTE Kennwort. CCCCC steht dabei für das vom Hersteller vergebene Passwort. Das vom Lizenznehmer geänderte Passwort befindet sich unverschlüsselt (!) im Quelltext des oberen Teils der nach Aufrufs des Links angezeigten Seite. Dieses Passwort ist am einfachsten durch Eingabe des Suchstrings LOGIN zu finden. (Zur Anzeige des Quelltextes genügt die im Internet Explorer enthaltene Funktion "Quellcode anzeigen". Der Funktionsaufruf ist nach Drücken der rechten Maustaste möglich. Die Funktion befindet sich etwas unterhalb der Mitte des Auswahlliste). - Die nach Link-Aufruf erscheinende Seite läuft nicht auf den David-Servern der Lizenznehmer, sondern unverschlüsselt und ungesichert als Shadow der root-Seite der David.Administrator-Einträge der Kunden ohne deren Genehmigung auf den Servern der Tobit.Software AG. Eine Information darüber in den Datenschutz-Hinweisen des Herstellers fehlt nach heutigem Kenntnisstand.

    Die Site-ID des Installation wird auf JEDEM David-Client innerhalb einer Netzwerks angezeigt. Dazu gehören auch David-Clients, die nur Remote via TCP mit einem David-Server verbunden sind.

    Aus dem heutigen (16.03.2014) bestehenden Ist-Zustand ergeben enorme Risiken für die Lizenznehmer. Dazu eine kleine Auswahl:

    A) Mit Kenntnis der Site-ID und des zugehörigen Passworts ist jede Bankverbindung und jede Kreditkarten-Information, die IM TSSM hinterlegt wurde, für Unbefugte in unverschlüsselter Klarschrift lesbar. Diese Daten können an anderer Stelle - zum Beispiel für Bestellungen übers Internet - missbraucht werden.

    B) Erfolgten Einträge von Nutzern im TSSM (Tobit Software Sitemanagement, so kann jeder Beliebige deren Namen und die Funktion im Unternehmen einsehen.

    C) Es können ohne Wissen und Zustimmung des Lizenznehmers von Unbefugten Änderungen der mit der Tobit.Software AG bestehenden oder nicht bestehenden Verträge vorgenommen werden. Insbesondere betrifft das die Verwaltung der SiteCare-Verträge, da für deren Abschluss oder Änderung lediglich die Kenntnis der Site-ID und des zugehörigen Passworts nötig ist. Auch innerhalb von Netzwerken mit mehreren tausend David-Clients ist die Site-ID überall sichtbar.

    D) David-Virenschutz und der Message Identifikation Service können von Angreifern abgeschaltet werden. Dann lässt sich bequem beispielsweise ein Trojaner installieren. Anschließend werden die beiden Dienste wieder eingeschaltet. Weder der David Lizenznehmer noch sein Administrator kann das rechtzeitig erkennen und gegensteuern.

    E) Die vollständigen Startlizenzen sind online über den Menüpunkt Lizenzen sichtbar. Daher sind sie auch kopierbar und können daher beispielsweise auf den Servern eines Spam-Versenders eingesetzt werden.

    F) Die Fachhändler-Zuordnung jeder Lizenz von Tobit.Software kann ohne Wissen und Zustimmung des Lizenznehmers auf einen anderen Fachhändler übertragen werden. Die einzig erforderliche Information ist die Site-ID, denn das zugehörige Passwort ergibt sich aus obigen Links.
    Genau die unerlaubte Änderung Fachhändler-Zuordnung ist mir bei einem wichtigen Bestandskunden passiert. Nach einem erfolgtem David-Update wurde mir zunächst die Provisionszahlung verweigert mit dem Hinweis, diese Lizenz sei zum Zeitpunkt des Updates ja gar nicht in meinem Kundenbestand gewesen. Der Nachweis war in diesem Fall sehr einfach, da ich bei diesem Kunden nicht nur die Betreuung, sondern auch die Urlaubsvertretung des Administrators mache.

    E) Die Sicherheitsfunktion, wonach nur der ausdrücklich Befugte wie Administrator oder Geschäftsführer eines Unternehmens einen kostenpflichtigen Vorgang auslösen dürfen, ist vollständig ausgehebelt.

    Die Missstände sind gemäß Zeugen dem Management der Tobit.Software AG bereits seit über zwei Jahren bekannt. Sie wurden gemäß erhaltener telefonischer Information damals schon hier im David-Forum diskutiert, aber leider kann ich die zugehörigen Einträge nicht finden. -
    Eine Behebung dieser Datenschutz-Probleme ist in nun mehr als zwei Jahren bis dato absolut NICHT erfolgt.

    Was ist nun zu tun? Nun, da gehen die Meinungen etwas auseinander. Ich empfehle momentan folgendes:
    I) Es sollten so wenig Informationen wie möglich ins TSSM eingetragen werden.
    II) Da MIS und Virenschutz von david zu leicht auszuhebeln sind empfehle ich den Einsatz von Spam- und Virenschutz-Systemen von Drittanbietern. Selbige sind darauf zu prüfen, ob Sie Viren abfangen, obwohl der Empfang über den Grabbing-Server als Dienst läuft. Mit Einsatz des Systeme von Drittanbietern ist es überflüssig, Bank- oder Kreditkarten-Daten ins TSSM einzutragen.
    III) Der Status online abschließbarer Verträge über David-Virenschutz, MIS und SiteCare sollte beim gegenwärtigen Stand der Dinge mindestens monatlich überprüft werden. Auch der Status des Translation Service sollte gelegentlich überprüft werden, da dessen Nutzung auf "anderer Leutes Kosten" für Unbefugte verlockend ist.
    IV) Sollte das Update eines Produkts von Tobit.Software nur möglich sein, wenn dazu Kreditkarten- oder Bankdaten online im TSSM oder bei david.tobit.net zu hinterlegen sind, dann sollte beim heutigen Stand wegen mangelhafter Datensicherheit darauf verzichtet werden. Die Gefahr des Missbrauchs dieser sensiblen Daten durch Cyber-Kriminelle ist zu hoch.
    V) Der Status einer korrekten Fachhändler-Zuordnung sollte spätestens alle zwei Monate überprüft werden.
    VI) Port 267 sollte in der Firewall geschlossen werden, damit remote keine ungenehmigte Nutzung von Backline Features erfolgen kann.

    Last but not least: Jedwede Remote-Verbindung zu einem David-Server sollte am besten nur noch über registrierte VPN-Verbindungen erfolgen. Alles andere, auch der Weg über den SSL-verschlüsselten Port 443, erscheint nicht mehr ausreichend sicher. Es sollten dabei Server-seitig VPN-Router eingesetzt werden, die ein Ausschließen nicht mehr gewünschter VPN-Clients ermöglichen. (Letzteres ist zum Beispiel nach Geräte-Diebstahl oder bei Ausscheiden eines Mitarbeiters aus dem Betrieb wichtig).

    41 Mal editiert, zuletzt von Arno (15. April 2014 um 00:19)

  • Guten Tag Arno,

    vielen Dank für die ausführlichen Informationen. Wenn diese Äußerungen stimmen, sollte man diese nicht nur in diesem
    Forum bekannt geben, sondern würde das weiter an die Presse rantragen. Ich schätze die Heise ist an solchen Sachen immer
    sehr interessiert gewesen.

    VG,

  • Und was hat das ganze jetzt mit kingcopys Purging Report zu tun? Hilft das jetzt irgendwie weiter? Noch dazu gibst du hier eine detaillierte Anleitung, wie man eine Sicherheitslücke ausnutzen und Daten missbrauchen kann, lieferst sogar Ideen, was man mit den Daten alles machen kann. Das passt aber dann in deine "Berufsehre als Ingenieur und Sachverständiger"? Ob sowas in die Netiquette eines Forums passt wage ich auch zu bezweifeln.

    Schon seltsam, wenn man deine Beiträge so liest warst du immer jemand, der sich für Tobit und ihre Produkte ausgesprochen hat. Jetzt auf einmal bist du totaler Tobit Gegner. Nur wegen der Sicherheitslücke, die es schon 2 Jahre gibt? Wenn dir die Sicherheit so wichtig ist, warum dann nicht vor 2 Jahren schon dieser Aufstand? Irgendwie glaube ich nicht, dass das Ende der Partnerschaft von deiner Seite so ganz freiwillig war..

    Aber gut, ich sehe... 

    Zitat

    Dieser Beitrag wurde bereits 36 mal editiert, zuletzt von »Arno« (Gestern, 16:37)


    ...du hast sicher besseres zu tun ;)

  • @Altair:
    Bitte immer erst in Ruhe lesen sowie verstehen und erst dann meckern. -
    Ich bin über den Status der Sicherheitsprobleme erst Anfang Januar 2014 informiert worden.
    Wäre ich früher darüber informiert gewesen, dann hätte ein Düsseldorfer Arbeitgeberverband letztes Jahr auf Microsoft Exchange umgestellt statt ein David-Update zu erwerben.

    @Kamil:
    Die Äußerungen stimmen.
    Ich bin bereit, mich diesbezüglich in einem Gerichtsverfahren vereidigen zu lassen.
    Die Identität der Informanten unterliegt allerdings dem Zeugenschutz.

    Was die Weitergabe der Informationen an Journalisten angeht, so gilt der alte Leitsatz für Führungskräfte:
    "Es gibt nichts Gutes, es sei den Du tust es."

    Was die Funktion der Links angeht, so ist diese mit beliebiger Site-ID prüfbar.
    Übrigens funktioniert die Passwortausgabe auch bei einer chayns-Lizenz.

    Für das nachfolgende Beispiel habe ich eine reale chayns-Lizenz mit der Site-ID 64389-16130 ausgewählt.
    Zur Dokumentation sind die mittels david Bild-Funktion erzeugten Bilder einschließlich des automatisch erzeugten Zeitstempels hier hineinkopiert.
    Die david Bild-Funktion wurde innerhalb einer Minute nach Bildausgabe durch die Links angewendet.

    Die Eingabe von liefert zum Zeitpunkt der Dokumentation den vollständigen Lizenzkey mit Passwort auch bei chayns:

    [Blockierte Grafik: http://www.antons.de/public/picchayns.jpg
    .

    http://dvadmin.tobit.com/dvp.asp?p=6438916130BKNSA
    liefert leider auch hier im Quelltext in den Zeilen 250 und 258 der angezeigten Seite das geänderte Passwort in Klarschrift, obwohl zu chayns nirgends von einem zugehörigen David Administrator berichtet wird.
    [Blockierte Grafik: http://www.antons.de/public/ossochayns.jpg
    Und nicht nur das - ein Klick auf Tobit Software Site Management genügt für alles Weitere.
    Schade übrigens, dass das Passwort immer noch nicht Case-sensitive ist.
    Sicherheitstechnisch orientiert sich die Vorgabe hier zu sehr an der Qualifikation von Kindern statt am Bedarf von Firmen.


    Ich schätze, dass david, djukebox und chayns zusammen gerechnet, mehr als eine halbe Million Lizenzen von den Sicherheitsproblemen betroffen sind.
    Dabei sind alte David-Version eingerechnet. - Bei jeder djukebox steht die Site-ID ab Werk auf der Rückseite.

    Die Anwendung des Links bei Radio.fx führt übrigens zum gleichen Ergebnis.
    Das ist bei EInzelplatz-Installation aber belanglos, da der vollständige Lizenzkey ohnehin unter Datei / Einstellungen / System jederzeit sichtbar ist.

    Abschließend bleibt zu erwähnen, dass meine via Partner-Kommunikationssystem im Dezember 2013 und Januar 2014 wiederholt erfolgte Anfrage nach Benennung des Datenschutzbeauftragten der Tobit.Software AG nicht zu einem Resultat führte. Der Inhalt der statt dessen Antworten erweckte bei mir den Eindruck, dass entweder ein solcher Datenschutzbeauftragter nicht existiert oder dass er in seiner Arbeit massiv behindert wird.

    33 Mal editiert, zuletzt von Arno (19. März 2014 um 18:43)

  • um wieder auf die PURGIN zurückzukommen:

    heute enthielt das Purgin Report doch tatsächlich 2 gelöscht Einträge:


    Verzeichnis 28:

    I3040469.001 - \\SERVER4\DAVID\archive\user\1000C000\$remind$\I3040469
    I3040469.0tx - \\SERVER4\DAVID\archive\user\1000C000\$remind$\I3040469
    I322E2F6.001 - \\SERVER4\DAVID\archive\user\1000C000\$remind$\I322E2F6
    I322E2F6.0tx - \\SERVER4\DAVID\archive\user\1000C000\$remind$\I322E2F6
    IDF4D287.001 - \\SERVER4\DAVID\archive\user\1000C000\$remind$\IDF4D287
    IDF4D48A.001 - \\SERVER4\DAVID\archive\user\1000C000\$remind$\IDF4D48A
    IDF4D48A.0tx - \\SERVER4\DAVID\archive\user\1000C000\$remind$\IDF4D48A
    I303DB5B.001 - \\server4\david\ARCHIVE\USER\28\I303DB5B
    I303DB5B.0tx - \\server4\david\ARCHIVE\USER\28\I303DB5B

    I2FE37A8.001 - \\SERVER4\DAVID\archive\user\10014000\in\I2FE37A8
    I2FE37A8.0tx - \\SERVER4\DAVID\archive\user\10014000\in\I2FE37A8
    I2FE3D17.001 - \\SERVER4\DAVID\archive\user\10014000\in\I2FE3D17

    verbleiben:

    verbleiben noch 8096 Dateien bis zum 19.02.2014

    [Blockierte Grafik: http://www.grizzly.biz/bilder/unbereinigt.jpg]

    ich verstehe die Arbeitsweise der Bereinigung nicht mehr.....

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

    Einmal editiert, zuletzt von kingcopy (18. März 2014 um 09:10)

  • Hallo kingcopy,
    richten Sie Ihr Augenmerk bitte einmal auf das Verzeichnis. Dort steht ...\user\28\...

    In den letzten elf Jahren beginnen die von david und Vorgänger-Versionen benutzten User-Verzeichnisse stets mit \10..., aber nicht mit 28. Und sie sind achtstellig, nicht aber zweistellig. Die kurze Länge des Verzeichnisnamens kann bedeuten, dass die User-Verzeichnisse händisch manipuliert wurden. Stammt - um das zu beurteilen fehlen mir einige Informationen - der kurze Verzeichnisname noch aus der Anfangszeit der David-Systeme, dann ist ein frühes Update nicht korrekt gelaufen.

    Beide Varianten führen zu einem inkonsistenten Filesystem.

    Natürlich könnte auch jemand mehr als 28 neue Verzeichnisse (die Zählung erfolgt hexadezimal) unterhalb von Servername\Benutzer angelegt haben. Aber bei richtiger Vergabe der Zugriffsrechte und ausreichender Sorgfalt des System-Verantwortlichen kann das nicht passieren. Es kommen also wohl nur die ersten beiden Varianten als Ursache in Betracht.

    Einmal editiert, zuletzt von Arno (18. März 2014 um 10:16)

  • Die Eingabe von liefert zum Zeitpunkt der Dokumentation den vollständigen Lizenzkey mit Passwort auch bei chayns:


    Hallo Arno, gut zu wissen. Allerdings ist auch gut zu wissen, welche Site-ID du hast. Zum Glück hast das Passwort geändert, sonst hätte ich jetzt eine neue David Lizenz für Lau gehabt. Was sagst du als Datenschutzbeauftragter den dazu, Lizenzschlüssel einfach so im Internet zu verbreiten? Zumal die Lizenzen einen gewissen Wert darstellen. Ich kann an dieser Stelle nicht prüfen ob die Lizenz echt ist, aber wir geht es hier eher ums Grundsätzliche.

    Aber gut, die Echtheit der Lizenz ließe sich bei einer kurzen Frage bei Tobit feststellen :)

    Gruß tskasa

  • @Tskasa & dertampon:
    Der Lizenzkey ist echt. Ich habe ihn lediglich verschenkt.
    Es handelt sich nicht um eine david-, sondern um eine chayns-Lizenz.
    Findet jemand das aktuell für diese Site-ID geltende Passwort heraus, so darf er via club.tobit.com seine Bankdaten der Kontoverwaltung der Site-ID hinzufügen. (Bitte aus ausreichende Konto-Deckung achten). -

    Seit gestern Nachmittag funktioniert Link 1 nicht mehr.
    Damit kehrt bis auf weiteres erst mal Ruhe ein.
    Hoffentlich hält sie eine Weile an.

    2 Mal editiert, zuletzt von Arno (19. März 2014 um 18:36)

  • Wenn man unter BENUTZER (USER) Eigene Verzeichnisse anlegt werden die mit 2. Stelligen fortlaufenden Nummern versehen, nur die USER (MENSCHEN) Die vom Servicelayer angelegt werden, werden mit der 8 Stelligen Nummer eingetragen.


    Es war nie Verboten im User Verzeichnis eigene gemeinsame oder Sortierte Ordner anzulegen.
    Diese wurden schon immer mitbereinigt.


    Ich denke das Problem ist mit dem VORLETZTEN SiteCare Servicepack vor dem 19 oder 17.02 in das System eingeflossen.

    Check LOGFILES: "Neustes Rollout David vom 24.01 eingespielt." Ab Da scheint die Bereinigung nicht mehr zu funktionieren, Checke Changelogs.

    Noch schlimmer: ich vergleiche die bereinigten Megabytes: die Zahlen der Bereinigung sind definitiv viel zu gering an MB normalerweise wurde täglich 900 MB Bereinigt, jetzt ist der Faktor 100 MB bei fast 100 USERN, ZU WENIG!


    FAZIT:
    Wenn das bei allen so ist werden in Kürze je nach Leistung der Server ganze David Installationen kollabieren! Steigerungs der Filesysteme RATE: 9:1 / auch meine Server können den Faktor 9:1 nicht ewig aushalten.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

    8 Mal editiert, zuletzt von kingcopy (20. März 2014 um 14:35)

  • Ohne Zweifel: Es war nie Verboten im User Verzeichnis eigene gemeinsame oder Sortierte Ordner anzulegen.
    Denn mit einem solchen Verbot würden Entwickler und Supporter ja den Kunden unzulässig bevormunden.

    Aber ratsam war es auch noch nie, die Struktur unterhalb von User so wie geschehen zu erweitern.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!