Beiträge von Arno

    Grundsätzlich hat sich vieles gebessert. Denn die Clients können ja - zunächst ohne Verbindung zu einem David-Server - eigenständig an einem Remote-Arbeitsplatz installiert werden. Sobald sie sich über Port 267 mit einem David-Server verbinden erfolgt automatisch eine Versionprüfung. Hat der Client einen älteren Stand als der Server dann erfolgt ein Client-Update via TCP-IP. Je nach Standort geschieht dies über das LAN oder über die Internet-Verbindung. Dazu erhält der Client über die Einstellung "Netzwerk / David-Server ..." die nötigen Informationen. Port 267 muss dazu in der Firewall ein- und ausgehend freigeschaltet sein. Dies gilt natürlich auch für eventuell eingeschaltetet Software-Firewalls der Arbeitsplatzrechner.

    Mit einer automatischen (!) Verteilung von David-Clients, zum Beispiel auf jeden neuen Rechner im Intranet, habe ich jedoch keine Erfahrung und auch keine Infos.

    Es kommt recht oft vor, dass ein User in Hektik beim Löschen von Spams die Option wählt: Ziel blockieren oder Kombination blockieren. Danach werden alle an diese eMail-Adresse gerichteten Nachrichten sofort gelöscht.

    Ich empfehle daher den Systembetreuern meiner Kunden im David-Administrator nur denjenigen das Recht zu geben, Regeln anzulegen oder zu verändern, die genau wissen was sie an der Stelle tun. Die Regeln aller anderen User sollten möglichst nur von Systembetreuer gesetzt werden. Übergangsweise kann das zwar unfreundliche Worte seitens der Betroffenen geben. Aber es hilft ...

    Problemlösung:
    Rechte Maustaste auf Ablage-Ordner / Eigenschaften / Dienste.
    Haken rausnehmen bei "Dateien zusammenfassen".
    Dann Datenbereinigung im Dvise-Admin nochmal ausführen.

    Ein automatisches Zurück-Verschieben gibt es nicht.
    Denn es könnte zu einem ziemlichen Durcheinander führen, wenn ein David-User seine Ordnerstruktur zwischenzeitlich verändert hat.

    Anmerkung:
    In früheren Versionen nannten sich die Ablage-Ordner TAS. Funktion und darunter liegende Struktur sind gleich.

    Bei Updates etwas sparen und dem Tobit-Partner eine Freude machen - das geht einfach.
    Der betreuende Partner darf das Update ein paar Prozent günstiger anbieten an der Hersteller (Tobit.Software) selbst. Dazu kauft er das Update bei Tobit ein und verkauft es Ihnen. Davon kommt ihm die Handelsmarge zugute. Er muss nur die Fakturierung selbst übernehmen und trägt das Risiko, das der Besteller nicht zahlt.

    Kauf nun ein Tobit-Kunde ein David Update online direkt beim Hersteller, dann zahlt er etwas mehr. Und sein betreuender Partner geht weitestgehend leer aus. Denn wenn der Kunde den Update-Vorgang online selbst ausführt, dann erhält sein betreuender Tobit-Partner neuerdings eine Umsatzprovision nur noch auf die SiteCare-Services.
    Die neue Regelung ist bitter für die Tobit-Partner. ;( Denn an Neulizenzen schon seit zwei Jahren nichts mehr zu verdienen. Und nun fällt auch noch ein Teil der Update-Erlöse weg.

    Also liebe Kunden: Bitte kein Geld verschenken, sondern Updates möglichst beim betreuenden Tobit-Partner bestellen statt im Direktvertrieb beim Hersteller. *)

    Wichtig zu wissen: Das Aktions-Angebot "chayns-Lizenz kostenlos dazu" gilt gemäß telefonischer Mitteilung der Partnerbetreuung auch dann, wenn das Update über den Partner bestellt wird statt im Direktvertrieb. Gültig für David-Updates bin Ende Juni 2013, wenn SiteCare-Service mit gebucht wird.

    *) Noch kein betreuender Partner eingetragen? Einfach auf der Seite david.tobit.net passenden Partner nach Ort und Qualifikation (Zertifizierungen) auswählen.

    Ich mag Probleme, die sich quasi von selbst erledigen.
    Wahrscheinlich lag nur ein Zugriffsproblem nach einer Installation vor. Aber das man der Fehlermeldung natürlich nicht an.
    Es dürfte in so einem Fall ausreichen, die Dienste Webbox und Servicelayer neu zu starten.

    Es gibt für's iPhone sowohl eine david App als auch eine David.fx12 App. Wahrscheinlich passt die verwendete App nicht zum Versionstand der David-Installation: Mit einem Rollout wird aus einem David.fx ein david.
    Übrigens kann nach Erwerb eines david-Updates oder einer neuen Lizenz von david der SiteCare-Service gut einen Monat lang verwendet werden, auch wenn er nicht gebucht wurde. Das aktuelle Rollout ist in beiden Fällen verfügbar.

    Ansätze zur Problemlösung:

    - Gibt es im root-Verzeichnis des betroffenen David-users Dateien mit Namen wie dic.cfg ? Dann versuchsweise umbenennen.

    - Falls auf einem der Server Wins-Einträge gemacht wurden dann auf dem Client die Hosts.ini editieren. Dort Namen und IP des aktuellen Servers eintragen.

    - Im Internet-Explorer Größe des Cache auf 50 MB begrenzen und Haken setzen für automatischen Löschen beim Schließen des Browsers.

    - Im David-Client unter Einstellungen / Ansicht die Animationseffekte für Dialogfenster abschalten (= nicht erlauben)

    Das direkte Kopieren von Archiven kann zwischen zwei David-Servern nur dann funktionieren, wenn diese Server den identischen Namen haben. Andernfalls entstehen ungültige Pfadbezüge in den Steuerdateien der kopierten Verzeichnisse. Diese lassen sich zwar mit ARCUTIL nacharbeiten und korrigieren, aber das kann ziemlich zeitaufwendig werden.

    Die möglichen Wege wären also:
    a) Für Namensgleichheit zwischen den Servern sorgen und die Archive auf einen anderen Rechner zwischenspeichern. Der Quellserver wird dann ausgeschaltet und der Zielserver eingeschaltet.

    b)das Tool MKINST zu nutzen.

    oder c) einen Tobit-Partner beauftragen, der mittels einer Servermigration die Inhalte von Server1 auf Server2 überträgt. Das Programm läuft nach Starten stabil, kann also unbeaufsichtigt arbeiten. Allerdings muss der beauftragte Tobit-Partner über die Migration-Lizenz verfügen.

    Das klingt eher nach einem Netzwerkproblem. Also:
    1) auf beiden Clients feste IPs einrichten.

    2) Prüfen, ob die Clients Mitglied der Domäne sind und ob die DNS-EInträge auf den Clients die des Domaincontrollers sind und nicht die des Routers.

    3) Auf dem Domaincontroller prüfen, ob ungewöhnliche DNS-Fehler aufzeichnet werden.

    @Despo: grundsätzlich nach RFC 5322 zulässig sind geschweifte Klammern im local Part einer eMail-Adresse in der Tat. Aber die mir bekannten Provider verweigern die Erstellung von eMail-Alias oder eMail-Konten, die eine geschweifte Klammer enthalten. Denn geschweifte Klammern finden als Variablenkennung Verwendung.

    @Kato: ausprobieren. Ggfs. via Intercom mal eine dem entsprechende Anfrage einsteuern.

    Geschweifte Klammern haben in der David-Syntax eine spezielle Bedeutung. Sie bezeichnen beim Anlegen eines Verzeichnisses den auf Windows-Ebene zu verwendenden Namen. Der vor der geschweiften Klammer liegende Teil des Betreffs ist der Verzeichnis-Name im David-Client, der innerhalb der Verzeichnisname auf Windows-Ebene.

    In einer eMail-Adresse hat eine geschweifte Klammer - also ein Sonderzeichen - nichts zu suchen. Denn diese Sonderzeichen werden je nach eingestellter Browser-Landessprache unterschiedlich dargestellt und sollten daher in Adressen vermieden werden. Wenn die Dokumentenverwalter das mit den geschweiften Klammern so haben wollen, dann werden noch einige Probleme auf die zukommen. Denn nicht nur Java-Scripte können da schon mal etwas seltsam drauf reagieren.

    Möglicherweise liegt ein Übersetzungsfehler vor, und die Amis wollten die geschweifte Klammer im Betreff und nicht im eMail-Namen. Oder aber das DMS fügt die geschweiften Klammern und dazwischen liegende Zählvariablen hinzu, um die Nachrichten wiederzufinden. Damit sind sie die Klammern aber NICHT Teil der eMail-Adressen. Ergo ist vor dem Beantworten solcher eMails die geschweifte Klammer zu entfernen!

    Bei europäischen Providern ist ein Sonderzeichen wie die geschweifte Klammer im eMail-Namen nicht zulässig und wird beim Anlegen eines neuen eMail-Alias normalerweise als ungültig abgewiesen.

    Die Antwort des Tobit-Supports zum Eingangs geschilderten Papierkorb-Verhalten lautet wie folgt:

    "Es wird immer nur eine Objektverknüpfung in den Papierkorb gelegt. Erst wenn alle Objektverknüpfungen erloschen sind, wird das Quelldokument gelöscht. Wenn Sie das Quelldokument anderweitig löschen (in diesem Fall den ganzen Quellordner löschen) kann das der Papierkorb nicht wissen und zeigt den Link natürlich auch noch an - wenn auch mit leerem Inhalt."

    Die Auswirkungen die dass daraus entstehen könnten, dass ein User seinen Papierkorb als Zwischenablage nutzt, halte ich für vernachlässigbar. Denn erstens setzt es die bewusste Handlung des Users voraus, Daten in den Papierkorb zu werfen und im gleichen Arbeitsschritt auch noch den Quellordner zu löschen. Und zweitens gibt es die Strongbox, die bei richtiger Einstellungen täglich sämtliche David-Archive sichert.

    Ich kann in zwei unterschiedlichen Installationen, die ich gerade überprüft habe, den Fehler NICHT nachvollziehen.
    Scenario: a) Windows 7 / IE10, b) Windows 8 / IE10. In beiden Fällen Stand ist der David-Stand: DVWIN32 12.00a 4472, DVAPI32 12.00a 0393.

    Allerdings achte ich immer darauf, dass der Cache des Webbrowsers auf max. 50 MB eingestellt wird und Löschen beim Beenden des Browsers angeklickt ist.
    Wenn der Webbrowser alte Cache-Inhalte enthält dann könnte die den beobachteten Fehler beim Anklicken einer zum Öffnen des Mailclient aktivierten Adresse auslösen.
    Anmerkung: auf beiden Rechnern läuft MS Office ohne Outlook. Der David-Client David wurde auf frisch installierten Rechnern eingerichtet.

    Beim InternetExplorer ist angehakt: Neue Versionen automatisch installieren.
    Kann also sein, dass Microsoft den IE10 bereits bezgl. des Fehlers gepatcht hat. (Stand: 10.0.9200.16540)

    1) Der Controller C4 ist laut Datenblatt für PCI-Steckplätze geeignet. Die Datenmenge die über 8 gleichzeitig betriebene ISDN-Kanäle läuft ist deutlich kleiner als die Datenmenge, die ein stabil laufender PCI-Slot normalerweise verkraftet. Die AVM C4 wurde 2004 hinsichtlich ihrer Eignung für David getestet. Ergebnis damals: uneingeschränkt geeignet.
    (siehe auch Tobit.Software Knowledge Base Artikel Q-100.399).


    2) Der recht teure Controller C4 verfügt über 4 S0-Anschlüsse. Pro S0-Anschluss sind zwei Kanäle möglich, sodass über diese Karte insgesamt bis zu 8 David-Ports parallel betrieben werden können. Die gewünschte Anzahl David-Ports benötigt COM-Port-Lizenzen.

    Soweit so gut. Allerdings hätte ich bei dem Gedanken, diese Karte einzusetzen, ein gewisses Unbehagen. Denn sie wird nicht mehr produziert. Bis Betriebssystem Windows 2008 R2 Server einschließlich ist das wohl kein Problem, denn die Kartentreiber sind im Serverbetriebssystem enthalten. Hinsichtlich Windows Server 2012 schweigen sich die Onlinemedien bis jetzt aus. -

    Wenn 4 David-Com-Ports genügen (also 4 ISDN-Kanäle, über die gleichzeitig Faxe empfangen und versendet werden) dann halte ich die Investition in einen Bintec RT1202 respektive fxConnect4 für sinnvoller. Denn dieses Gerät unterstützt Faxkommunikation auch für virtuelle Server und ist gleichzeitig eine sehr hochwertige Firewall für DSL.

    Die SMTP-Konfiguration erfolgt am besten unter
    Postman / Datenbanken / Sendemethode.

    Zur Eingrenzung von Fehlerursachen empfehle ich das in David integrierte Port-Tracing zu verwenden.
    Unter Konfiguration des Postman ist ein Tracing der zum SMTP-Server gehenden Signale auf Erweitert / Monitor Information möglich. Dazu sollten die Monitor Information zunächst auf Normal oder Erweitert eingestellt werden. Bei Bedarf lässt sich dieses Port-Tracing auch in eine Datei umleiten.

    Auch da ist einiges in Bewegung gekommen. Zum Beispiel ist die Webbox in der aktuellen Version merklich komfortabler geworden. Der Absender für über die Webbox verschickte eMails IST wählbar, wenn dem David-User im Dvise-Admin mehrere eMail-Adressen zugeordnet wurden.

    Aber sollten wir für ähnliche Dinge nicht lieber einen separaten Forum-Thread öffnen? Wir schweifen in unseren Antworten sonst zu sehr vom ursprünglichen Thema ab.