Posts by s1n88

    Liebe Community,
    ich habe mir das Quicktext Pro Anhänge Problem heute mal angesehen. Es scheint so, dass die Funktionen veraltet waren.
    Ich konnte den Code so umschreiben, dass es nun wieder funktioniert!


    Interessierte Pro-User dürfen mich gerne per PN kontaktieren.
    Danke an SusiTux für die Info bzgl. Codeveröffentlichung.

    Ich stehe leider vor dem gleichen Problem!
    Auch wir wollten Quicktext Pro wegen der Anhänge nutzen, aber es klappt leider nicht. Auch wenn es seit 15.07. ein neues Update auf Version 0.9.11.6 gab - Der Entwickler meldet sich nicht ...
    Ich habe zwar gelesen, es gab ein Problem mit dem Encoding der XML-Datei, aber genau das Problem soll nun in der neusten Quicktext Version behoben sein und auch der Workaround brachte keine Besserung bei dem Problem mit den Anhängen.


    Hat jemand eine Lösung? Ich probiere schon das Ganze zum Laufen zu bekommen, aber bisher ohne Erfolg.
    Kennt jemand einen Workaround?

    Kannst du den Loadbalancer so einstellen, dass der Mailserver fix über eine definierte Leitung (die mit dem dicksten Upstream) erreicht

    Ja, das können wir und haben wir auch schon eingestellt. Ob ich nun alle Verbindungen zum Mailserver über die dicke Leitung schiebe oder den Loadbalancer sage er soll die Verbindung über die 3 Leitungen teilen bringt leider nichts - Wir konnten keine Verbesserung feststellen. Derzeit ist die Regel allerdings aktiv, sodass Mailserververbindungen über die dicke Leitung gehen.


    Ich konnte allerdings das "Anhänge Problem" wohl lösen. Es wurden bei uns ja nicht immer die Größe der E-Mail Anhänge angezeigt, worauf dann das Antworten nicht richtig funktionierte.
    Dies konnte ich mit zwei Einträge in der Konfiguration beheben, wenn auch eher unschön :D


    Code
    defaultPref("mail.imap.fetch_by_chunks", false);
    defaultPref("mail.imap.mime_parts_on_demand_threshold", 50000000);

    So ganz genau steige ich da nicht durch, aber es hat wohl was mit dem E-Mail Abruf zutun bzw. wie Thunderbird die Größe ausliest. Auf jedenfall musste ich den ersten Befehl deaktivieren und mit dem zweiten Befehl definiere ich die Größe. Ich habe sie nun auf knapp 50MB gesetzt, damit auch auf E-Mails mit großen Anhängen (Und ja, einige sind so krass und verschicken sowas mit E-Mails ...) erfolgreich geantwortet werden kann.
    Wenn die Größe z.B. auf 3MB gesetzt habe, so wurde mir die Größe der E-Mail Anhänge bis 3MB erfolgreich angezeigt. Bei größeren E-Mails kam dann wieder "Größe unbekannt".
    Daher hatte ich es jetzt auf 50MB gesetzt, um fast alle E-Mails zu erreichen. Bisher auch keine Beschwerden - Seit 2 Tagen bei uns aktiv.


    Wer eine schönere Lösung kennt, gerne her damit :)
    Mich würde allerdings mal interessieren, wodurch das Problem entsteht - Ich meine gelesen zu haben, dass es ggf. am Mailserver liegt, der TB keine Größe der Anhänge mitteilt?! Weiß da jemand was genaues? wie das alles z.B. abläuft?

    Es ist das genau das Konto, welches auch einen GnuPG-Schlüssel hat - @s1n88 setzt ihr Enigmail ein?


    Nein, setzen wir nicht ein.


    Wir haben zwischenzeitlich eine Systemumstellung im Haus durchgeführt (Neue Samba4 Domain) und im Zuge dessen auch Änderungen an TB vorgenommen. Und zwar haben wir jetzt das Mailcaching abgeschaltet, sodass nun direkt auf dem IMAP-Server gearbeitet wird. Sprich bei jeder E-Mail die angeklickt wird, wird auf dem Server zugegriffen. Es landen nur noch die Kopfzeilen im TB-Profil.
    Wie ich feststellen musste, läuft das leider nicht gerade viel besser - Anfangs gabs starke Probleme mit Anhängen, da dort immer keine Größe angezeigt wurde. Dies hängt wohl mit dem Mailserver und den TB Einstellungen zusammen. Wir haben TB nun gezwungen, selbst die Anhang Größe zu analysieren, sodass nun endlich die Größen angezeigt werden. War das nämlich nicht der Fall, konnte auf eine E-Mail mit Anhängen nicht geantwortet werden - Wieso auch immer ... es wurde keine Signatur mehr angezeigt und das Senden schlug fehl, indem der Sendebalken unendlich lang durchlief ... Aber das konnten wir nun fixen.
    Trotzdem passiert es ab und zu, dass E-Mails nicht richtig geladen werden und man erst wieder eine andere anklicken muss, damit die andere geladen wird. Sehr verwirrend alles.


    Das eigentliche Problem, dass manchmal E-Mails nicht rausgehen (besonders mit Anhängen) haben wir aber immer noch ... Ich finde einfach keine eindeutige Antwort auf das Problem.
    Manchmal habe ich schon unseren Router (Loadbalancer mit 3 Internetleitungen) in Verdacht - Als wenn dieser einfach für diesen Client dann keine Verbindung zum Server aufbauen will oder die Session sich dort aufhängt.


    Achja, bei uns tritt das Problem bei ALLEN Clients auf und nicht nur bei einem Konto ... Allerdings auch nicht ständig ... Manchmal hat ein Kollege ein paar Tage Ruhe und dann hat er mal wieder das Problem - Sehr sehr merkwürdig alles ...

    nicht ein wenig unterdimensioniert unter Anbetracht dessen:


    Hey Ulrich,
    ja das klingt in der Tat merkwürdig, ABER wir wissen leider nicht zu 100% was TB/Dovecot oder Postfix da veranstalten. Die 1200 Threads können ja auch wegen was anderem bestehen. Ich weiß nur, dass TB insgesamt 5 IMAP-Sessions pro Mailkonto aufbaut. Wenn ich jetzt ca. 100 Mitarbeiter habe, die im Schnitt mit 2 E-Mailkonten arbeiten, dann käme ich bereits auf 1000 IMAP-Sessions. Vielleicht sind daher so viele Threads offen. Ich weiß es leider nicht genau, da ich weniger in der Linux Welt arbeite. Auf jedenfall erschien die obrige Fehlermeldung ... Diese haben wir jetzt erst einmal erhöht. Wir möchten ungern zu hohe Grenzen setzen und gehen lieber in kleinen Schritten an das Problem heran. Ich überprüfe jetzt jeden Morgen die Log-Dateien des Vortages und schaue, ob weitere Meldungen aufgetaucht sind.


    Dabei ist uns nun z.B. aufgefallen, dass nachdem wir die obrige Fehlermeldung behoben haben, nun eine weitere erschienen ist.

    Code
    Warning: Inotify instance limit for user exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances


    Das hat unser Serveradmin nun auch behoben. Interessant finde ich allerdings, dass diese Fehlermeldung zu keiner Zeit vorher auftrat, sondern erst nachdem wir "login_max_processes_count" erhöht haben. Ich schätze daher, dass dieser Wert zu erst meckerte und nachdem nun weitere Verbindungen möglich waren der nächste Wert an seine Grenze gestoßen ist.


    Mich würde ja einmal interessieren, wie andere Firmen Ihren Dovecot Mailserver bei einer Mitarbeiteranzahl bis zu 200 Usern oder mehr konfiguriert haben. Nur leider findet man dazu wenig im Netz.
    Dann könnten wir die relevanten Einstellungen vergleichen und ggf. ab ändern.


    Nunja, weiter geht die Fehlersuche :)

    Ich habe nach längerer Logdateien Auswertung was gefunden! Es tauchte mehrmals

    Code
    Dovecot: Warning: All login processes are in use. You may need to increase login_max_processes_count


    auf.


    Wir haben nun dementsprechend login_max_processes_count von 512 auf 1024 angepasst. Mal sehen, ob die Meldungen nun ausbleiben und ob unsere Benutzer nun weniger TB-Probleme haben.


    Ich halte euch auf dem Laufenden, sofern ich Neuigkeiten habe. Hilfreiche Tipps nehmen wir aber immer noch gerne an :)

    anhand der Serverprotokolle einen Schritt weiter zu kommen.


    Das Problem ist ja, dass der Server in so einem Fall nie was in die Logs schreibt :/
    Daher muss das Problem bereits auf dem Weg zum Server entstehen, spricht vielleicht sogar im eigenen Netzwerk oder am Computer ... oder TB selbst ist das Problem?!


    Ich würde ja gerne weiterhelfen und den Entwicklern auch einen Tipp geben, aber wie gesagt, keine Einträge in den Logs und alle Limits sind soweit angehoben und auch die Hardware langweilt sich. Es liegt daher eig. nicht am Mailserver.
    Ich werde auf jedenfall weitere Tests durchführen. Ich werde mal anfangen das SSL auf STARTTLS um zu ändern. Es ist echt wie die Suche nach der Stecknadel im Heuhaufen :(

    ich gehe davon aus, dass Thunderbird dir den Ordner anzeigt, in den die gesendete E-Mail kopiert werden soll (dieser also abonniert ist).


    So siehts aus - Der Gesendet Ordner (Auf dem Server ja SENT) ist abonniert, sichtbar und auch nutzbar.


    Ich hatte einmal ein ähnliches Problem und bei mir hat geholfen, den IMAP-Ordner, in den die gesendete E-Mail kopiert werden soll, von Hand in den Thunderbird-Einstellungen auszuwählen:


    Das dürfte bei allem der Fall sein, da ich die Thunderbird Einstellungen per zentrale Steuerung (Autoconfig) verteile. Ich überprüfe das aber gerne noch einmal bei denen, wo es derzeit am meisten auftritt.


    die SMTP-Einstellungen des entsprechenden Kontos von SSL auf STARTTLS umzustellen.


    Das ist bereits bei uns Standard! Der SMTP-Server steht auf STARTTLS und Port 587 - Der IMAP-Empfang läuft allerdings über SSL/TLS Port 993. Ich kann ja auch gerne hier mal Testweise auf STARTTLS runterschrauben und prüfen, wenn Ihr sagt, dass das kopieren eine IMAP-Aktion ist.


    Peter:
    Vielen Dank für deine ausführliche Antwort. Ich muss grundsätzlich erst einmal erläutern, dass wir einen eigenen Postfix Server bei ISP betreiben und dort bereits alle Limits erhöht haben. Auch die Serverlogs protokollieren keine Fehler mehr,
    wie Anfangs als wir wirklich mal übers Limit kamen mit aktiven IMAP-Sessions uvm. Aber das wurde bereits alles gefixt. Das einzige was auffällt sind die ca. 1200 Threads die parallel laufen. Aber wenn Thunderbird auch pro Konto 5 IMAP-Sessions aufbaut, kommt man bei unserer Mitarbeiterzahl auch schnell auf so eine Anzahl. Aber wie gesagt, die CPU langweilt sich die meiste Zeit und ist auch nicht überlastet. Und ich denke wenn das der Fall wäre, hätten wir viel mehr Probleme am Tag ...


    Deine Idee mit dem lokalen Ordner klingt zwar ganz gut, doch ich weiß jetzt schon, dass viele Mitarbeiter so einen Filter nicht jeden Tag ausführen würden. Lässt sich das automatisieren? Beim Beenden von TB noch schnell die Mails aus dem lokalen gesendeten Ordner dann in den IMAP-Ordner zu kopieren? Dann wäre es sicherlich ein netter Workaround.

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Programm + Version: 31.4.0
    * Betriebssystem + Version: Win7 Pro
    * Kontenart (POP / IMAP): IMAP
    * Postfachanbieter (z.B. GMX): Eigener Postfix Server beim ISP


    Liebe Community,
    wir nutzen im Unternehmen Thunderbird und haben mittlerweile nicht nur mehr sporadisch das folgende Problem, sondern es wird immer häufiger.


    Und zwar äußert sich das Problem so, dass TB eine geschriebene E-Mail wohl verschickt, aber dann beim "In Gesendet kopieren ..." sich aufhängt und es nicht schafft.
    Nach einigen Sekunden dann die Meldung "Konnte nicht in Gesendet kopiert werden, möchten Sie es erneut versuchen?" - Meistens klappt selbst das erneute Versuchen nicht.
    Nun hat TB aber eine doofe Programmierung, denn er sendet die E-Mail jedes Mal erneut zum Empfänger - Und klicke ich auf Abbrechen, dann schließt sich meine E-Mail, was auch sehr ärgerlich ist,
    da ich Sie so nicht einmal mehr sichern konnte. Auch das Zwischenspeichern via "STRG + S" klappt dann nicht, da ich die gleiche Meldung erhalte "Konnte nicht in Entwürfe gespeichert werden".


    Wir haben nun schon diverse Stellen überprüft, konnte aber keine Probleme finden. Der Mailserver langweilt sich den ganzen Tag bei max. 5% CPU-Last und hat auch noch genug Arbeitsspeicher frei.
    Die Platten haben auch noch genug Platz ... Wir haben Dank Multi-Wan insgesamt 3 Internetleitungen... Also selbst wenn eine ausfällt, übernehmen die anderen die Arbeit.
    Aber auch hier konnte ich in Störungsfällen keine Internetausfälle sehen. Auch die Speedtest ergeben keine Schwachstelle ... Das interne Netz weißt auch keine Schwachstellen auf. Das Kopieren von Dateien rennt mit gut 100-90 MB/sec recht zügig im GB-Netzwerk.


    Auf den Computern läuft die Win7-Firewall und auch ein Antivir Program, welches allerdings keinen E-Mail Scanner besitzt und auch das TB-Profil als Ausnahme in der Liste drin stehen hat, damit dies nicht zufällig die mboxen beschädigt beim scannen.


    Das Problem taucht auch nicht immer auf! Das ist ja das merkwürdige, was es mir so schwierig macht. Mir ist nur aufgefallen, dass man TB einmal neustarten muss, nachdem man das Problem hatte, denn TB scheint sich danach irgendwie immer noch im Hintergrund damit zu beschäftigen. Meistens können auch vorhandene E-Mails nicht mehr korrekt geöffnet werden. TB bleibt daher meist auch im Taskmanager hängen, sodass ich ihn erst dort schließen muss. Nachdem TB-Neustart klappt es zu 90% dann auch wieder - Bis er das nächste Mal irgendwann wieder das Problem zeigt.


    Es ist echt zum verzweifeln. Kennt jemand ähnliche Probleme oder hat einen Tipp, woran es evtl. liegen könnte oder was ich noch testen könnte?


    Vielen Dank schonmal im Voraus.


    Liebe Grüße
    Nico

    Quote from "edvoldi"

    nur was für ein Datum für den Termin richtig ist, wenn mehrere ähnliche Daten drin stehen


    Genau, das kann TB/Lightning nicht richtig erkennen. In unserem Beispiel standen sogar mehrere Daten drin, als Enddatum wurde dann der letzte genommen. z.B. 11.09. / 20.09 / 25.09 - TB/Lightning nimmt dann den 25.09. als Enddatum, weils eben der späteste ist.


    Problem ist nur, wenn TB/Lightning andere Zahlen als Datum erkennen will, welche aber keine sind. Dann tritt es eben auf, dass der Termin am 02.02.2020 gesetzt wird oder ähnliches.


    Ich würde das Feature gerne deaktivieren. Scheint so, als wenn es dafür allerdings keinen config Eintrag gibt :(
    Falls jemand eine Lösung weiß, wäre ich sehr dankbar drum.

    Also auch wir haben die genannten Probleme mit falschen Datum beim "Umwandeln in Termin".
    Das scheint ja daran zu liegen, dass Lightning den E-Mail Text mitliest. In einer Mail stand im Text 25.09. und dies wurde auch als Enddatum eingetragen, wenn man diese E-Mail als Termin umwandeln wollte.
    In einer E-Mail mit einigen ausländischen Telefonnummern im Text wurde dann 2034 als Jahr eingetragen ...


    Ist dies nun ein Bug oder neues Feature von Lightning? Und wenn es ein neues Feature ist, lässt sich dies deaktivieren bzw. irgendwie umgehen? Leider hat man in Lightning ja schon so wenig Einstellmöglichkeiten.


    Achja, wir nutzen TB 31 mit Lightning 3.3 auf Win7.

    Okay, ich habe die Antwort nun doch selbst gefunden.
    Im schon oben genannten Blog wurde die Lösung später veröffentlicht:


    Quelle: http://mike.kaply.com/2012/03/…dvanced-autoconfig-files/

    Thunderbird-Version: 24.5.0
    Betriebssystem + Version: Windows 7 x64
    Kontenart (POP / IMAP): IMAP
    Postfachanbieter (z.B. GMX): Eigener Mailserver


    Liebe TB-Community,
    Ich suche eine Möglichkeit die userChrome.css beim ersten Start automatisiert erstellen zu lassen. Gibt es dafür eine Möglichkeit bei Thunderbird?


    Ich habe derzeit zwei Umsetzungsideen, wie man es theoretisch hinbekommen könnte:
    1. Nach der Installation von Thunderbird müsste direkt ein leeres Profil erstellt werden noch bevor Thunderbird zum ersten Mal gestartet wird. Dann wäre es mir via Softwareverteilung möglich, nach der TB-Installation noch eine Batchdatei auszuführen, die eine fertige UserChrome.css ins Profil kopiert.


    2. Wir benutzen in unserem Firmennetzwerk die MCD Funktion zur automatisierten und zentralen Konfiguration der TB-Settings. Zwar funktioniert das mit JavaScript-Dateien, doch TB nutzt nur eine sehr abgesteckte Version, sodass vieles überhauopt nicht möglich ist. Angeblich soll aber folgendes möglich sein:


    Quote

    ...the AutoConfig file is a Javascript file with full access to XPCOM Components. This is going to open up some really cool stuff for us later (dynamically generating userChrome.css and userContent.css) ...


    Leider wird bei der Quelle nicht beschrieben, wie das funktionieren soll. Auch beim Suchen konnte ich bisher nichts dazu finden ... Hat das evtl. schon jemand von Euch mal gemacht und kann mir dabei weiterhelfen?


    Wer kann zu diesem speziellen Thema helfen?

    Soooo ... das war wirklich - Test bestanden! Alles klappt nun wie gewollt! :D


    Also noch einmal für andere, die evtl. mal das Problem haben könnten:
    Alle TB-Einstellungen, die innerhalb der globalen Settingsdatei mit "lockPref" erfolgen, werden nicht in die prefs.js Datei des jeweiligen Profils gespeichert! Fällt die globale Settingsdatei mal weg oder ein Computer besitzt z.B. kein MCD, so werden die Standardeinstellungen von TB genutzt. Da ich alle Servereinstellungen per "lockPref" eingerichtet hatte, damit der Benutzer diese Einstellungen nicht ändern kann, wurden diese Einstellungen bei nicht vorhandenen MCD ignoriert und Standard gewählt. Allerdings gibt es bei TB Standardgemäß ja noch keine eingerichteten Servereinstellungen, weswegen dieses E-Mail Konten dann auch entfernt und keins angezeigt wurde.


    Ich habe nun alle "lockPref" Einstellungen auf "pref" geändert (Hat den derzeitigen Nachteil, dass der Benutzer nun die Einstellungen innerhalb von TB ändern kann), ABER alle Einstellungen sind in der prefs.js hinterlegt und der Benutzer kann seelenruhig innerhalb der Domain von Computer zu Computer wechseln, ohne das irgendwann sein Profil nicht richtig geladen wird, auch wenn er an einem Computer sitzt, der z.B. kein MCD besitzt.


    Na klar sollte in einem Live-Betrieb, wie Susanne es schon erwähnte, sowas nicht der Fall sein, aber in meinem speziellen Fall werden die neuen Rechner beispielsweise bereits damit ausgeliefert, aber die alten haben es noch nicht erhalten, da wir uns derzeit im Testbetrieb befinden.


    Liebe Grüße
    Nico


    PS: Thread kann auf gelöst gestellt werden :)

    So, da bin ich wieder und habe Neuigkeiten!


    Quote from "SusiTux"

    Woran erkennst, dass er das vorhandene öffnet? Ist dieses Profil jemals fertig eingerichtet worden? Oder öffnet der TB ein Profil, das zwar vorhanden, dessen Erstellung aber zuvor nie ganz abgeschlossen wurde?


    Es gibt nur ein Profil in der profiles.ini und nur ein Profilordner. Thunderbird mit Parameter /p zu starten zeigt auch nur ein Profil, außerdem sind noch die Plugins vorhanden, die bei der Ersteinrichtung installiert worden sind. Somit wird nur das eine Profil geladen.


    Ich weiß allerdings nun, wieso die E-Mail Konten fehlen - TB bearbeitet nach Start ohne MCD die prefs.js Datei:


    prefs.js nachdem ersten Start mit aktivierter MCD:

    Code
    user_pref("mail.account.account2.identities", "id1");
    user_pref("mail.account.account2.server", "server2");
    user_pref("mail.account.account3.server", "server1");
    user_pref("mail.account.lastKey", 3);
    user_pref("mail.accountmanager.accounts", "account2,account3");
    user_pref("mail.accountmanager.defaultaccount", "account2");
    user_pref("mail.accountmanager.localfoldersserver", "server1");


    prefs.js nach zweiten Start, allerdings ohne MCD:

    Code
    user_pref("mail.account.account3.server", "server1");
    user_pref("mail.account.lastKey", 3);
    user_pref("mail.accountmanager.accounts", "account3");
    user_pref("mail.accountmanager.defaultaccount", "account2");
    user_pref("mail.accountmanager.localfoldersserver", "server1");


    Man sieht, dass TB das automatisiert eingerichtete E-Mail Konto aus der prefs.js Datei entfernt.
    Deswegen ist das Konto auch nicht mehr sichtbar.


    Desweiteren habe ich festgestellt, dass "lockPref" Einstellungen in der globalen Settings Datei, die bei aktivierten MCD ausgelesen wird und die TB-Einstellungen einrichtet, nicht in der prefs.js gespeichert werden. Diese werden anscheinend nur temporär geladen aber innerhalb der prefs.js nicht gespeichert, sodass in der prefs.js trotzdem die eigentlichen Standardeinstellungen drin stehen.
    Ein Beispiel: Bei uns müssen E-Mails mit Verdana Schriftart bei 10pt (13px) geschrieben werden.
    Standard bei Thunderbird ist aber Calibri oder Cambria mit 17px.
    Stelle ich nun in meiner Settingsdatei die Schriftgröße auf 13px per "lockPref", so kann der Benutzer innerhalb von TB diese Einstellung nicht ändern, in der prefs.js wird aber trotzdem wieder 17px geschrieben.
    Wende ich nur "pref" an, so wird auch in der prefs.js 13px gespeichert, aber die Einstellung wäre vom Benutzer änderbar, wie ich es gerade im Test festgestellt habe.


    Da ich noch weitere "lockPref" Einstellungen habe, gerade für die Servereinstellungen, muss ich dies wohl alles auf "pref" anpassen, damit TB sich ohne MCD richtig verhält, hoffe ich jedenfalls. Ich werde also weitertesten und dann berichten.
    Jedenfalls bin ich nun schon einen Schritt näher - Rauszufinden, wieso TB die prefs.js bearbeitet, wenn kein MCD vorhanden ist.


    Lieben Gruß
    Nico

    Hey Susanne,
    vielen Dank für deine Nachricht.


    Also ich habe ja nun schon diverse Internetseiten durchsucht und verschiedene Anleitungen gelesen. Aber es wird dort wohl überall von ausgegangen, dass das MCD auf jeden Rechner aktiv ist.
    Bei mir ist es aber derzeit so, dass wir das Ganze noch "testen" - Allerdings mit zwei, drei Testbenutzern. Wir können ja nicht gleich alle Rechner damit ausliefern (wären so um die 110) und dann am Ende klappt die Hälfte nicht und dann rufen alle zeitgleich an - Daher erst einmal der minimale Testbetrieb, weswegen nicht jeder Rechner das aktivierte MCD besitzt.


    So, kommen wir zu deinen Fragen:


    Quote from "SusiTux"

    Wenn TB im normalen Modus zum ersten mal gestartet wird, dann überprüft er, ob bereits ein lokales Profil bzw. eine profiles.ini existiert. Falls nicht, legt er beides entsprechend im lokalen Benutzerverzeichnis an.
    Über die *.js-Datei im Installationsverzeichnis (/defaults/pref) teilst Du dem TB mit, dass dieser "normale" Modus nun nicht mehr gelten soll, sondern dass stattdessen das Config-File abgearbeitet werden soll. Damit wird aber letztendlich wieder ein lokales Profil angelegt.


    Das ist richtig - Startet man TB ohne MCD wird ja das lokale Profil angelegt und ich muss TB einrichten, alle Einstellungen setzen die bei uns relevant sind, die E-Mail Konten usw.
    Vorteil vom aktivierten MCD ist eben, dass ein neuer Mitarbeiter sein TB zum ersten Mal startet und ALLE diesen sonst von Hand eingerichteten Einstellungen bereits beim ersten Programmstart durch die Config-File gesetzt werden. Wie bereits erwähnt, klappt das auch soweit ;)


    Quote from "SusiTux"

    Nun hat jeder Anwender stets auch seine spezifischen Daten, wie den Usernamen oder das Homeverzeichnis. Diese benutzerspezifischen Informationen musst Du entweder per LDAP oder aus Umgebungsvariablen auslesen.
    Findet der TB beim Start kein js-Script unter /defaults/pref, startet er ganz normal und legt ggf. ein neues Profil an. Das erklärt dieses Verhalten:


    Wie so üblich werden diese Einstellungen ja in der prefs.js Datei im Profil gespeichert.
    Stimmt, den Benutzernamen lese ich aus der Umgebungsvariable aus und suche im LDAP dann die passende E-Mail Adresse raus, wodurch TB nur noch nachdem zugehörigen E-Mail Passwort fragt.
    Wenn TB beim Start keine js-Datei findet (deaktiviertes MCD), dann öffnet er sich zwar, legt aber auch kein neues Profil an, denn es existiert ja bereits eins, aber TB verhält sich, als wenn es ein neues Profil wäre. Es sind weder E-Mail Konten zu sehen noch sind unsere Firmenrelevante Einstellungen gesetzt.
    Ein weiteres lokales Profil wird unter "Roaming\Thunderbird\Profiles\" nicht angelegt. Er öffnet einfach das schon vorhandene, nutzt aber anscheinend nicht die prefs.js, in der ja alle Einstellungen stehen, weswegen das oben beschriebene Verhalten auftritt.


    Quote from "SusiTux"

    Woher kommt dieses Profil? Wurde es von Hand eingerichtet? Woher weißt Du, dass es funktioniert, wenn es doch nicht geladen wird? Oder meinst Du, dass der TB ein funktionierendes lokales Profil verwendet und lediglich die von Dir gesetzten Einstellungen über den MCD ignoriert?


    Ist an diesem Rechner der MCD aktiv, sprich ist die *.js unter /defaults/pref vorhanden?


    Wenn ich das Profil eines Benutzers per Hand (ohne MCD) eingerichtet habe und dieser sich von seinem Rechner abmeldet (innerhalb einer Domain), so kann er sich an jeden x-beliebigen Rechner innerhalb der Firma ja anmelden. Tut er dies nun und setzt sich an einen der drei Testrechner mit aktivierten MCD, so wird sein Profil auch geladen und er kann ganz normal weiterarbeiten. Meldet er sich nun von diesem Rechner wieder ab, so wird sein Profil ja wieder mit den Server synchronisiert. Am nächsten Arbeitstag meldet er sich wieder an einem Rechner ohne MCD an und dann taucht das Problem auf - Sein TB startet, es sind weder E-Mail Konten eingerichtet, noch unsere Firmenrelevanten Einstellungen eingerichtet. Also das oben beschriebene Verhalten taucht wieder auf.
    Er kann dann nur noch an Computern mit aktivierten MCD arbeiten. Also muss TB ja irgendwo innerhalb des Profils abspeichern, ob das Profil MCD benutzt oder nicht?! Und genau das versuche ich raus zu finden, wo TB sich das merkt, damit ich dieses Fehlverhalten evtl. durch ein Script oder eben eine TB-Einstellung deaktivieren kann.


    Klar soll am Ende jeder Rechner MCD erhalten und das Problem dürfte dann nie wieder auftauchen, nur derzeit benötige ich eine Übergangslösung.


    Quote from "SusiTux"

    Dann ist mir noch etwas zum Refresh-Intervall aufgefallen. Ich erwähne es, weil ich nicht weiß, wie der TB sich bezüglich dieses Refreshs verhält. Beginnt die Zeit bei jedem Start des TB von vorn oder speichert er die Zeit irgendwo? Mit anderen Worten, wenn bereits ein lokales Profil vorhanden ist, führt er dann gleich einen Refresh aus, oder wartet er noch bis die Zeit abgelaufen ist und verwendet in der Zwischenzeit das vorhandene Profil? In Deinem Fall könnte das heißen, dass er zunächst das vorhandene Profil nimmt und erst nach einer Stunde aktualisiert.


    Leider habe ich zur Refreshtime auch kaum was brauchbares gefunden. Wie das Ganze funktioniert, weiß ich auch nicht genau. Aber es ist eine interessante Theorie, die du da erwähnst. Vielleicht sollte ich einfach mal testweise die Refreshtime runtersetzen und prüfen, ob sich das Profil dann zeitverzögert lädt. Wobei ich aber auch sagen muss, dass nur bei aktivierten MCD diese Refreshtime ausgelesen werden kann, es sei denn TB speichert sich diese, wie du schon sagst, irgendwo zwischen ...


    Ich finde es leider schade, dass Mozilla zu diesem Thema wenig Informationen raus gibt. Innerhalb eines Unternehmens finde ich diese Funktion sehr brauchbar und nützlich. Außerdem erleichtert es die Arbeit, da man nur noch eine Datei bearbeiten muss und bei jedem Benutzer sind diese Einstellung nach einem TB-Neustart bereits aktiv. So muss man nicht mehr von Rechner zu Rechner laufen :)


    Lieben Gruß
    Nico

    Thunderbird-Version: 24.5.0
    Betriebssystem + Version: Windows 7 x64
    Kontenart (POP / IMAP): IMAP
    Postfachanbieter (z.B. GMX): Eigener Mailserver


    Liebe TB-Community,
    ich bin mir nicht sicher, ob ich die richtige Kategorie getroffen habe, sonst bitte Thema verschieben, Danke.


    Ich habe mich in den letzten Tagen mit der Thunderbird Autoconfig Funktion beschäftigt.
    Dabei ist es mir soweit gelungen alle möglichen Einstellungen beim ersten Thunderbirdstart korrekt zu übergeben.
    Die Funktionsweise sollte ja eigentlich jeden bekannt sein, der sich damit bereits beschäftigt hat. Einfach eine .js Datei in den "defaults/pref" Unterordner vom Installationsverzeichnis und dort die Angaben

    Code
    pref("general.config.obscure_value", 0);
    pref("general.config.filename", "TBconfig.js");


    setzen. Die TBconfig.js Datei befindet sich dann im Rootverzeichnis der Installationspfades (sprich z.B. C:\Program Files (x86)\Mozilla Thunderbird) und beinhaltet das folgende

    Code
    lockPref("autoadmin.global_config_url","file://///NETZWERKPFAD ZUR SETTINGSDATEI.js");
    lockPref("autoadmin.refresh_interval", 60);


    So ... das klappt auch alles wunderbar.
    Nur jetzt habe ich genau ein Problem - Und zwar, wenn sich ein Benutzer, dessen TB-Profil auf diese Weise eingerichtet wurde an einem Computer setzt, wo diese "Autoconfig-Funktion" noch nicht aktiv ist, sprich wenn es keine .js Datei im "default/pref" Ordner existiert. Dann kann Thunderbird ja keine globale Settingsdatei vom Netzwerkpfad laden und würde wie üblich arbeiten, sprich alle Einstellungen müssen per Hand eingestellt werden. Doch dieser Benutzer besitzt ja nun bereits einen Profilordner, somit auch ein funktionierendes Profil... Doch TB möchte dieses nicht laden, solange die .js Datei fehlt!


    Aber wieso? Wieso klappt das dann nicht? Auch wenn ein Benutzer, dessen Profil zuvor per Hand eingerichtet wurde, sich dann an einem Rechner setzt, wo diese "Autoconfig-Funktion" aktiv ist funktioniert noch alles. Doch meldet er sich wieder ab und an einem anderen wieder an, so wird danach wieder kein Profil geladen, obwohl es im Roaming Ordner vorhanden ist. Die profiles.ini sieht komplett identisch aus, auch innerhalb der Prefs.js konnte ich keine Einstellung finden, die darauf verweist, in welcher Form das Profil eingerichtet wurde.


    Wie also unterscheidet TB in welcher Form das Profil eingerichtet bzw. genutzt wird? Kann mir da irgendjemand mit weiterhelfen?


    Liebe Grüße
    Nico