Von dem Problem des deaktivierten Grabbing-Dienstes sind z.B. Server 2012R2 betroffen. Wir haben auch noch eine spezielle Installation auf einen 2008R2 laufen und auch auf dem stand der Grabbing-Dienst. Die Installation des Hotfix ist auf all diesen Servern durchgelaufen, sie hat aber nichts bewirkt.
Beiträge von wlconsult
-
-
Nein, bei uns waren es insgesamt 5 Systeme, bei denen der Grabbing Dienst nach dem Update auf manuell stand und beendet war. Alle auf automatisch umgestellt und gestartet - läuft seitdem problemlos.
-
Läuft hier einwandfrei.
-
Es könnte sein, dass in das Record nicht der "agenturserver.de" reingehört, sondern die Mailserver von Mittwald. Kläre das notfalls mit dem Support dort, ein einfacher Anruf sollte genügen.
Bei IONOS wird z.B. auch nicht die Domäne eingetragen, sondern die MX von IONOS:
v=spf1 include:_spf-eu.ionos.com ~all
Für Mittwald sieht das u.U. ähnlich aus. Der Generator kann das in diesen Fällen nicht erkennen, bei Spacenet z.B. würde Dein durch den Generator erzeugtes Record aber passen.
DKIM ist dagegen nicht unbedingt notwendig, GMAIL akzeptiert die Emails auch nur mit SPF-Record. Das muss aber natürlich passen.
Grüße
Werner
-
GMail nimmt keine Emails mehr von Emailservern an, für die es kein passendes SPF-Record auf Deiner Domain gibt.
Es kommt darauf an, wie Euer DAVID die Nachrichten versendet: Macht Ihr das mit Smarthost über einen Provider (Strato, IONOS, ...) oder ist Euer DAVID direkt als MX eingetragen und sendet/empfängt direkt?
Prinzipiell muss das SPF-Record beim Betreiber der Domain im DNS Eurer Domain eingetragen werden. Wenn Ihr per Smarthost über den Provider versendet, geht das meist sehr einfach, weil es dafür bei fast allen Providern schon vorgefertigte Konfigurationen gibt, die man meist nur "einschalten" muss.
Wenn der DAVID dagegen direkt als MX tätig ist, dann musst Du das SPF-Record im DNS Eurer Domain als TXT-Eintrag selbst anlegen und die IP-Adresse des DAVID-Servers hinterlegen. Die FAQ der meisten Provider liefern hier immer gute Hinweise.
Du kannst das SPF-Record für Eure Domain überprüfen lassen, bzw. Du bekommst sogar Vorschläge für die in Eurem Fall gültige Syntax unter:
SPF Record Generator - MxToolBox
Viele Grüße
Werner
-
Dann ist es ja noch einfacher für Euch. Ihr müsst das Tool nur einmalig lizensieren und könnt es dann abgesehen von Eurer eigenen Installation für beliebig viele andere Migrationen nutzen.
-
Wenn der neue Server einen anderen Namen hat und sich auch noch in einer neuen Domäne incl. neuer User befindet, dann kann auch ich Dir nur dringend raten, den Umzug mit den Server Migration Services von TOBIT (über einen Fachhandelspartner) zu machen.
Den genauen Weg habe ich hier im Forum schon einmal beschrieben:
Wenn Du die Vorarbeiten selbst erledigst und auch den DAVID schon einmal vorab neu auf dem neuen Server installierst, dann sollte sich ein Fachhandelspartner finden lassen, der für den reinen Umzug mit dem Tool nur einen geringeren Obulus verlangt, weil es dann - abgesehen von der Zeit, die der Transfer der Daten benötigt - praktisch kein Aufwand mehr ist.
ARCUTIL ist eine absolute Krücke für diesen Zweck. Ein kleiner Fehler und Deine Arbeit war umsonst. Außerdem musst Du ja dann immer noch User neu zuweisen und vieles manuell korrigieren.
Wenn Du es mit Bordmittel machen willst (musst), dann kannst Du die Daten der User auch über Strongbox-Images zurückspielen. Allerdings setzt auch das voraus, dass Du den DAVID auf dem neuen Server nicht nur installierst, sondern auch komplett einrichtest. Mit den Strongbox-Images spielst Du ja nur den reinen Datenbestand zurück, nicht aber die Konfiguration des Systems selbst.
-
DAVID versendet grundsätzlich alle Emails mit UTC +0000 Zeit-/Datumsinformation. Das ist m.W. auch nicht konfigurierbar. In allen anhängenden Systemen ergibt sich in Zusammenhang mit der lokalen Zeitzone dann wieder die korrekte Sende-/Empfangszeit.
Das Problem scheint also eher Euer Archiv zu betreffen, denn wenn ich mir z.B. Mailstore-Server als Archivierungslösung anschaue, wird die UTC-Information dort ebenfalls in die korrekte Zeitzone "übersetzt" und Emails entsprechend dargestellt.
-
Ich kann Dir die ISO zu Version 3387 (Rollout 335) oder zu Version 3414 (Rollout 337) anbieten. Im Prinzip ist es so, wie QWERTZ schon geschrieben hat: Die ISOs ändern sich nicht so oft. Um auf exakt Deinen Stand zu kommen brauchst Du die ISO 3387 und das Rollout 336.
VG
Werner
-
Das liegt daran, dass Deine Testversion abgelaufen ist. Mit Sitecare hat das nichts zu tun. Eine Testversion läuft 30 Tage und danach stellt sie die Arbeit ein, es sei denn, Du kaufst DAVID regulär.
-
Wir haben einige Kunden mit Installationen so um die 20 bis 35 User. Die unangekündigten Preiserhöhungen für die Sitecare dort lagen im Bereich von ca. 20 - 27 %, je nach Useranzahl und Staffel.
Große Installationen waren schon immer deutlich günstiger als kleine Installationen. Für bis zu 10 User zahlt man ungefähr 50% mehr pro User und Monat, als für eine Installation mit z.b. 50 Usern. Die alten BASIC-Lizenzen mit 2 Usern (wie oben von Shubi genannt) sind extrem viel teurer geworden.
-
Einfach deaktivieren, es läuft dann zum angezeigten Zeitpunkt aus.
Ich persönlich empfinde die von TOBIT aufgerufenen Kosten für die Sitecare speziell bei kleinen Installationen auch als - gelinde gesagt - unverschämt. Zudem hat TOBIT die Sitecare-Kosten ohne jede Ankündigung letzthin auch noch mal deutlich erhöht, was bei einigen unserer Kunden die Diskussion über einen Umstieg zu O365 noch mal beschleunigt hat.
-
Neuinstallationen seit Dezember 2021 keine mehr. Wir betreuen nur noch Bestandskunden und ziehen nach und nach alle zu O365 oder gehostetem Exchange um. Ab und zu verkaufen wir eine Zusatzlizenz, das wars dann aber schon. Momentan sind wir noch TAR, das wird aber auch bald Geschichte sein.
Der Anreiz für Händler, DAVID zu verkaufen, geht gegen Null. Praktisch keine Provisionen mehr, der B2B-Support seitens TOBIT ist schon seit Jahren ein Witz. Der Händler muss einen jährlichen Mitgliedsbeitrag und auch noch für die Sitecare seiner NFR-Versionen bezahlen - das gibt es sonst nirgendwo!
Den Kunden fällt der Abschied auch leicht: Sitecare ist gerade für kleinere Installationen überproportional teuer und der Kunde bekommt im Gegenzug schon lange keinen echten Mehrwert mehr für seine regelmässigen Zahlungen. Dringend notwendige Dinge wie eine bessere Anbindung von Outlook als Client oder eine EWS-Schnittstelle für 3rd-Party Produkte sehen wir nicht kommen. Activesync wird lt. MS nicht mehr weiter entwickelt und in zukünftigen Outlook-Versionen auch nicht mehr enthalten sein, damit ist das Thema Outlook als Client demnächst auch erledigt.
Wer will/soll dann noch DAVID (ver-)kaufen?
Wir haben kein Problem damit, denn wir verlieren beim Wechsel auf ein anderes Emailsystem keinen unserer Kunden, TOBIT schon. Und die kommen auch nie wieder zu TOBIT zurück.
-
Wenn man die Authentifizierung mittels Personalausweis und Kartenleser machen möchte, dann muss zum einen der Kartenleser mit seinen Treibern installiert sein und funktionieren, zum anderen muss man auch noch die AusweisApp2 für das jeweilige Betriebssystem herunterladen (https://www.ausweisapp.bund.de/download) und installieren. Diese "klemmt" sich zwischen die D-Trust-Website und den Kartenleser.
Ist die App auf dem Rechner nicht vorhanden, kommt der von Kingcopy angesprochene Fehler mit 127.0.0.1:xxxx.
Gruß Werner
-
Habe ich erst Anfang dieser Woche für mein persönliches Zertifikat gemacht. Ich war ebenfalls überrascht und nicht vorbereitet. Ich hatte allerdings die notwendigen Gerätschaften:
- Personalausweis mit digitaler ID und PIN
- Reiner Cyberjack RFID Kartenleser
- AusweisAPP2 für Windows
Ich musste den ganzen Kram aber erst einmal installieren und aktivieren, denn obwohl mein Perso schon 4 Jahre alt ist, habe ich die Online-Funktionen bisher nirgendwo brauchen können. Den Kartenleser hatte ich schon vom Online-Banking, deswegen war das nicht das Problem. Es soll auch mit dem Perso und der App für das Mobiltelefon gehen (also ohne RFID-Lesegerät), aber das habe ich nicht ausprobiert.
Wenn ich das nicht da gehabt hätte, dann hätte ich mir ein Zertifikat eines anderen Herausgebers besorgt. GlobalSign, Certum, COMODO, SwissSign, ... machen das nach wie vor mit einfacher Email-Validierung, allerdings seit neustem auch nur noch für max. 2 Jahre.
-
Outlook 2016 und neuer setzen zwingend ein offizielles Zertifikat auf dem DAVID-Server voraus (z.B. von Let's-Encrypt, wie Nordtech weiter oben schon gesagt hat). Ein selbstsigniertes Zertifikat funktioniert hier nicht mehr, m.W. auch dann nicht, wenn man versucht, das Postfach über die Systemsteuerung manuell anzulegen. Bei Outlook ab 2019 muss man auch noch einen Weg finden, das Autodiscovery zu umgehen, wenn der Server nur lokal gefunden werden soll. Das funktioniert mehr schlecht als recht und schon das nächste Update von MS kann das wieder zunichte machen.
Der beste Weg hierfür ist eine feste IP, ein Subdomain-Eintrag beim Hoster und ein offizielles Single-Server-SSL-Zertifikat. So etwas kostet z.B. bei Sectigo als "Lite (Positive SSL)" Euro 59,00 für 5 Jahre. Das wird auch von allen mobilen Endgeräten sofort akzeptiert.
In neueren Outlook-Versionen ist der EAS-Support übrigens zwar immer noch drin, er wird aber seitens MS nicht mehr gepflegt. Die letzte Version bei der das voll implementiert und supported wurde und bei der auch noch selbstsignierte Zertifikate funktionieren ist Outlook 2013.
-
Das ist für den Fachhändler exakt dasselbe System, nur dass es da (wegen evtl. mehrerer gleichzeitig offener Anfragen für verschiedene Kunden) noch unübersichtlicher wird.
Das ganze Händlerportal ist in meinen Augen ein Witz und jeder andere Hersteller oder Distributor hat da Besseres zu bieten - leider. TOBIT ist hier auch absolut resistent gegenüber Verbesserungsvorschlägen oder Wünschen.
Vielleicht liegt die Ursache auch in der zwangsweisen Verwendung von Chayns. Die Website zeigt meiner Meinung nach jedenfalls, dass man so etwas besser nicht mit dem Chayns-Baukasten machen sollte. Dafür taugt das System definitiv nicht.
-
Eine Migration mit dem Migration Tool sollte kein Problem sein. Als TAR habe ich das schon oft bei Kunden durchgeführt und es hat immer gut geklappt. Allerdings sollten einige Vorarbeiten erledigt werden. Wie genau es funktioniert und was dabei zu beachten ist, habe ich schon vor ein paar Jahren hier beschrieben:
Ob das Tool in Eurem Fall auch das Mittel der Wahl ist, hängt von ein paar Dingen ab:
- Wie groß ist die gesamte Datenmenge der alten DAVID-Installation?
- Welche Downtime könnt Ihr akzeptieren?
Das Migration Tool kopiert die Dateien des Archive-Baums einzeln übers Netzwerk von A nach B. Wie viel da in welcher Zeit geschafft wird, hängt dementsprechend von Eurem Netzwerk ab. Ein paar hundert Gigabyte schafft man aber locker an einem Wochenende.
-
Hallo Burkhard,
hast Du schon Folgendes geprüft/gemacht:
1. In der POSTMAN.INI-Datei im Verzeichnis \DAVID\APPS\POSTMAN\CODE den Parameter EHLOWITHDOMAIN aktivieren und auf TRUE setzen.
2. In der Konfiguration des POSTMAN auf dem ersten Tab unter "Generell" bei "SMTP Host Name" eure Email-Domain eintragen, also z.B. "musterdomain.de". Hier steht oft die IP-Adresse des DAVID-Servers.
Danach den Postman-Dienst neu starten.
-
Könnte es sein, dass bei den betreffenden Usern die automatische Bereinigung (max. Eintragsalter) für das persönliche Adressbuch aktiviert ist und die fraglichen Adressen einfach durch die nächtliche Bereinigung automatisch gelöscht werden?
Eine automatische Bereinigung für Adressen ist zwar nicht besonders sinnvoll, man kann sie aber aktivieren und dann verschwinden tag-genau die zum Bereinigungszeitraum passenden Adressen. Bei einem Kunden hat das mal ein Spaßvogel für den zentralen Kalender aktiviert mit der Folge, dass nicht nur die ältesten Einzeltermine gelöscht wurden, sondern auch ganze Terminserien bis in die aktuelle Zeit von einem Tag auf den anderen "verschwanden".