Beiträge von nordtech

    Moin zusammen,

    bei einem Kunden teile ich mir die Netzwerkverwaltung mit einem anderen (fremden) Dienstleister; er ist für Hardware und System zuständig, ich fürs Tagesgeschäft und u. a. für David.

    Es gibt drei Terminal Server, die in einer Farm zusammengefasst sind. Die User auf den TS haben sehr eingeschränkte Rechte; ich kann als Admin rauf. Nun geht es darum, den Benutzen David als Standard-Anwendung für mailto:-Links zuzuweisen. Systemsteuerung & Co. sind für die User gesperrt, auf dem Wege klappt es also nicht.

    Soweit ich das richtig gegoogelt habe, konnte man früher (bis Server 2008?) einfach den Key unter HKEY_CLASSES_ROOT\mailto\shell\open\command auf der lokalen Maschine anpassen, und alles war OK. Das scheint aber nicht mehr zu funktionieren - aktuelle Server möchten die Einstellung gern im User-Hive haben, unter HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associati‌ons\URLAssociations\‌MAILTO\UserChoice. Das ist händisch bei knapp 100 Benutzern natürlich etwas mühsam. ;)


    Was bleibt, wäre eine Verteilung per GPO. Und da hapert's momentan. Es gibt zwar eine Reihe von Anleitungen online, aber diese beziehen sich fast ausschließlich auf MS Outlook. In der Regel wird dort empfohlen, eine .adm-Datei zu erstellen und diese als Gruppenrichtlinie zu importieren, aber an welchen kritischen Stellen was durch welche Einträge für David ersetzt werden muss, erschließt sich mir leider nicht.

    Daher mal bescheidene Frage in die Runde: Hat jemand von euch zufällig ein passendes Template herumliegen? Oder wie macht ihr das mit der Definition in Terminal-Server-Umgebungen?

    Das sieht für mich so aus, als wenn da noch eine "unsichtbare" Symbolleiste zwischen hängt. Mach mal Rechtsklick und wähle "Symbolleisten fixieren" ab, taucht da irgendwo das Verschiebe-Icon (vier Punkte übereinander) auf, ohne dass daneben Symbole stehen? Dann diese Leiste einfach ausblenden oder irgendwohin schieben, wo sie nicht stört.

    Stimmt, steht so sogar in der Hilfe:

    Leider hatte ich bei der umgekehrten Suche (nach "SPAM") diesen Schalter nicht gefunden. Generell wundere ich mich in letzter Zeit öfters, dass in unserer Installation offenbar viele Werte vom Default abweichen, obwohl sie (wie in diesem Fall) ziemlich sicher nie manuell angefasst wurden. Vielleicht betrifft das in erster Linie sehr alte Installationen; unser David ist schon mindestens 10 Jahre immer nur aktualisiert worden, nie neu installiert. Das gilt für die meisten Kunden allerdings ebenso... Werde bei Gelegenheit mal prüfen, ob bei denen der Haken gesetzt ist.

    Das ist ja interessant. Die Option "SPAM melden" gibt es bei mir in den Benutzerrechten nicht - aktuelles Rollout, MIS aktiviert. Auch wenn ich testweise einen ganz neuen User anlege, erscheint da nichts. Konsequenterweise gibt's im Kontextmenu im Client keine Möglichkeit, die Nachricht als SPAM zu markieren. Nanü?

    Also aus

    Code
    Ort, %(Datum %k. %B %Y)

    Wird "Ort, 14. September 2017". Von daher musst du vermutlich erst mit "%(Datum" das Datumsfeld einleiten und dann mit den entsprechenden Variablen befüllen.

    Die Hilfe im David-Client sagt dazu Folgendes:

    Datum/Zeit
    Über die folgenden Variablen können unterschiedliche Datum- bzw. Zeit-Variablen ausgewählt werden:


    Datum
    Zur Auswahl stehen vier Variationen des aktuellen Datums. In Klammern sehen Sie jeweils ein Beispiel. Sobald das System die Serien-Nachricht erstellt, wird das Erstellungsdatum eingefügt.
    (16.04.2003): %(Datum)
    (Mittwoch, 16.04.2003): %(Datum %A, %x)
    (Mi, 16.04.2003): %(Datum %a, %x)
    (16-Apr-2003): %(Datum %d-%b-%Y)


    Zeit
    Uhrzeit der Nachrichten-Erstellung.
    %(Zeit)


    Wochentag
    Wochentag der Nachrichten-Erstellung.
    %(Wochentag)


    Monat
    Monat der Nachrichten-Erstellung.
    %(Monat)


    Kalenderwoche
    Aktuelle Kalenderwoche.
    %(Kalenderwoche)

    Es grenzt daher an ein Wunder, wenn die alten App-Versionen noch mit den heute aktuellen Versionsständen der David-Server funktionieren.

    Naja, der PCL Conversion Server (das dürfte nur den ganz alten Hasen noch etwas sagen) läuft mit dem neusten Rollout auch nach wie vor. Ich denke, dass Tobit an solchen Stellen bewusst nichts verändert, und dann funktionieren die alten Lösungen schlichtweg weiter. Bei der App ist eher Apple der "Gefahrenfaktor", da dort auch radikale Änderungen öfter mal vorkommen.

    Von meinen Kunden benutzt inzwischen niemand mehr die App, aber ich finde es schon gut, dass Tobit das Teil noch einmal fit für iOS11 gemacht hat. Schadet ja nichts.

    Problem ist, das die anderen Regel auch durchgeführt werden ... Obwohl Regel nr. 1 schon verschiebt ...

    Ich hab mich im Februar 2016 exakt darüber gewundert und bei Tobit eine Anfrage gestellt. Antwort damals:

    Es werden grundsätzlich alle Regeln abgearbeitet. Damit das so gewährleistet werden kann, werden Verschiebe-Regeln, sollte eine weitere Weiterleitung-, Lösch-, Kopier- oder Verschiebe-Regel auf diesen Eintrag zutreffen, die Datei nicht verschieben, sondern lediglich kopieren. Die Sortierung der Regeln dient dazu, dass bei vielen Regeln die Übersicht zu behalten.
    Die einfachste Lösung dafür wäre, im david® Administrator eine Verteilregel anzulegen, die die Verteilkennungen prüft und in die entsprechenden Archive verschiebt. Diese werden nämlich vor den Regeln in den Archiven verarbeitet. Die Verteilregeln in den Archiven können Sie dann entfernen.

    Also im Grunde genau das, was Arno oben schreibt. Vorteil der Regeln im David Admin: Im Ziel-Archiv, in das die Nachrichten auf diese Weise verschoben werden, können weitere Regeln existieren. Verschiebt man hingegen per Archive-Verteilregel und im Ziel-Archiv existieren weitere Regeln, so werden jene (nach meiner Kenntnis) nicht mehr gezogen.

    START "" /WAIT ""%ssl%\letsencrypt.exe --renew --baseuri "https://acme-v01.api.letsencrypt.org/" >> %ssl%\update_log_renew.txt"

    Bei mir ist es das gleiche wie bei lycra. Trotz Umleitung erfolgt die Ausgabe von letsencrypt.exe direkt auf der Console, nicht ins Logfile. Das ist 0 bytes groß, allerdings auch dann, wenn die Erneuerung sauber durchgelaufen ist. Kann ich reproduzieren, wenn ich den Befehl direkt aus der Komandozeile starte: Ausgabe erfolgt ins Fenster, Befehl läuft erfolgreich durch, die update_log_renew.txt wird erstellt, bleibt aber 0 bytes groß.

    Die Datei letsencryp.exe nutzt Serilog für die Protokollierung, und damit das sauber funtkioniert, muss man offenbar erst noch Pakete nachinstallieren. Mir war das irgendwann zu aufwändig, hab's daher nicht komplett durchgezogen.

    stylistics: Nutzt du die letsencrypt.exe aus dem Archiv von Murmelbahn, oder evtl. eine andere?

    Schon merkwürdig das es bei dir nicht so ist.

    Ja. Meine Webbox scheint immer nur exakt ein Zertifikat rauszugeben, obwohl drei zusammengefügt werden. Das ist doch so richtig, oder?

    Code
    type *-key.pem > wbcert.pem
    type %domain%-crt.pem >> wbcert.pem
    type ca-*.pem >> wbcert.pem

    Ich habe das Thema "Automatisches Update" nach vielen Versuchen ad acta gelegt; hier läuft's einfach nicht stabil und sauber. Entweder, es bleibt ein Programm hängen, oder die Webbox startet nicht sauber. Außerdem ist das Ganze eh ein bisschen suspekt, solange man von der letsencrypt.exe kein Protokoll bekommen kann - so ist nämlich nie klar, ob das Update wirklich durchgelaufen ist, oder der Batch nur aus den bereits vorhandenen Dateien eine neue wbcert.pem zusammenkopiert.

    Dennoch bin ich mit dem Ergebnis ganz zufrieden; bei einer ansonsten kostenlosen Lösung kann man es auch auf sich nehmen, 4x im Jahr manuell eine Erneuerung durchzuführen. Und das geht mit der update.bat sehr bequem.

    Mein Problem ist eher, dass Prüfseiten wie ssllabs.com immer noch melden, dass die Zertifikatskette unterbrochen sei. Obwohl die wbcert.pem ja aus den 3 Dateien zusammenkopiert wird, sagt mir ssllabs, dass lediglich ein Zertifikat übergeben wurde. "Sent by server" das für meine subdomain, "In trust store" das Root-Zertifikat, aber "Let's Encrypt Authority X3" wird als "extra download" angezeigt, obwohl es nach meinem Verständnis doch mit in die Datei eingebacken wurde? Hat diesbezüglich jemand eine Idee?

    Mann, hier ist irgendwie gerade der Wurm drin. Seit heute Morgen (oder vielleicht auch schon seit dem neusten Rollout, habe länger keine Termine mobil angelegt) folgendes Phänomen:

    Ich erstelle über den User-Account, der seit Jahren problemlos läuft, auf einem iOS-Gerät einen neuen Termin. Der wird auch brav übermittelt. "Teilnehmer" wird auf "Ohne" belassen. Kurz darauf habe ich aber im Ein- und Ausgang plötzlich eine Besprechungsanfrage, auf dem iPhone ploppt eine Nachricht "Vor 17389 Tg.: Einladung von... 1. Januar 1970 00:00". auf. In den Besprechungsanfragen im Ein- und Ausgang ist das korrekte Datum hinterlegt, allerdings sind das keine "echten" Besprechungsanfragen (ich kann nichts bestätigen oder ablehnen), sondern quasi einfache Mails.

    Ich habe: Den Account auf dem iPhone komplett gelöscht, dann im David Admin auch das Gerät und die ActiveSync.db entfernt. Konto neu eingerichtet -> "Accountinformationen konnten nicht überprüft werden". Kurzer Gegencheck auf dem iPad: Geht alles, muss also am iPhone liegen. Netzwerkeinstellungen zurückgesetzt, danach konnte das Konto problemlos eingerichtet werden. Es wird auch alles brav abgeglichen: Kontakte, Kalender, Aufgaben, E-Mails. Aber wo kommen jetzt diese Pseudo-Besprechungsnanfragen her? Die erscheinen übrigens auch, wenn ich am iPad einen Termin erstelle. Ist also Davids Schuld.

    Jemand eine Idee? Oder das zumindest schonmal gehabt?

    Moin,

    ich stehe (mal wieder) gedanklich etwas auf dem Schlauch. Um einem User einen Ordner zu verknüpfen (z. B., damit auf diesen auch via ActiveSync zugegriffen werden kann) geht man ja im David Client hin und sagt "Als Verknüpfung erstellen". Richtig? Glaub' schon. Nun möchte bei einem Kunden der Chef aber auch "Unverteilt" verknüpft haben, falls dort irrtümlicherweise Einträge auflaufen, die nicht zugeordnet werden können. Aber obwohl der User Domänen-Admin ist und sowohl auf Dateisystem-Ebene als auch in David alle Rechte hat, erscheint die Option "Als Verknüpfung erstellen" beim Unverteilt nicht.

    Tante guugel sagt: "Bei dem Archive Unverteilt handelt es sich um ein globales Archive, welches standardmäßig nicht im David.InfoCenter Web angezeigt werden kann. Jedoch gibt es die Möglichkeit, eine Verknüpfung dieses Archives zu erstellen, sodass dieses als Unterarchive von Verknüpfungen angezeigt wird. Auch ist es möglich, bei gehaltener Strg+Shift-Taste das Archive Unverteilt z.B. unter den Eingang eines Benutzers zu ziehen und so hier eine Verknüpfung zu erstellen. So kann dieses Archive auch im David.InfoCenter Web angezeigt werden."

    Klappt nur leider beides nicht. Bei Strg+Shift wird mit gleich per durchgestrichenem Kreis angezeigt, dass keine Verknüpfung erstellt werden kann. Und der Menüpunkt ist wie gesagt einfach nicht da.

    Der Witz ist, ich hab' die Verknüfung auf Unverteilt in unserer eigenen Installation auch, es muss also mal funktioniert haben - neu erstellen kann ich die aber ebenfalls nicht.

    Bitte keine Grundsatzdiskussionen zum Thema "In Unverteilt darf nichts ankommen", und man kann das natürlich über eine Verteilregel alles in einen Ordner schmeißen etc. pp. - mich würde nur interessieren, ob ich hier einen gedanklichen Fehler mache oder die Verknüpfung von "Unverteilt" einfach nicht mehr vorgesehen ist? Also auch nicht mehr per Umweg, wie früher?

    Ein Zertifikat kauf mal einmal für z.B. drei Jahre (27€) und gut ist, und ich kann es ohne großen Aufwand
    für andere Dienste verwenden.

    Mal doof gefragt: Wo bekommt man das für diesen Preis? Eine spontane Recherche ergab gerade ca. 100 Euro im Jahr - ist natürlich noch immer nicht die Welt, aber schon eine Schallgrenze, bei der manche Kunden meckern könnten (zumal es ja gar nicht so einfach ist, einem normalen Anwender zu erklären, wozu ein Zertifikat überhaupt gut ist).

    PS: Tobit Verkauft keine Webserver Zertifikate, sondern eMail (S/MIME) Zertifikate (von D-Trust).

    NOCH nicht. Ich denke, denen ist schon bewusst, dass da was passieren muss - wenn man ein selbsterstelltes Zertifikat in der Webbox und eine dynamische IP hat, bekommt man den Webaccess über https ja zum Beispiel nur noch übers Wegklicken vieler fieser Warnmeldungen aufgerufen. Gut möglich, dass neuere Versionen von iOS und Android da auch wählerischer werden. Mein Tipp ist, dass Tobit demnächst eine integrierte Lösung anbieten möchte, wie schon mit SPAM-Filter, Virenschutz, ePost, Mail-Zertifikaten usw. - nur wird diese Lösung nicht kostenlos und somit nicht auf Let's Encrypt basieren.

    hatte ich auch, aber keine hängende letsencrypt.exe

    Ich denke, das lag bei mir daran, dass die letsencrypt.exe in einen Fehler gelaufen ist und "versteckt" auf einen Tastendruck wartete o. ä.. Kann ich nicht mehr nachvollziehen oder reproduzieren, kam vermutlich vom intensiven Herumspielen (einmal lief der Update-Batch sogar parallel doppelt, schluck...)

    Ansonsten auch von mir noch einmal herzlichen Dank an alle Beteiligten.

    Definitiv! Richtig gute Aktion! :)

    Meiner Meinung nach ist es ein Trauerspiel, dass Tobit dies nicht selbst anbietet.

    Zumal der Gedanke ja offensichtlich schon vorhanden war - eigentlich kann's nicht so schlimm sein, das in die Webbox zu implementieren. Wenn man böse denkt, könnte es natürlich sein, dass kostenlose Erweiterungen nicht erwünscht sind und man lieber selbst Zertifikate anbieten/verkaufen möchte. Oder man hält die Vorarbeit mit dem Setzen von A-Record bzw. CNAME für zu support-anfällig. Keine Ahnung.