Beiträge von nordtech

Schau mal in den Diensten, ob der SQL-Server (Instanz DAVID) korrekt installiert ist und läuft. Falls ja: Sagen im David-Client die Einträge unter System -> David -> Ereignisse irgendwas?

Die allermeisten Einstellungen (zumindest serverseitig) bleiben erhalten, wenn man entweder den Servernamen beibehält und stumpf das gesamte David-Verzeichnis überkopiert ODER den offiziellen Weg mit den Tobit Migration Servicves wählt. Letzteres kann bei sehr umfangreichen Archiven ein bisschen an der Geduld nagen.

Wenn du manuell alles mit Strongbox-Archiven umziehst, gehen die Einstellungen verloren, und bei einer Neuinstallation erhalten die Benutzer neue User-IDs. Woher soll das System auch wissen, wie es vorher war?

Zitat von juvilado

Das Zertifikat von globessl.com ist da, aber beim importieren verlangt er auch ein Passwort

Nee, das Zertifikat importierst du nicht auf die Smartphones, daraus baust du dir eines für die Webbox. Die weist sich damit dann "offiziell" als korrekte Gegenstelle aus, und der Weg mit dem manuellen Import entfällt.

Bastle dir eine neue Textdatei. In die kopierst du einfach untereinander die Inhalte der folgenden Dateien rein, die du von GlobeSSL erhalten hast:

1) Eigenes Zertifikat (kundenname.crt) (online bei globessl.com: CRT code)

2) Intermediate 1 (GlobeSSLDVCA.crt) (online bei globessl.com: CA code, erste Hälfte)

3) Intermediate 2 (USERTrustRSAAAACA.crt) (online bei globessl.com: CA code, zweite Hälfte)

4) Private Key (den du bei der Erstellung des Cert-Requests gespeichert hast).

Die Intermediates sind nicht zwingend nötig, sorgen aber für ein besseres Grading.

Diese Textdatei speichern als "WBCERT.PEM" (nicht "WEBBOX.PEM" !) im Verzeichnis \DAVID\APPS\WEBBOX\CODE, in der Konfiguration der Webbox Haken setzen bei "Zertifizierungspfad übertragen", in der Zuweisung der Zertifikate im David Admin ggf. die Pfade anpassen, dann Webbox neu starten.

Läuft die Webbox wieder, kannst du z. B. unter https://www.ssllabs.com/ssltest/ mal eure Domain eingeben und schauen, ob da alles schön grün ist. Mit obigen Einstellungen (Intermediates + Zert.-Pfad) sollte mindestens ein "A" herauskommen.

Zitat von juvilado

Nach dem Bestätigen kommt trotzdem wieder der Fehler:

Hast du das Zertifikat zusätzlich, wie von riawie in Beitrag 25 beschrieben, in den Zertifikatsspeicher des Smartphones importiert?

Zitat von juvilado

Welches muss ich denn wohl da bestellen?

In der Auswahl wäre das einfache Sectigo PositiveSSL vermutlich ausreichend. Du brauchst ja nur ein ganz einfaches für "Domain Validation".

Zitat von juvilado

Wie kann ich das denn bearbeiten

Bau dir einfach schnell ein neues.

Mach eine Sicherheitskopie eures jetzigen Zertifikats, vermutlich \David\Apps\Webbox\Code\wbcert.pem

Dann \David\Util\Windows\TLSCERT\tlscert.exe aufrufen und im Tool folgende Werte hinterlegen:

Certificate Type = Self Signed

Key Length = 2048

Country Name = DE

State or Province = Bundesland

Locality Name = Stadt

Organization Name = Firmenname

Organizational Unit = n/a

Common Name = EXAKTE (Sub)Domain David

Contact e-Mail = Mailadresse

Optionale Attribute: Leer lassen, Valid Days kannst du dir aussuchen (z.B. 366)

Wichtig ist dort halt, dass "Common Name" exakt der Adresse entspricht, über die du per Smartphone drauf zugreifst. Also z. B. eure dyndns-Adresse, ohne http(s)-Präfix. meindavidserver.dyndns.org etwa.

Die über das Tool erstellte Datei speicherst du als WBCERT.PEM in \David\Apps\Webbox\Code ab und startest dann die Webbox neu.

Schön finde ich das trotzdem nicht, auch wenn's funktioniert. Der Kostenaufwand für ein offiziell beglaubigtes Zertifikat ist ja nun wirklich minimal. Aber gut.

Zitat von juvilado

Ich will ja eigentlich kein Zertifikat für eine Webseite

Doch doch, in diesem Fall schon. Du willst ja damit keine E-Mails signieren/verschlüsseln, sondern ankommenden Clients nur bestätigen, dass sie den korrekten Host zu fassen haben. Gut, ist in diesem Fall nicht wirklich eine "Webseite", aber eben ein Dienst-Host.

Du brauchst: 1) Einen Hostnamen, der auf eure Adresse zeigt, da Zertifikate nicht für IP-Adressen ausgestellt werden können (nützt dir bei dynamischen Adressen eh nix). Wie gesagt, ich meine im Hinterkopf zu haben, dass Let's Encrypt keine Zertifikate für dyndns.org-Adressen ausstellt, bin da aber nicht ganz sicher. Falls doch, kommt der Tipp von ComputerManni ins Spiel, evtl. ist es schlau, sich bei Strato ein Billigpaket mit dyn. Host nur für diesen Zweck anzuschaffen.

2. musst du dann für diesen Host ein Zertifikat anfordern. Für LE geht das nur "zu Fuß" über die oben verlinkten Methoden. Ich hab' das seinerzeit offen gestanden als zu kompliziert empfunden und mir statt dessen ein einfaches Zertifikat bei GlobeSSL geholt ("Globe Standard SSL"). Einfache Domain Validation (DV), mehr brauchst du an der Stelle nicht. Andrere Anbieter gehen natürlich ebenso, GlobeSSL ist relativ billig. Für den Bezug erstellst du auf dem David-Server ein certificate request, z. B. mit der TLSCERT.EXE im Util-Verzeichnis. Mit dem ausgestellten Zertifikat musst du dir anschließend eine .pem-Datei bauen und diese der Webbox "unterjubeln".

Anschließend sieht es im Browser dann im Idealfall so aus, wenn du die Webbox-Adresse von extern aufrufst:

OK, im Screenshot steht neben der URL ein Ausrufezeichen, und es handelt sich um einen dyndns.org-Host (klappt LE damit überhaupt? Ich meine mich zu erinnern, dass wir bei allen Kunden auf andere Anbieter umgeschwenkt sind oder ein Konstrukt mit CNAME-Weiterleitung gebaut haben, weil die Ausstellung direkt auf xyz.dyndsn.org nicht funktionierte).

Ich gehe weiterhin davon aus, dass das Zertifikat Schuld ist.

Zitat von juvilado

Auf dem A40 funktioniert er weiterhin

Ich glaube nicht, dass wir hier weiter kommen, solange du uns nicht verrätst, welches bzw. welche Art von Zertifikat die Webbox nach außen weitergibt. Bitte:

Zitat von Ritana

Im Browser david aufrufen und schauen was das Zertifikat sagt.

Ports passen soweit, eingehend muss für ActiveSync nur 443 ankommen. Ich tippe auch zu 90% auf ein Zertifikats-Problem. Vielleicht ist ein Gerät da toleranter als das andere - früher[tm] war es gängig, dass auch selbstsignierte Zertifikate geschluckt wurden, seit einigen Jahren allerdings wollen die meisten Systeme ein offizielles.

Was bekommst du denn im Browser angezeigt, wenn die den Webaccess öffnest und mal in der URL-Zeile auf das Schloss klickst?

Zertifikat kostenlos wird schwierig, ginge wohl über Let's Encrypt, habe ich aber auf manuellem Wege nicht mehr ausprobiert, seit die Funktion in David eingebaut ist (für Installationen mit aktivem Sitecare).

Bei Kunden ohne Sitecare nehme ich i. d. R. ein günstiges Zertifikat z. B. von GlobeSSL. Das liegt bei knapp 10 Euro brutto für ein Jahr und ist damit auch für kleine Installationen verschmerzbar.

Ja, beim Weiterleiten scheinen Anmeldung und Verschlüsselung verloren zu gehen, egal, was im Postman für den Smarthost konfiguriert wird. "Gut", dass es auch bei anderen auftritt, dann hoffe ich mal auf einen zeitnahen Hotfix.

Nein, das läuft über eine Weiterleitung im Postman. Der Auftrag erscheint im "In Transit" als "Rundsendung" (obwohl nur an einen Empfänger gerichtet - weiß nicht, ob das vorher auch schon so war), und wird kurz darauf vom Provider mit obiger Meldung abgelehnt.

Sendemethoden etc. sind nicht definiert, die Mail muss mit den Standard-Postman-Einstellungen auf den Weg gehen.

Wie gesagt - bringe ich aus dem David-Client eine Mail mit identischem Absender und Empfänger auf den Weg, läuft's. Schon sehr merkwürdig.

Gestern, vor Rollout 411, funktionierte das noch einwandfrei. Nun habe ich schon wieder etwas Angst, was bei den Kunden passiert, wenn sich dort am WE David aktualisiert...

Nach dem Update klappt der Mail-Versand aus meiner Warenwirtschaft plötzlich nicht mehr. Verschickt wird per Smarthost, Strato sagt aber "falscher Absender". Bringe ich die Mails manuell auf den Weg, klappt alles, mit identischem Absender und Empfänger.

Aus der Meldung des Strato-Servers werde ich in diesem Zusammenhang nicht schlau, der Versand erfolgt immer über das selbe Smarthost-Konto:

:1: 250-smtp.strato.de greets xx.xx.xxx.xxx
:1: 250-ENHANCEDSTATUSCODES
:1: 250-PIPELINING
:1: 250-8BITMIME
:1: 250-DELIVERBY
:1: 250-SIZE 104857600
:1: 250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5
:1: 250-REQUIRETLS
:1: 250 HELP
:1: MAIL FROM:<info@xxxxxxxxxx.xx>
:1: 530 5.7.0 User not authenticated
(1) SMTP Server: Wrong Sender Name!
:1: RSET
:1: 250 2.0.0 RSET OK
:1: QUIT
:1: 221 2.0.0 closing connection
(1) Mail Transmission aborted

Kann das jemand reproduzieren?

Gnah! Mal wieder zu kompliziert gedacht.

Die Bereinigung erfolgt simpel über die Eigenschaften des Archivs "World Wide Web" -> "Postlagernd". Da ist standardmäßig im Reiter "Dienste" ein max. Eintragsalter von 10 Tagen hinterlegt.

In der Admin-Hilfe steht: "Beachten Sie, dass sich bei Nutzung dieser Funktion zum Teil erhebliche Datenmengen im Postlager-Ordner ansammeln können. Aus diesem Grund ist für den hierzu standardmäßig verwendeten Ordner (»WWW- Postlagernd«) eine automatische Bereinigung nach zehn Tagen voreingestellt."

Wo man die Dauer ändern kann, weiß ich spontan nicht - würde mal auf eine .ini tippen. Wobei mir weder in der david.ini noch in der webbox.ini ein passender Eintrag begegnet ist. Vielleicht wurde bei euch der entsprechende Wert hochgesetzt?

Aber bei einem so langen Zeitraum und den von dir beschriebenen anderen Problemen wird es vermutlich eher grundsätzlich an der Bereinigung haken.

Zitat von mk-itservice

selbstsigniertes Cert ist auch vorhanden

Nunja, ist das vielleicht der Grund? Mobilgeräte mögen ja schon seit einiger Zeit nur noch offizielle Zertifikate, vielleicht ist das bei neueren Outlook-Versionen auch so? Ich benutze das von David ausgestellte Let's-Encrypt-Zertifikat, damit funktioniert's definitiv.

Eigentlich müsste das nach dem, was ich so erkennen kann, greifen... Daher mal eine "doofe" Frage: Im Reiter "Ziel" ist schon die Aktion definiert, die du haben willst, oder? Also kopieren/verschieben? Oder ist da ggf. "kopieren" angehakt und wartest darauf, dass die Regel verschiebt?

Die "Anzahl Zugriffe" weiter rechts in der Liste werden ebenfalls nicht hochgezählt? Oder ist da zu erkennen, dass die Regel irgendwann früher schon einmal funktioniert hat?

Nun hab' ich extra gerade mal mein Outlook 2019 angekurbelt, um das zu testen.

Zugriff auf David via EAS Funktioniert weiterhin.

Erfahrungsgemäß macht Tobit da nix. Der Ball liegt auch eher bei der Software, die das "false positive" produziert, also beim Hersteller des Virenschutzes. Die Webseite wird vermutlich ja nur als unsicher aufgeführt, weil festgestellt wurde, dass von dort häufig "Schadsoftware" heruntergeladen wird.

Die Konstellation "großer AV-Anbieter" und "Kunde nutzt 'exotische' Software wie David" wird immer hakelig sein. Da hilft nur, mit dem manuellen Schreiben von Ausnahmen gegenzusteuern. Ehe man Kaspersky beigebracht hat, dass z. B. eine Drive-Snapshot-exe nichts Böses tut, bekommt man graue Haare.

An dieser Stelle aber auch erneut Unmut in Richtung Tobit, dass das Client-Update immer neu bezeichnete Temp-Ordner aufmacht: Bei einem Kunden wurde heute C:\Windows\Temp\Package7\clients\windows\dv4ts.exe als Malware erkannt - würde statt "Package7" (die Ziffer ändert sich ständig) einfach "TobitClientUpdate" oder so verwendet, könnte man schön den gesamten Ordner als Ausnahme definieren.

Naja. Obiges trat heute tatsächlich nur auf einem (!) Client auf, Securepoint bzw. Ikarus waren mit der Anpassung offenbar sehr flott.

Zitat von riawie

Ich komm grad ums verrecken nicht drauf wo ich das wieder gerade biegen muss

Alternativ zum Registry-Eintrag: Im Verzeichnis des Classic Clients in DVSMAPI einmal die dvsmapi.exe aufrufen und den Dialog bestätigen. Je nachdem, ob 32 oder 64 bit heißt der Ordner "C:\Program Files\Tobit InfoCenter" oder halt "C:\Program Files (x86)\Tobit InfoCenter".

Ich hab' das bestimmt schon ein Dutzend Mal durch; viele Kunden mögen den Modern Client tatsächlich spontan nicht so besonders. Vermutlich in erster Linie wegen der Optik - ich hatte aber auch schon einen Fall, wo der neue Client aus unbekanntem Grunde ständig hakte und stockte. Mit dem alten ist alles OK.

Ja, eine Strongbox-Sicherung des Kalenders hatten wir schon im Laufe der Kommunikation mit dem Tobit-Support nach Ahaus geschickt. Es hieß damals, mit dem Kalender sei alles OK, aber die können natürlich auch nicht jeden einzelnen Eintrag auf Herz und Nieren prüfen. Wir haben dem Support nun explizit beschrieben, welche Einträge wir in Verdacht haben, vielleicht lässt sich ja was erkennen.

Fürs Protokoll: Wir haben nach unzähligen Versuchen mit Herumschrauben an Hardware, Einstellungen, Smartphone-Clients etc. nun vermutlich die Lösung gefunden. Zumindest idelt die Webbox jetzt die meiste Zeit über, in Spitzen geht's mal auf 2-5% hoch, aber insgesamt deutlich ruhiger.

Dummerweise hatten wir zuletzt "aus Verzweiflung" mehrere Maßnahmen am Laufen, daher ist es nicht exakt möglich, die Ursache zu benennen. Ich denke allerdings, dass es an einem defekten Eintrag in einem für alle User verknüpften Gruppenkalender lag. Den habe ich durch Zufall entdeckt, weil er zeitlich gut zum erstmaligen Auftreten des Problems passte. Dem Eintrag selbst war allerdings nichts anzumerken, er ließ sich normal öffnen. Aber nach Löschen und neu Anlegen wurde es plötzlich zunehmend ruhiger auf dem System.

Schön, dass wir eine Lösung finden konnten. Wieder einmal zeigt sich allerdings, dass David an manchen Stellen keine wirkliche Fehlertoleranz aufweist. Wie z. B. auch beim Outlook-Import oder dem Migrationstool. Wir konnten ferner nicht feststellen, wie es zu diesem defekten Kalendereintrag gekommen ist, der Server hatte keine Abstürze oder Dateisystem-Probleme. Na ja. Hauptsache Problem gelöst, Kunde glücklich.