Beiträge von Arno

    Der Usenamen ist gleich der Site-ID. Diese wird im David-Client im Menüpunkt Site-Information angezeigt.
    Gleichzeitig entspricht das den ersten beiden Blöcken der Lizenzkarte des Kunden.
    Das Passwort ist der dritte Block auf der Lizenzkarte.

    Wurde das Passwort nicht geändert, dann ist es wie folgt zugänglich:
    David Administrator öffnen, links ganz oben auf David (Servername) klicken.
    Auf der sich öffnenden Seite mit den Systeminformationen gibt es den Link TSSM.
    Anklicken führt zur Seite Tobit Software Site Management und dort zum Menüpunkt Lizenzen.
    Da sind alle Lizenzen des Kunden in Klarschrift hinterlegt.

    barabas.
    Das ist richtig, aber ich bitte zu bedenken: Ein Update älterer Versionen sollte besser über den betreuenden Tobit-Partner eingesteuert werden. Der kann das Update freier kalkulieren. Obwohl der Tobit-Partner dabei mehr Geld aus der Marge erhält kann er das Update etwas günstiger anbieten.

    Ab Version 12 sind die Aktualisierungen starr an die Provisionsregeln der Partner gebunden.

    SiteCare ist ein Software-Pflegevertrag, bei dem Produktaktualisierungen und Anpassungen für neue Betriebssysteme vom Hersteller bereitgestellt werden.
    Da der Kunde bereits die V12 einsetzt lassen sich Aktualisierungskosten leicht auf ermitteln.

    SiteCare-Verträge gibt es mit monatlicher und jährlicher Laufzeit. Allerdings beträgt die Mindestlaufzeit drei Monate.
    Der Kunde kann auch auf den aktuellen Release-Stand mit einem Update ohne SiteCare aktualisieren. Letztendlich ist das eher Geschmackssache, was man auswählt oder eine Frage des aktuellen Angebots.
    Ausnahme sind Aktionsangebote die ein bis zweimal jährlich vom Hersteller angeboten werden.
    Nach Abschluss eines SiteCare-Vertrages stehen alle verfügbaren Aktualisierungen während der Laufzeit zur Verfügung.

    Im Moment tendiere ich eher dahin, den SiteCare-Vertrag zu empfehlen. Denn Mitte Januar wird Windows 10 an den Start gehen.
    Erfahrungsgemäß baut Microsoft soviel um dass Updates der david-releases nötig werden.
    Jetzt ein Update zu bestellen und dann im Februar schon wieder eines dürfte teurer werden als einen SiteCare-Vertrag abzuschließen.

    Was die technische Seite der Kundenbetreuung angeht empfehle ich Ihnen dringend, entweder im Rahmen einer Tobit-Partnerschaft selbst KnowHow-aufzubauen oder eine enge Zusammenarbeit mit einem erfahrenen Tobit-Partner oder -Administrator zu suchen. David setzt Netzwerk- und Firewall-KnowHow voraus. Vor allem wenn Remotefunktionen einzurichten und zu administrieren sind.

    Selbst auf die Gefahr hin dafür Buh-Rufe zu erhalten:
    Fritz!Card USB mit Vista-Treiber und Windows 2012 Server ist eine Bastel-Lösung mit unvorhersehbaren Folgen.

    1) AVM als Hersteller der Fritz!-Komponenten wird bei Störungen im Serverbetrieb keinerlei Support oder Gewährleistung geben. Die Fritz!Card USB ist nicht für den Einsatz im Serverbetrieb vorgesehen.

    2) Auch Tobit.Software wird sich wohl kaum in die Nesseln setzen und diese Lösung supporten.

    3) Vor der Funktion des Servers hängt die Produktivität des Betriebes ab! Mit Einsatz solch einer Bastellösung besteht immer die Gefahr, dass zu einem späteren Zeitpunkt aus Sicherheitsgründen ein Patch installiert werden muss, dass sich mit dem Vista-Treiber nicht verträgt. Vollständiges Serverstillstände oder "Hängen" wichtiger Dienste sind nach Installation nicht freigegebener Bastellösungen gar nicht so selten.

    Schon ein einziger Tag Ausfall eines wichtigen Servers kostet einen mittelständischen Betrieb normalerweise erheblich mehr als eine Bintec RT1202 einschließlich Installation. Und nach mehr als drei Tagen Stillstand der EDV sind die meisten Betriebe insolvent.

    Die Gerdes PrimuX ab PrimuX S0 E (Art.Nr. 2406) laufen stabil. Voraussetzung ist, das der PCI-Express Slot genug Strom liefert. Probleme hatte ich bei einem Dell Rechner. Denn nur im PCIe-8x Slot war die Stromversorgung ausreichend. Bei allen anderen PCIe-Slots brach im laufenden Betrieb die Faxüberragung ab.

    Falls einen Virtualisierung vorgesehen ist kommen die ISDN-Karten nicht in Frage. Dann sollte mit einem Bintec Multimedia-Gateway wie dem Bintec RT-1202 gearbeitet werden. Das Gerät ist auch für die David Voice-Funktionen uneingeschränkt geeignet.

    wieso ist das intuitiv nicht zu machen?

    Wenn alles intuitiv und ohne Lernerlebnisse abliefe, wovon sollten Trainer dann noch leben?
    Und wozu gibt es Schulen und Schulungen?

    Aber jetzt mal im Ernst: Gerade die Benutzerführung der StrongBox ist doch in den heutigen David-Versionen sehr für intuitives Arbeiten ausgelegt.
    Das einzige was der Admin einmal gesehen haben muss ist, wo er die StrongBox Images im Navigator findet.
    Findet er dort keine, dann gibt es entweder keine Sicherung oder er hat sich selbst das Recht zur StrongBox-Nutzung im Dvise-Admin genommen.

    Im Navigator sollte ganz unten unterhalb der Archive, "StrongBox Images" zu sehen sein.
    Dieses Verzeichnis sollte sich öffnen laasen. Darunter sind die erfolgten Sicherungen abgelegt.
    Falls die nicht sichtbar sind dann bitte mt einem Doppelklick auf die Sicherungsdatei [ Name zum Beispiel 2.0) ] die Sicherung mounten.
    Obacht, dieser Mount ist unter Umständen nur für den gerade eingeloggten User sichtbar.

    Die Unterverzeichnisse sollten exakt dem Inhalt des Navigators entsprechen.
    Das wiederherzustellende Verzeichnis auswählen und dann mit der rechten Maustaste "Ordner wiederherstellen" markieren. Es öffnet sich ein Kontextmenü.
    Darin Ziel und Optionen auswählen und auf Start klicken.

    Einzelne Dateien (eMails, Termine, Adressen) aus den Sicherungsordnern lassen sich per drag&drop wiederherstellen:
    Datei im StrongBox-Baum auswählen und kopieren. Zielverzeichnis in normalen Navigator-Baum auswählen und einfügen.

    Tipp: Im David Client gibt es rechts oben den Menüpunkt Hilfe / David Client Hilfe.
    Das Suchwort StrongBox bringt 13 Treffer mit Hilfetexten.

    "Temporär beschäftigt" ist oft eine Meldung, die auf eingeschaltetes Greylisting beim Empfänger hinweist.

    Aber bei einigen Providern wie 1und1 kommt es auch vor, dass Versenden mit einer dynamischen IP zu solchen Meldungen führt.
    Ein Benutzen des Tobit Mail Relay Servers hilft in dem Fall weiter.

    Eine Kontrolle oder Änderung von SMTP Host und Name des beim Postman eingetragenen Domain Name Server ist ratsam.
    Die Einstellungen sind auf der Seite [David admin / Postman / Generell] zu finden.

    Nach ersten Erfahrungen beschleunigt der Einsatz von SSD-Festplatten David sogar drastisch!
    Zumindest wenn Controller und CPU auf die Leistung des SSDs abgestimmt sind.
    Die SSD-Platte(n) eines Kommunikations- und Fileservers sollte für viele Schreibvorgänge ausgelegt sein.
    Das ist zum Beispiel bei den preiswerten EVO-Serien von Samsung nicht der Fall.
    Die sind eher für viele Lesevorgänge geeignet, wie sie zum Beispiel bei der Archivierung, in Online-Bibliotheken oder auch in Medienservern vorkommen.
    Sie sind ausgelegt für bis zu 600 TBW, also 600 Terabytes Bytes Written, übersetzt insgesamt 600 Terabyte geschriebener Daten bezogen auf die gesamte Plattenlebensdauer plus Reserve bei Normklima (23° C). Bei vielen kleinen zu schreibenden Dateien verringert sich dieser Wert. Und eine beständige Temperaturerhöhung bedeutet pro 10 Grad Celsius jeweils eine halbierte Lebenserwartung der Halbleiterbausteine von SSDs.


    Ausdrücklich für Dauerbetrieb und hohe Schreibraten ausgelegte SSDs von Samsung (Baureihe 845 DC Pro) sind in Terabyte-Größe im laufenden Jahr noch nicht lieferbar. Die aktuelle Obergrenze liegt bei 800 GB Kapazität. SSD Serverplatten dieser Serie und Größe kann ich ab Mitte Dezember 2014 liefern. Die kleineren 400 GB SSDs vom Typ Samsung 845DC Pro MZ-7WD800EW sind innerhalb eines Arbeitstages lieferbar. Beide Server-Festplatten können ab sofort über meinen Webshop oder telefonisch (02131-1515360) bestellt werden.

    Die hohen Durchsatzraten werden bei den Samsung 845 DC Pro-Serien kontinuierlich über Jahre gehalten, während SSDs der EVO-Serien schon binnen Jahresfrist Performanceeinbußen bei der Schreibleistung aufweisen können. Im Serverbetrieb rechtfertigt das die höhere Ausgabe für 845 DC - Pro Platten.

    Notfalls lassen sich die David-Daten bei 800 GB Datenbestand auf zwei oder drei kleinere SSD-Platten aufteilen. Das ist ohne Probleme über Betriebssystem-Funktionen steuerbar, benötigt aber sorgfältige Einrichtung. Es wird auch jeden Fall billiger als ein Tag Produktionsausfall.

    Hinweis für Forumsmitglied Joewol:
    Angesichts langsamer Datenzugriffe auf ihre bestehende David-Installation dürfte es sich lohnen, darauf einen vollständigen Defragmentierungslauf auszuführen. Er könnte bei 800 GB mehr als einen Tag dauern. Ausreichend Kühlung der Platten ist dabei ganz wichtig. Zeigt aber das Auslesen des Smart-Bereichs auch nur einer Platte schon Hinweise auf Verschleiß, dann sollte der Defragmentierungslauf vorsichtshalber unterbleiben.

    Die Investition in eine Server-geeignete SSD-Platte mit Auslegung für viele Schreibvorgänge erhöht die Produktivität von David-Anwendungen so sehr, dass ein Return of Investment innerhalb eines Zeitraums von weniger als zwei Jahren zu erwarten ist. Eine einzelne Server-geeignete SSD-Platte heutiger Bauart liefert mit passendem Controller die Daten weitaus schneller als jedes RAID5-System mit herkömmlichen Festplatten. Daneben braucht eine SSD-Server-Platte für die Bearbeitung der identischen Datenmenge mehr als 400-fach weniger Strom als eine herkömmliche Festplatte und dem entsprechend weniger Kühlung.

    OK, aber wenn ein Domaincontroller innerhalb von 10 Jahren von mindestens vier verschiedenen EDV-Betrieben gewartet wurde, dann sind einige nicht dokumentierte "Tretminen" im Betriebssystem anzunehmen. Ich denke da zum Beispiel an die Folgen wechselnder Virenschutz-Systeme, von denen noch ungelöschte Policies übrig sind. Ein Neu-Aufsetzen der Domäne halte ich dann beim Serverwechsel für sehr empfehlenswert. Ich halte das neu-Aufsetzen der Domäne vor allem dann für sinnvoll, wenn es beim Server-Betriebssystem eine Virusinfektion gegeben hat. Moderne Schadcodeprogramme verändern gezielt Policies und Schutzeinstellungen. Diese Veränderungen alle zu finden wird kaum möglich sein. Wer aus Zeitnot oder Sparsamkeit eine Servermigration vornimmt muss sich bewusst sein, dass er bei der Migration zumindest ein Teil der vom Schadcode veränderten Einstellungen mit überträgt. Der neue Server ist dann von Anfang an anfällig für neue Schadcode-Infektionen.

    Werden durch den Neuaufbau einer Domäne die Client-User gezwungen, ihre Daten einem neuen Login zuzuordnen, dann hat das sehr vorteilhafte Effekte:
    Denn bei den PCs kleiner oder mittelständischer Unternehmens ist davon auszugehen, dass sich im Laufe von Jahren etliche Botnetz-Viren und ähnliche Nettigkeiten in den Benutzerverzeichnissen eingenistet haben. Die User müssen nicht mal eMail-Nutzung betreiben. USB-Slots, DVD-Laufwerke oder Internetverbindung sind als Einfallstor völlig ausreichend.
    Wenn nun die Benutzerverzeichnisse dieser PCs nach Kopie benötigter Daten sorgfältig gelöscht werden, dann sind anschließend zumindest die Dateien aus den Temp-Verzeichnissen oder heute aus den Application Data Verzeichnissen gelöscht. Und genau darin verstecken sich die meisten Adware-Programme und Trojaner. Bis jetzt nistet sich nur ein kleiner Teil solcher Schadcode-Programme versteckt ins Betriebssystem ein.

    Kaum ein Mittelständler und fast gar kein Kleinbetrieb betreibt genug Aufwand, um sich vor Botnetz-Viren, Adware-Programmen und Trojanern zu schützen.
    Und 100%-gen Schutz gibt es gar nicht. Schon ein einziger mit einem Botnetz-Virus infizierter PC kann genügen, um über's LAN in kurzer Zeit den ganzen Betrieb anzustecken.

    Der Microsoft-Suppot sagte zu einer Infektion mit einem Erpresser-Virus sinngemäß folgendes:
    "Sie haben keine Chance, solche Viren vollständig aus einem System zu entfernen. Die verändern Betriebssystem-Dateien meistens so, dass trotz aufwendiger Bereinigung des Systems neue Viren nachgeladen werden. Die einzige Möglichkeit zur Behebung des Schadens ist eine vollständige Neuinstallation. Vermeiden Sie dabei die Nutzung von Tools wie Windows Easy Transfer. Die Viren-Grundbestandteile würden sonst mit kopiert."

    In den 15 Jahren als Systemmanager CATIA und Nemetschek Kompetenzpartner habe ich viele Vorteile von Filesystemen kennengelernt.
    Sie sind schnell, wenn die zu bearbeitende Datenmenge beim Aufruf angegeben werden kann. Bei Allplan FT wurde nur ein Teilbild (Layer) geöffnet, während Systeme wie AutoCAD, aber auch IDEAS oder UG immer fast das ganze CAD-Modell beim Start des Programms öffnen und handlen mussten. Folglich waren CATIA (auch ein Filesystem) und Allplan in der Arbeitsgeschwindigkeit vom Start an schneller. Auch das Speichern ging extrem flott. Hakelig wurde es hingegen beim Datenaustausch und beim Sichern der Daten. Beides war und ist im Vergleich mit den Datenbank-basierenden CAD-Systemen ziemlich umständlich.

    Aber wo stehen wir heute, wenn wir Kommunikationssysteme betrachten?
    Wie steht es um die Stärken und Schwächen heutiger Filesysteme, wie sie David nutzt?
    Und wo kann im Vergleich ein Datenbank-basierenden System seine Stärken ausspielen, und wobei hapert es, wenn wir Datenbanken nutzen?

    Ich bin auf Eure Antworten gespannt.

    Lässt sich ein Exchange Server mit David Client Sichtmasken betreiben?
    Geht das und wenn ja, wie?

    Grund für meine Anfrage:
    1) Outlook ist mir einfach zu langweilig und unübersichtlich vom Look & Feel.
    Aber ich werde mich in Kürze intensiv mit Exchange befassen, weil mit dem All-IP-bedingten Rückgang der Faxnutzung die David Software für viele Kunden uninteressant wird:
    "Veraltete Technologie, teuer, umständlich, aufwendig zu administrieren, zunehmend problematisch beim Mail-Versand"
    Diese Argumente sind längst nicht mehr alle wegdiskutierbar.

    2) Gleich mehrere mittelständische Firmen, deren Softwareinstallationen ich seit Jahren supporte, teilten mir mit, dass sie im nächsten Jahr zu Exchange zu wechseln. Für deren Mitarbeiter wäre es recht praktisch, wenn sie übergangsweise den gewohnten Client-Bildschirm noch weiter nutzen können.

    kiste hochstufen (ja, adprep dauert 3min), warten bis gesynct ist, rollen umziehen, licensing server ändern, DNS im DHCP server ändern und fertig. dauert 15min bei 2 servern.

    Das möchte ich so nicht unkommentiert stehen und gelten lassen.
    Denn in der täglichen Praxis sieht es meistens anders aus. Auf dem alten Domaincontroller sammeln sich im Laufe der Jahre nicht nur Daten, sondern auch jede Menge Fehler. Die werden bei einer Migration zu einem neuen Server mitgeschleppt. Da kann es locker mal zwei Tage Arbeit erfordern, bis die Liste der Fehlermeldungen vernachlässigbar klein geworden ist.
    Ich arbeitete bei einigen Installationen mit einer Firma zusammen, die Software für Apotheken liefert und wartet. Die Erfahrungen deren EDV-Teams bezüglich der Server-Migration von W2003 nach W2008 waren so schlecht, dass sie grundsätzlich keine mehr vorgenommen haben.

    Dass ich immer noch PDC zum Domaincontroller sage liegt einfach an einer Gewohnheit aus nunmehr 15 Jahren PDC, BDC, SDC und DC, AD und ...
    Namen sind in der EDV-Welt recht kurzlebig. Irgendwann interessieren die immer neuen Namen für minimale Unterschiede einfach nicht mehr, solange im Kollegenkreis sowieso jeder weiß, was gemeint ist.
    Aber ich werde mich diesbezüglich vielleicht bessern. Denn in den nächsten Tagen werde ich mich mal intensiv mit Microsoft Azure, der Migration von W2008 zu W2012, Office 265 und mal zur Abwechslung Exchange auseinandersetzen. Und spaßeshalber mal eine AD-Migration zwischen zwei virtuellen Servern durchziehen.

    Azure? Noch nie gehört? Das ist aber eine Bildungslücke. Ich sehe da einige Marktchanchen für Kommunikationsserver in der Wolke. Wozu Geld für lokale Hardware ausgeben, wenn die Mitarbeiter eines Betriebes sowieso fast alle irgendwo in der Welt unterwegs sind? Da wäre es ja Stromverschwendung, die Hardware lokal zu betreiben!

    Ja, genau das meine ich.

    Zunächst eine vollständige neue David-Installation auf dem neuen Server vornehmen.
    Auf dem alten Server die Papierkörbe leeren.
    Alle User anlegen und deren Funktion festlegen (Administrator, einfachr User, DVG-Member usw.)
    Dann die Sicherungsdatei auf den neuen Server kopieren und mit Doppelklick darauf zuordnen.
    Alle nötigen Verzeichnisse wiederherstellen (User-, Gruppen, Grabbingserver usw.)
    Bei den Kalender prüfen, ob die Wiedervorlage und der Besitz der Einträge noch in den Zuordnzung passt.
    (Falls die Zuordnung nicht passt, bitte kurze eMail. Denn auch dafür gibt es eine Lösung).

    NoHopeNoFear: Er will ja gerade den PDC löschen respektive abschalten. Dann gibt es keinen Domaincontroller mehr in der Domäne.

    Neuanlage der Domäne auf dem David-Server als Primary Domain Controller ist ein Weg, hochstufen des David-Server zum Secondary Domain Controller der zweite Weg.
    Zu beachten dabei ist, dass der Windows 2003 Server noch ein 32-Bit System ist. Es wird dafür also der etwas aufwendige Weg einer Migration des DomainControllers in eine 64 Bit-Umgebung mit ADPREP32 und einigen dazugehörigen Utilities nötig. Sobald der David-Server als SDC mit allen Benutzerkonten synchronisiert ist kann er zum PDC hochgestuft und dann der alte Server abgeschaltet werden.

    Wenn weniger als ~ 5 User in der Domäne laufen dann ist die Neuanlage des PDC mit neuer Domäne name-neu.local der einfachere Weg. Vorher sollten auf den Clients die persönlichen Daten der Domänen-User gesichert werden.

    Das "Einfach mal eben alles auf einen anderen Server kopieren" ist so ziemlich das Schlimmste, was man einer David-Installation antun kann.
    Der Serverumzug sollte entweder mit einem David-Migrationstool erfolgen oder via StrongBox.
    Alles andere wird zu Fehlern führen, die mehrtätige Nacharbeit mit Arcutil nach sich ziehen kann.

    Das Migrationstool besitzen die meisten Tobit-Partner.

    Wenn ich den Text eingangs richtig verstanden habe, dann wird doch der derzeitige Primary Domain Controller (PDC) abgeschaltet. Wenn der W2008 Server seine Active Directory Struktur nicht mit dem PDC synchronisiert hat [also als Backup Domain Controller fungierte], dann gibt es nach dem Abschalten keine funktionierende AD mehr. Die Clients haben zwar die Usernamen noch zwischengespeichert, aber nach einem Wechsel zwischen wie Anmeldevorgängen kann "Ende" sein. Da wird eine neue AD-Struktur benötigt.

    Der Memberserver könnte die Usernamen allerdings zwischengespeichert haben, aber sicher bin ich mir da nicht. Ich müsste erst mal in einer Testumgebung ausprobieren, was bei so einem Wegfall des PDC noch da ist. Aber da fehlt mir momentan doch etwas die Zeit zu, weil die neuen Azure-Funktionen der recht stürmisch aufziehenden Microsoft Wolken ja auch erst mal gelernt werden müssen.

    Mit etwas Glück kann es vorübergehend genügen, das Verzeichnis \david\apps\webbox aus der letzten Datensicherung wiederherzustellen.

    Aber das wird keine Dauerlösung sein wie ich aus eigener Erfahrung weiß.
    Dieses Webbox-Verzeichnis und wahrscheinlich auch der Inhalt von \\servername\David\Archive\SYSTEM\DAVID\Access wird aus einer frischen Umgebung zu ersetzen sein.
    (Defekte Verzeichnisse bitte nicht löschen, sondern nur umbenennen !!! )

    Eine zusätzlich ausgeführte InterCom-Anfrage an den Tobit-Supprt kann nicht schaden. Da das Problem öfter auftrat gibt es zu obigem Weg vielleicht noch Varianten.