Master Template Verwirrung

    Hallo Zusammen,


    ich hab mal eine Frage zu den Master Templates:


    Situation: 1 Administrationsserver (6.5.2), auf dem die Templateänderungen vorgenommen werden.
    4 Mailserver, die je zu zweit im Cluster laufen (je 1x 6.5.1 und 1x 6.5.2)


    Vor dem Upgrade auf 6.5.2 wurden (so glaube ich) die Master-Templates, wenn ich sie auf dem Admin-Server verändert habe, bzw. neue angelegt habe, auf alle Server der Domain (automatisch) verteilt.


    Nun funktioniert dies nicht mehr...
    Einige User haben plötzlich (mittem am Tag) Probleme mit Ihren Mail-DB (z.B. Standardmaske wurde nicht gefunden), die sich durch ein Update der Gestalltung vom Admin-Server beheben lassen.


    Fällt Euch zu diesem Phänomen irgendetwas ein???


    Wie sollen Master-Templates eigentlich wirklich funktionieren???



    Danke


    Norbert äh... Codec

    hallo,


    wir haben eine ähnliche umgebung. für die replikation vom adm server auf die mail-server musst du ein verbindungsdokument haben der die schablone repliziert. sonst geht es nicht von alleine.


    die meisten probleme bei uns mit dem master template liegen am client, cache.ndk. wenn der cache gelöscht wird und client neu gestartet wird hilft das oft.


    die idee des master templates ist dass nicht jede mail-db alle gestaltungselemente drin hat sondern nur links auf die schablone auf dem server. die design task in der nacht ersetzt die elemente durch links wenn du SCT einstellst. update der gestaltung nützt bei uns nichts, da es ja auf dem mailfile nichts zu aktualisieren gibt.


    bei grösseren problemen wechseln wir auf eine normale mail schablone und dann wieder auf die master schablone zurück.


    Björn

    Bei SCT-basierten Datenbanken (dt. "Zentralschablonen") werden in den davon abgeleiteten DB's (wie schon erwähnt) nur Links auf die jeweiligen Designelemente verwaltet.


    Bei jedem Öfnen eines Designelements schaut der Client zuerst in seinen Cache, ob das Element bereits dort liegt. Wenn ja, dann schaut er als nächstes (in der Zentralschablone) nach, ob sich das Element seit dem Cacheeintrag geändert hat. Wenn nicht wird das Element aus dem Cache heraus verwendet, wenn ja dann wird das Element neu in den Cache übertragen und danach geöffnet.


    Das Problem hierbei liegt meist in Kombination mit Updates und Replikation und den mehrfach verwendeten Cache-Mechanismen.


    Um das Ganze zu verdeutlichen:


    I.) SCT wird erstmalig eingerichtet:
    - Design Task löscht alle Desinelemente aus den DB's und stellt stattdessen Platzhalter mit den ID's der Designelemente aus dem SCT ein.
    - Client cacht diese Platzhalter UND die daraus resultierend geladenen Designelemente.



    II.) Admin-Server erhält neue Designelemente via Upgrade:
    - Admin-Server repliziert neue Designelemente auf den Cluster (die dortigen Designelemente erhalten damit neue NoteIDs, die alten Elemente werden gelöscht).
    - Mail-DB bekommt davon nichts mit da nur Platzhalter verwaltet werden.
    - Clientcache verweist auf Platzhalter die wiederum aber auf nicht mehr vorhandene Designelemente des SCT verweisen -> Folge: Problem


    Theoretisch müßte der Designtask die Platzhalter ersetzen, tut er aber eben nur theoretisch... Praktisch klappt das nur bei wenigen Datenbanken. Könnte eine Server-Cache-Kombination sein die das Problem verursacht.


    Dauerhaft lösen läßt sich das Problem nur indem man entweder den Design-Task oder noch besser den Convert-Task nach jedem Upgrade der Schablone anweist, die Platzhalter in den SCT-Basierten DB's neu zu erzeugen (eigene nachträgliche Änderungen im Design sind von dem Problem nicht betroffen da sich die IDs der Elemente dabei nicht verändern).


    load convert directory\*.nsf mastertemplatename mastertemplatefilename


    (man ersetzt sinngemäß das design mit sich selbst...)


    Übrigens: Die Meldung "Vorgabemaske nicht gefunden" kann auch bei einer mehrsprachigen Schablone dadurch hervorgerufen werden, daß das englische "Memo"-Form diese Eigenschaft hat und die beim Nutzer eingespielte deutsche Maske demzufolge nicht. Das passiert häufig wenn man beim Languagepack anstatt "Sprache ersetzen" die Option "Sprache hinzufügen" gewählt hat.

    Hallo Carsten,


    mal wieder eine lange Antwort in gewohnter Qualität :) Danke schon mal dafür.
    Das heißt dann aber, dass ich besser bei Problemen komplett auf die Zentralschablonen verzichte und dafür in Kauf nehme, dass das Template halt bei allen Datenbanken komplett in der DB gespeichert wird. So kann ich dann doch den Ärger vermeiden, oder??
    Dieses Problem hat nämlich bei den Kollegen, die auf dem einen Mailcluster arbeiten zu einem Haufen Verwirrung/Ärger geführt, der gegen den Mehrverbrauch an Platz aufgerechnet werden muß...


    Ich denke ich werde dann mal die Templates zu ganz normalen Templates machen und die dann auf die Mailserver verteilen.


    Merkt der Design-Task diese Änderung, oder muß ich die dann nochmal explizit angeben??


    Danke nochmal


    Norbert äh... codec

    Das EIN oder AUSschalten des SCT sollte immer mit dem convert passieren. Der Designtask erkennt leider nicht immer zuverlässig alle Änderungen. Auch werden diese im Cluster eher schlecht als recht repliziert.


    Ich würde also erst zentral SCT abschalten, dann die Schablone auf alle Server replizieren, die Schabloneneigenschaft SCT auf allen beteiligten Servern einzeln kontrollieren (SCT-Flag wird nämlich normalerweise nicht repliziert, könnte also sein daß es überall separat ausgeschaltet werden muß trotz Cluster).


    Anschließend auf einem Server den Convert laufen lassen und danach per Replikator die Änderungen sicher zwischen allen 4 Servern verteilen (nicht auf Cluster verlassen).


    Der Aufwand ist also der gleiche, egal ob du SCT nur aktualisieren oder abschalten magst *g*