Beiträge von graef-edv

Es scheint sich hier um einen konzeptionellen Fehler zu handeln, der verschiedene Dienste betrifft. Ich habe einen Kunden, bei dem ich die ISDN-TLD regelmäßig neu starten muss, damit die Faxe ankommen, bei einem weiteren Kunden ist es der Grabbing-Server, bei einem anderen der MA-Server. Das Ganze scheint auch nur Schubweise aufzutreten, nach einigen Wochen kehrt wieder Ruhe ein und der Neustart-Task kann wieder entfallen.
Ich habe teilweise auch schon mit Files=xx Logdateien geschrieben, konnte aber daraus auch nichts erkennen. Da der Fehler immer nur einzelne Installationen betrifft konnte auch der Tobit-Support in der Vergangenheit den Fehler nicht reproduzieren.

Jörg.

Das Problem dabei ist, dass sich alle Parameter geändert haben, auch der Servername. Ich müsste das dann auch noch mit Arcutil gerade ziehen und vermute, dass mir dort die gleichen Fehler begegnen werden, wie beim DvMigrate.

Weiss den jemand, ob man DvMigrate überhaupt zweimal hintereinander laufen lassen kann, oder ob ich alle Benutzer auf einmal umziehen muss? Ist ein inkrementelles Migrieren so überhaupt möglich? Ich muss im zweiten Schritt noch einen anderen Standort in diese Installation integrieren. Das sind allerdings nicht so viele Benutzer, so dass ich das wahrscheinlich per Strongbox übernehmen werde.

Weihnachtliche Grüße aus Vellmar,

Jörg.

Hallo,
ein kurzer Nachtrag:

Im Migrationsprotokoll habe ich etliche Fehlermeldungen vom Typ:

ERROR : 00:50:03 | UpdateSR=> Remove invalid Archive path for 'zzz_AusgeschiedeneMitarbeiter': \\SRV-ALT\DAVID\ARCHIVE\USER\75
Errorcode: 0x00000002 (2)
Das System kann die angegebene Datei nicht finden.

Hierbei handelt es sich um Fehler im TAS, die der Purging-Report vorher nicht gefunden hatte.

Sowie etliche Positivmeldungen:

UpdateUsersArchiveDIR: POS=7, Subject: Vorname Nachname
UpdateUsersArchiveDIR: PDC=\\SRV-NEU, UseDomain=1, Server=\\SRV-NEU, NetUserGetInfo=0
UpdateUsersArchiveDIR: SetSRSubject(Vorname Nachname)

DvMigrate scheint also die Benutzer korrekt zugeordnet zu haben, trotzdem stehen im Administrator unter Benutzer die alten Benutzernamen; bei dem probehalber migrierten Benutzer stand dort korrekt der neue Name.

Any idea?

Jörg.

Nein, leider per IMAPs und externem SMTP. Die Anbindung des MacOS Sierra Mailclients an Tobit David ist mir leider nicht gelungen. Irgendwie will dieser dusselige Client alles selber machen und scheitert dabei.

Was passiert denn, wenn Du den Dateisystemnamen in geschweiften Klammern mit angibst?

Also neuen Ordner erstellen und z.B. Test{Test} benennen.

Ich würde aber auch dringend empfehlen, die Archive.dir zu prüfen und zu reparieren. Da stimmt was nicht.

Jörg.

Ich habe jetzt bei einem Kunden Thunderbird für MacOS installiert. Der Kunde ist super zufrieden, läuft alles tadellos mit David zusammen..

Hallo,

Zur Anzeige von Fehlern im TAS (Tobit Archive System) kann ein Mail-Report aktiviert werden.
Hierzu muss in der DAVID.INI die Zeile

MSGMAILNAMES=ADMIN@EXAMPLE.NET

eingefügt werden.

Hierbei musst Du natürlich Deine Mailadresse einsetzen.

Jörg.

Hallo, ich habe das auf verzögertem Start stehen. De Dienst läuft ja auch zunächst (teilweise tagelang) korrekt. Der Fehler tritt plötzlich im laufenden Betrieb auf, ohne dass es z.B. zu einem Neustart kam.

Hallo,

ich bin heute Nacht mit dem Migrationstool grandios gescheitert. Vielleicht kann mir hier jemand helfen:

Situation: Auf dem alten Server mit Windows 2008R2 läuft ein David Sitecare mit aktuellem Patchstand und 35 Benutzern. Da sich die Betriebsstruktur des Kunden geändert hat wurde ein neuer Server angeschafft und ein Server 2012R2 installiert, wobei eine komplett neue Domänenstruktur erstellt wurde. Die alte Domäne passt inzwischen in keiner Weise mehr zur Situation des Kunden, die Schreibweise der Benutzernamen wurde in diesem Zuge vereinheitlicht und einige "alte Zöpfe" abgeschnitten. Auf dem neuen Server wurde ebenfalls die aktuelle Version von David Sitecare installiert.

Nachdem ich gestern probehalber einen einzelnen Benutzer mit der aktuellen Version von DV-Migrate umgezogen hatte und dabei per "Zuweisen" den alten Benutzer auf den neuen zugewiesen habe lief alles einwandfrei. Heute Nacht habe ich dann mit gleichen Einstellungen in DV-Migrate die restlichen Benutzer umgezogen. Der Job wurde heute Nacht mit einer Erfolgsmeldung abgeschlossen.

Mein Problem: Der gestern probehalber umgezogene Benutzer ist nach der Migration verschwunden. Weiterhin sehe ich im David Administrator auf dem neuen Server alle Benutzer des alten Servers in der alten Schreibweise, sie sind also nicht den aktuellen AD-Konten zugeordnet. Ich sehe ebenfalls die Benutzer bei denen ich "nicht migrieren" ausgewählt habe. Es sieht so aus, als ob die USER.DAT einfach so herüber kopiert wurde.

Habe ich hier irgendeinen Kardinalfehler begangen? Kann man überhaupt das Migrationstool mehrfach hintereinander für einzelne Benutzer anwenden?

Hat hier jemand einen Tipp für mich oder eine alternative Strategie? Der Robocopy/ArcUtil Ansatz kommt leider nicht in Frage, da z.B. etliche ausgeschiedene Benutzer nicht umgezogen werden sollen und viele Verzeichnisstrukturen geändert werden sollen.

Ich möchte ungerne die Strongbox-Variante mit manuellem Umkopieren der Mails verwenden, da ich Weihnachten eigentlich lieber mit meiner Familie als mit dem Server verbringen möchte.

Verzweifelte Grüße,

Jörg.

Moin.

Wenn es ein Zertifikatsproblem wäre, dann würde es ja nicht tagelang laufen und nach dem Neustart sofort wieder funktionieren.

Jörg.

Hallo,

ich hatte es ja in einem anderen Thread schon einmal angesprochen, jetzt habe ich wieder den Fall gehabt, dass die Webbox "hing", ohne dass beim Kunden die Eskalationsstufe auf Emergency stand und ich es mir einmal näher anschauen konnte.

Der Dienst lief, die Webbox hat nicht auf HTTPS reagiert. Im Trace der Webbox stand:

WebBox Active
(AC) Certificate state: \\sbserver\david\apps\webbox\code\wbcert.pem
WebBox Second Port Active
(AC) Certificate state failed!
Using TLS file (\\sbserver\david\apps\webbox\code\wbcert.pem)
Error loading certificate! TLS not available (\\sbserver\david\apps\webbox\code\wbcert.pem)

Nach dem Neustart der Webbox sah es dann so aus:

(AC) Subject CN: kunde.domain.de
(AC) Valid from: Sun, 18 May 2016 11:26:48 GMT
(AC) Valid to: Sun, 26 May 2026 11:26:48 GMT
(AC) Days left: 3455
Using TLS file (\\sbserver\david\apps\webbox\code\wbcert.pem)
TLS initialisation successful
WebBox SSL Active
WebBox Second Port Active

Obwohl sich am Zertifikat nichts geändert hat scheint die Webbox dieses plötzlich und bis zum Dienstneustart nicht mehr zu mögen.

Hat da jemand eine Idee?

Jörg.

Erstelle doch mal einen Purging-Report und schau, ob da was in der TAS-Struktur nicht stimmt.

Jörg.

Schau doch mal mit einem Texteditor in die Dateien in den beiden Ordnern rein.

Vielleicht kannst Du ja aus den Empfängern/Absendern etwas herauslesen. Manchmal sind auch wild gewordene Auto-Reply-Loops ein Problem.

Jörg.

Hast Du mal geprüft, ob Deine Uhrzeit exakt stimmt?

Da von diesem Problem (Dienst läuft laut Taskmanager, arbeitet aber nicht) bei mir verschiedene Kunden bei verscheidenen Diensten betroffen sind, könnte es sich eventuell auch um ein Problem der internen Lizenzprüfung handeln.

Seit meinem Problem mit der abgelaufenen Sitecare-Lizenz bin ich da etwas skeptisch geworden.

Jörg.

Hallo,

jetzt stehe ich vor der gleichen Problematik: Der Kunde möchte ab sofort das vergünstigte Update auf Sitecare nutzen, den Server darf ich aber erst im neuen Jahr von 2003 auf 2012R2x64 updaten.

Kann ich von David Zehn auf das aktuelle Sitecare Package auf einen Server 2003 x32 bedenkenlos updaten?

Jörg.

Das schönste wäre eine klassische und zeitnahe Kommunikation per E-Mail mit einer Ticket-ID im Betreff. So wie das früher mal gut funktioniert hat.

Aber wir sind ja leider nicht bei "Wünsch Dir was".

Jörg.

... schon versucht, aber wahrscheinlich müsste ich dafür ein kostenpflichtiges Priority-Ticket aufmachen. ;p

Hallo,

wegen eines Problems mit meinem E-Mail-Client unter Android habe ich auf meinem Galaxy S5 das ActiveSync-Konto und die Daten des E-Mail-Clients gelöscht, und möchte das Konto neu einrichten. Bei der manuellen Konfiguration komme ich bis zu der Meldung "Eingehende Servereinstellungen überprüfen...", ab hier passiert nichts mehr. Vorher lief alles einwandfrei.

Trage ich statt der Domain mail.kunde.de die IP-Adresse ein, so bekomme ich zwar eine Zertifikatwarnung, der Sync funktioniert aber. mail1.kunde.de ist ein CNAME-Record, der auf einen StratoDynDNS-Account mail1.kunde.de zeigt. Dieser zeigt dann auf die IP-Adresse. Mit mail1.kunde.de bekomme ich zwar eine Zertifikatswarnung, der Sync funktioniert aber.

Gibt es bei EAS ein Problem mit CNAME-Records?

EDIT: Nach der erfolgreichen Einrichtung des Kontos kann ich dann wieder auf die mail.kunde.de (CNAME) zurück stellen, dann funktioniert es weiter. Das Problem scheint auf der Android-Seite zu liegen.

Ich muss die Aussage bezüglich des Supports doch noch einmal etwas entschärfen. Das Problem wurde natürlich an die Entwicklung weiter gegeben. Der Hinweis bezüglich der Neuinstallation war eine Empfehlung zur schnellen Problemlösung. Ich habe den Anruf nicht persönlich entgegen genommen, es wurde mir lediglich so von einem meiner Mitarbeiter ausgerichtet.

Trotzdem ist die Erreichbarkeit des Supports, insbesondere in unternehmenskritischen Situationen, nicht wirklich lobenswert. Trotz Priority-Ticket ging es einfach nur schleppend voran; die Antworten hier im Forum waren immer schneller gewesen als die des Supports. Ich denke, dass es bei Tobit insbesondere bei der Unterstützung der Partner weiterhin Verbesserungsbedarf gibt, aber das wurde in anderen Threads ja schon hinreichend diskutiert.

Jörg.

So wie es ausschaut ist mein Problem inzwischen gelöst.

Nachdem ich wie oben beschrieben die Lizenz erneut eingetragen habe hat mir der Service-Layer keine Mails bezüglich der abgelaufenen Lizenz mehr geschickt, im Trace der Webbox erschien jedoch immer noch die Meldung bezüglich der ungültigen Lizenz. Habe ich die Lizenz im Client verifizieren lassen, war sie gültig, der Code wurde ohne Fehlermeldung übernommen.

Heute habe ich von Tobit dann die Nachricht erhalten "In unserer Testungebung funktioniert Ihre Lizenznummer einwandfrei, wir können Ihnen nicht weiter helfen. Bitte installieren Sie neu."

Letztlich gelöst haben wir das Problem, indem wir die Systemuhrzeit des Servers exakt eingestellt haben, die AD-Zeit ging um ca. 5 Minuten nach. Seitdem funktioniert das System wieder einwandfrei.

Meine Vermutung: Bei der Aktivierung der Lizenz findet eine zertifikatbasierte Kommunikation mit dem Tobit Lizenzserver statt, bei der es keine Zeitdifferenzen geben darf. Vor dem Ablauf der Lizenz hat die Zeitdifferenz AD zu Weltzeit aber scheinbar keine Rolle gespielt.

Jörg.