dabei sollte man dann aber vermutlich - genau wie bei Android - drauf achten bei jeder weiteren Einrichtung des gleichen Accounts die Synchronisation von Kontakten, Kalendern und Co abzustellen, weil sonst alles mehrfach auf dem Smartphone landet?
Beiträge von riawie
-
-
Textbausteine - mit denen Du hier vermutlich eher Vorlagen für die eMails meinst kannst Du fürs iPhone nicht Serverseitig vorgeben, sondern musst das iPhone Seitig im dortigen Mail Client definieren. Das trifft letztlich auf alle Smartphones genauso zu wie bei jedem Drittanbieter Mail Client am PC / Mac ebenfalls.
iPhone und Apple ist nicht so meine Welt, aber auch da soll es dem vernehmen nach Apps geben mit denen man sich Mailvorlagen generieren kann. wenn du Dir da auf den betreffenden iPhones dann passende Vorlagen für die zwei unterschiedlichen zu verwendenden Absender definierst kannst Du da auch gleich jeweils den passenden @@von absender@domain.tld Befehl mit in die Vorlage setzen. -
grundsätzlich sollte man non standard Ports nur aus gutem Grund verwenden und nur wenn man ganz genau weiß was man da tut.
Port 8010 zu verwenden ist zwar nicht grundsätzlich falsch, birgt aber halt je nach dem wie weit man das System nutzen will einige Stolpersteine.
Entsprechend rate ich dazu auf den Standard Port zu wechseln. -
Da Du einen non standard Port für https eingerichtet hast musst Du den halt nun immer auch beim Verbindungsaufbau mit angeben, also in Deinem Fall:
"https://xxxxxx.tobit.net:8010"
satt:
"https://xxxxxx.tobit.net"
Denn letzteres versucht immer über den standard https Port 443 auf Deinen Server zuzugreifen, was aber nicht funktionieren kann da Du ja Port 8010 als https Port eingerichtet hast. -
Nachdem Herr Henner die gleiche Frage auch im offiziellen Tobit David Forum gestellt hat ist zumindest mal von dort bekannt das es um Strato geht.
Dazu kann ich sagen das Strato mindestens mal kein generelles Problem darstellt, denn wir holen unsere Mails auch mit einer 303 problemlos bei Strato ab.
Wenn man hier helfen können soll müsste man also mehr Informationen haben... -
Schau Dir mal den zeitlichen Ablauf der Geschichten an.
Ich kenne solche Fälle, die eMails sind in den mir bekannten Fällen immer erst nach der nächtlichen Bereinigung leer gewesen, nicht schon direkt beim verschieben.
Das Problem scheint zu sein das David die Daten nicht zwingend direkt beim verschieben in den Zielordner befördert, sondern unter Umständen dort nur einen Zeiger auf die Datendatei im alten Ordner einträgt.Schaut man sich die verschobene Mail am gleichen Tag an ist sie noch intakt.
Wenn dann die Bereinigung kommt findet sie im Quellordner vermeintlich nicht mehr genutzte Inhaltsdateien der Mails und entfernt diese.
Guckt man sich die verschobene Mail am nächsten Tag an ist sie dann leer.
Eine echte Auflösung wie das zuverlässig und dauerhaft abgestellt werden kann ist mir nicht bekannt.
Will man wenigstens eine Chance haben die Daten im Zweifel wieder aus der Strongbox holen zu können muss die Strongbox Sicherung zwingend vor der nächtlichen Bereinigung abgeschlossen sein.
Dann kann man die Mails immerhin wenn es einem auffällt wieder aus der Strongbox holen und hat sie nicht völlig verloren. -
geht schon, is aber nicht schön...
Es braucht:
1. Benutzerfreigaben für jeden der reingucken können soll auf jedem Eingang der eingesehen werden können soll.2. Bei jedem Nutzer der bei anderen in die Eingänge gucken können soll je Ziel eine Verknüpfung zu dessen Eingang
Aber Achtung: es dürfen keine Rekursionen entstehen, sonst macht sich Outlook tot...Also Verknüpfungen welche auf Eingänge anderer Benutzer zeigen die ebenfalls solche Verknüpfungen nutzen dürfen nicht der Einfachheit halber in Eingängen liegen, sondern müssen neben den Eingängen angelegt werden.
Wenn man das so anlegt bekommen die Outlooks diese Verknüpfungen so serviert als wären es schlicht weitere Ordner in ihrem ActiveSync Account
Angelegt und verwaltet werden kann das alles natürlich nur von einem TIC aus
Im Grunde ist das allerdings echt $zensiert$ -
Auf dem Rechner besteht scheinbar ein Problem mit einer nicht ordentlich abgeschlossenen Installation des besagten Produkts.
Das ist allerdings eher kein Tobit Problem, sondern des Rechners an sich und sollte sich so auch im Windows Explorer beobachten lassen, denn David bedient sich hier schlicht eines Systemdialogs, bei dessen Aufruf dann das beobachtete passiert.
Also Installation fixen und das Problem verschwindet. -
hmm, kommt wohl erst mal auf das Alter dieser Strongbox Datei an, denn wenn die zu alt ist erstellt der Service Layer reproduzierbar eine neue statt eine weitere Sicherung anzuhängen.
Grundsätzlich würde das ansonsten so gehen, das man einen sicherungsauftrag erstellt bei dem man als Ziel den Ordner in dem diese Strongbox liegt und dort explizit nur den neu hinzuzufügenden Ordner sichern lässt.
Mit sehr viel Geduld und probieren mag das klappen, aber schön ist anders...
Wenn es aber unbedingt sein soll würde ich wie folgt vorgegen:
1. im David Archiv dierekt unter Servername einen neuen Ordner anlegen, z.B. mit dem Namen "Archiviert"
2. Diesen Ordner dann als nächsten Schritt von der normalen Strongbox Sicherung ausschließen.3. In diesen Ordner den gesamten Inhalt der alten Archiv Strongbox wiederherstellen lassen
4. den zusätzlichen Ordner der nun ebenfalls archiviert werden soll dort mit hineinschieben
5. einen neuen Sicherungsauftrag erstellen welcher den so erstellten "Archiviert" Ordner komplett in die neue Strongbox sichert, aber auch nur diesen und nichts sonst.
6. neue Strongbox prüfen
7. Inhalt des "Archiviert" Ordners komplett löschen um das Live Archiv wieder zu entlasten.
8. die neue Archiverit Strongbox wieder allen Bedarfsträgern zur Verfügung stellen.
Der Weg sieht zwar aufwändiger aus und braucht zwischenzeitlich einiges an Speicherplatz, hat aber den Vorteil definitiv im ersten Anlauf zu funktionieren... -
mit den angedachten Variablen geht das so in der Tat nicht, die werden wie stylistics schon geschrieben hat erst beim versenden ausgewertet.
Wenn man das haben will könnte man sich allenfalls einen Menübutton mittels VBS scripten und dann entweder den Stempel in den eMail Text eintragen lassen, oder eleganter wie von Stylistics vorgeschlagen in einen Kommentar zur Nachricht schreiben lassen.
In irgend eines alten Folge der David Tipps vom Füchter hatte der mal was ähnliches angerissen, was auch Benutzerinfors ausgewertet und irgendwo verwendet hat, was nicht erst beim versenden sichtbar war.
Genaues kann ich dazu aber nicht liefern, nur die Anregung es in der Richtung zu versuchen... -
wir haben das so gelöst das die Signatur und Prflichtangaben erst beim senden an die eMails angehängt werden und nicht Teil der Vorlagen sind.
Benutzerkonfiguration > Versand > eMail-Fußnote
zur eigentlichen Vorlage gehört bei uns nur das Titellogo und die Grußformel, beides ist für uns schmerzfrei wenn es beim automatisierten Versand nicht Teil der eMail ist.
Der Kunde oder Lieferant interessiert sich da ja im Grunde eh nur für den Anhang.
Wenn tatsächlich mal ein Mitarbeiter eine zusätzliche Nachricht zu dem ERP Dokument dazu schreiben will klickt er sich die Vorlage halt wieder dazu, das ist problemlos weil in dem Moment der Editor - abgesehen vom Anhang - ja noch völlig leer ist.
99% aller durch das ERP System erzeugten Mails gehen aber eh ohne weiteren Text raus und bekommen nur die Signatur mit Pflichtangaben drunter gesetzt.
Nicht schön bunt, aber im Grunde halt funktional. -
burkhard komplexe Situation, je nach dem was da sonst noch alles zugegriffen werden soll und wie viele Mitarbeiter an den Außenstandorten arbeiten ist ein Terminalserver Ansatz in solch einer statischen Konstellation durchaus der richtige Ansatz.
Dabei muss dann allerdings dar Internetzugang am Hauptstandort auch berücksichtigen das die nun virtuell dort hinzukommenden Mitarbeiter unter Umständen ebenfalls noch zusätzlichen Internettraffic generieren.
Ich würde bei so einem Ansatz dazu tendieren den gesamten VPN Traffic per QoS zu priorisieren.
Wenn an den Standorten auch noch Telefonie über VoIP genutzt wird würde ich dafür eigene Leitungen schalten oder wenn das nicht möglich ist dem VoIP Traffic eine höhere QoS Priorisierung angedeihen lassen.
Wichtig ist das aller normaler Internet Traffic an allen beteiligten Standorten die niedrigste Priorität bekommt.
Es kann dennoch sein das normaler Surftraffic (Webbrowser) dann am Hauptstandort Probleme bereitet, in dem Fall sollte man die Bandbreite des Hauptanschlusses für Surftraffic so lange begrenzen bis das arbeiten flüssig wird, oder alternativ für Surftraffic und VPN getrennte Internetanschlüsse nutzen.
In einem Alternativszenario ohne Terminalserver müsste man erst mal ebenfalls eine Trafficpriorisierung einrichten. Dann könnte man mal versuchsweise den David Server für die Außenstellen Firewallen, also dafür sorgen das er für die Außenstellen nur noch auf den Ports 443 und 267 erreichbar ist (damit ist aber kein Portforwarding gemeint, sondern schlicht ein Satz Firewallregeln im VPN) . Das zwingt die David Clients den David Server wie einen remote Server anzusprechen statt wie einen Server im lokalen Netz und ihren Bandbreitenhunger zu beschränken. Momentan sprechen sie ihn ja wie einen normalen Server im gleichen Netz an und erwarten daher von ihm auch gewisse Reaktionszeiten und eine gewisse Bandbreite.Für den Zugriff auf andere Dateien würde man dann einen Branche Cache Server je Standort aufsetzen.
Je nach dem wie das VPN aktuell realisiert ist gäbe es da eventuell noch ein par weitere Optimierungsmöglichkeiten.
Grundsätzlich sehe ich es in solchen Situationen allerdings als sinnvoller an wenn die Mitarbeiter via RDP oder einem optimierten RDP Protokoll in der Zentrale arbeiten.
Das ganze Thema wirklich zu besprechen würde allerdings locker mal einen Tag füllen, allein für eine Bestandsaufnahme und Analyse der Ist-Situation ginge sicher ein halber Tag, wenn nicht mehr drauf, in der restlichen Zeit könnte man gerade noch grob ein Konzept und Handlungsanweisungen skizzieren.
Das wäre dann doch ein wenig viel für ein Forum wie dieses hier... -
twmemphis
Sorry, der Absatz:
"Der geschickteste Fall sowas zu lösen ist der das man für den David Server einen eigenen öffentlich auflösbaren Hostnamen vorsieht, der aus dem Internet aufgelöst immer zur öffentlichen IP-Adresse des Routers mit dem Portforwarding auf den David Server führt.Bezog sich rein auf das von nordtech geschilderte Problem das er ab und an mit einem Client der denkt er würde noch remote auf den David Server zugreifen müssen lokal im LAN neben dem David Server sitzt.
Das trifft auf Deine Konstellation aber ja gar nicht zu, also kannst Du den Absatz wieder vergessen.entsprechend ist Deine Überlegung hier:
Wir haben bereits einen öffentliche Hostnamen (mail.xxxx.de), welche nicht zum Router, sondern direkt zur IP Adresse des David Servers führt. Evtl geht es auch erst durch den MailMarshal, aber das kläre ich gerade.
Aber jedenfalls zeigt der Hostname aufgelöst nicht auf die IP des Routers. Sollte es besser zum Router zeigen?
leider durch meine Konfusion von oben grad fehlgeleitet und hilft Dir nicht weiter...
Um Dein Problem weiter einzukreisen müsste man natürlich wissen wie die genaue Aufstellung der Infrastruktur beim entsprechenden Server wirklich ausschaut.
Wenn man das nicht im Deatil anschaut wird das leider ein wenig Kaffeesatzleserei bleiben.
Ich kann aktuell halt nur eines mit Verbindlichkeit sagen und das ist:
Wenn der David Server performant ans Internet angebunden ist und ihm weder jemand der die gleiche Leitung nutzt die Bandbreite raubt, noch irgendwer an seinem Anschluss die eingehenden Verbindungen der Clients kaputtfiltert.
Dann können Clients welche selbst ebenfalls Internetzugänge haben bei denen sie nicht gegen andere Bandbreitenterroristen - wie z.B. gerade einem breitbandigem Stream lauschende Chromium Browser oder ähnlich kannibalisierende datenhungrige Anwendungen - selbst dann ordentlich remote mit einem David Server arbeiten wenn es gelegentlich zu Lags kommt.
30 Sekunden oder längeres einfrieren kommt dann nicht vor.
Viele Probleme die es aufgrund von Einschränkungen der Internetzugangsqualität auf einer von beiden Seiten gibt lassen sich mit einem fein getunten VPN deutlich abmildern.
Aber es muss einem klar sein das man dann daran arbeitet Probleme zu umschiffen die man besser abstellen sollte.
Leider kann man sie nicht immer alle abstellen, also muss man manchmal doch umschiffen.
Würde man beide Seiten per IPv6 anbinden und beim mobilen Nutzer alle nativen Möglichkeiten für nomadische IPv6 Nutzung voll ausschöpfen würde das übrigens den Idealzustand darstellen.
Allerdings hab ich das selbst hier - außer in einem Testszenario - noch nicht umsetzen können weil nicht überall natives IPv6 verfügbar ist.
Meine Aussagen das sich flüssig remote mit einem mobilen David Client auf einem David Server arbeiten lässt als säße man im Büro (das halt nur ein schmalbandiges LAN hat) beziehen sich also rein auf IPv4 Umgebungen und machen kein IPv6 zur Bedingung.
Das Problem was bleibt ist das sich jemand Eure Anbindung genau ansehen und optimieren sollte.
Das ist normaler Weise eine einmalige Investition die sich aber lohnt.
Natürlich kann man das alles auch durch ein anderes System ablösen welches von vornherein auf stark nomadische Nutzung konzipiert wurde, das hat dann halt seine eigenen Constraints.
Aber zu sagen das ginge mit einem David nicht tut dem David halt schlicht unrecht.
Vielfach sind es schlicht behindernde IDS Systeme und nicht gut abgestimmte Firewalls welche den David beim Einsatz außerhalb des LANS kastrieren.
Das Problem dabei ist das die wenigsten Dienstleister für David das Mandat und oft auch nicht die Expertiese haben sich auch um die korrekte Außenanbindung des Servers und der nomadischen Clients zu kümmern. Schuld ist dann aber natürlich der David... -
Nein, die Clients sitzen in Rostock oder München an einem Laptop mit DSL Anbindung und connected mit ihrem Online Client zum Server in Oberursel.
Die Rechner in Oberursel mit LAN Direktverbindung zum Server haben kein Problem, hier ist alles flott.
Oder hast Du es anders verstanden bzw gemeint
*argh* *narf* der Thread wird langsam unübersichtlich und ich hab Nordtechs Bericht mit Deinem in einen Topf geworfen
Ich werde den Kommentar mal bearbeiten, so das es wieder Sinn ergibt...
Sorry für die Verwirrung...
Eigentlich soll es ja nur um Deine Problemstellung gehen.
In Deinem Fall würde ich da wohl ein VPN einziehen mit angepassten Keepalives um das Thema NAT auszuschalten.
Wie gesagt, wir haben die Probleme nicht, unser David Server hat aber auch eine dedizierte eigene öffentliche IP und hängt an einem Anschluss der ihm ausreichende Bandbreite garantiert. -
Wie wäre es (bei gleichem Servernamen) damit:
1. Backup des DAVID-Verzeichnisses zurück spielen
2. Tobit darüber installieren?
wäre die ideale Lösung wenn er ein Backup des David Verzeichnisses gehabt hätte oder noch an das Verzeichnis gekommen wäre
Scheint aber als wäre das nicht der Fall gewesen... -
Edit: jetzt war ich mit den Urhebern der verschiedenen Aussagen durcheinander gekommen, also mal sortieren ...
nordtech das Problem auf was ich mich bezog, hatte in der Tat nicht twmemphis oben beschrieben, sondern Du selbst... , also ein Client der obwohl er im LAN sitzt nicht auf die Interne Adresse des David Servers zugreift sondern auf dessen externe Adresse, welche eigentlich nur genutzt werden soll wenn der Client sich außerhalb des Netzes befindet und dann nach längerer Nichtnutzung einfriert sobald man ins Fenster klickt und dann erst nach einer geduldigen Pause wieder reagiert sollte auf keinen Fall auftreten wenn der Client auf die LAN Adresse des Servers zugreift.
Passiert Dir das auch ohne das der Client über die WAN Adresse des Routers und Portforwarding auf den David Server im LAN zugreifen muss hast Du definitiv ein Problem im LAN.
Wenn es allerdings so wie auf der vorigen Seite von Dir beschrieben passiert hat das seine Gründe in der Art wie die meisten Router derartigen maskerading Nat Traffic zur eigenen externen IP Adresse und anschließendem DNat Portforwarding nach drinnen innerhalb ihres Kernels abwickeln.
Die Gründe dafür was da intern passiert zu erläutern sprengt hier leider meinen zeitlichen Rahmen den ich bereit bin darauf zu verwenden.
Entscheidend ist das man es aus dem Weg räumen kann und das man dazu die Anwender nicht zwingen muss immer an das umstellen des Server(namen)s zu denken wenn sie von draußen ins Office kommen
Der geschickteste Fall sowas zu lösen ist der das man für den David Server einen eigenen öffentlich auflösbaren Hostnamen vorsieht, der aus dem Internet aufgelöst immer zur öffentlichen IP-Adresse des Routers mit dem Portforwarding auf den David Server führt.
Zusätzlich konfiguriert man den DNS Server im Netz wo der David Server steht so, das er auch diesen öffentlichen fqdn Hostnamen auflöst, allerdings nicht mit der öffentlichen IP-Adresse des Routers, sondern mit der internen IP Adresse des DAVID Servers im LAN.
Damit entfällt im LAN das Thema Maskerading Nat nach Portforwarding über die öffentliche IP Adresse des Routers und damit entfallen auch die dadurch entstehenden Probleme wenn der David Client eine Zeit lang nicht genutzt wurde.
Diese Lösung funktioniert immer.
Es gibt noch andere Lösungsansätze dafür, allerdings ist es da von der genauen Konstellation der vorgefundenen Umstände abhängig ob sich ein Erfolg einstellt und wie man genau dahin kommt, daher verzichte ich hier auf weitere Erklärungen dazu.
---------------
Sorry für das vermischen der unterschiedlichen Problembeschreibungen...
Ich hoffe ich habs nun wieder sinnherstellend aufgeräumt.
Die Probleme von twmemphis sind ja doch etwas anders gelegen und eigentlich hatte ich versucht mich auch rein darauf zu beschränken... -
O.K. ich hätte schreiben sollen:
"Generell würde ich mir an Eurerer Stelle Eure Router und was die sonst so zu tun haben näher anschauen."
Sorry, ich hab nen Vollzeit Job und bin bereits jetzt durch die gesetzlichen Arbeitszeitbeschränkungen daran gehindert noch mehr zu arbeiten.
In meinem Status ist Freizeit unbezahlbar.
Dennoch beteilige ich mich gern an Foren und Austausch zum Thema Problemlösungen, denn davon habe auch ich etwas
Ich kann aber allenfalls die Richtung weisen, nicht Probleme bis zum Ende lösen, das übersteigt meine freien Ressourcen... -
twmemphis und nur mal so zur Einschätzung, die 30 MBit Synchron, wie sind die realisiert? SDSL? Und wie viele Leute arbeiten an dem Standort? Wie viele greifen remote auf Dienste dort zu? Und was steht da für ein Router/Firewall?
-
In unserem Büro München haben wir DSL mit irgendwas um 50MBit, hier am Server in Oberursel eine synchrone 30Mbit Leitung (ab Juni 600Mbit). Auch die Kollegin in Rostock hat eine 100Mbit DSL Leitung.
Beide, die Münchener als auch die Rostocker, haben sporadisches Einfrieren des Clients für ca 30 Sekunden.
Da es sich um Internet-Kabelverbindungen handelt ist es eher unwahrscheinlich, dass so lange Internet-Unterbrechungen vorliegen.
Die von Dir für die deutschen Standorte geschilderten Probleme klingen nach DSL Routern mit Problemen bei der gleichmäßigen Aufteilung von Datenströmen.
Kann es sein das da über die gleichen Leitungen auch noch ganz gern nebenher der ein oder andere Chromium basierte Webbrowser aktiv ist? Vielleicht auch noch mit dem einen oder anderen (mehrere Nutzer an einem Standort) Web Radio Stream? Chromium hat da so ein par unschöne Eigenschaften was sein Verhalten angeht sich zeitweilig bis zu 100% der Bandbreite einer Netzwerkverbindung zu krallen, das ist ganz nett wenn man gerade einen chromium basierten Browser für einen Download oder einen Stream nutzt, aber so gar nicht angenehm wenn man "nebenbei" was anderes tun will das auch nur im Ansatz interaktiv ist.Warum friert die App ein, wenn die Verbindung mal schwergängig ist? Dann könnte man doch dem Benutzer wenigstens erlauben im Editor weiter zu tippen und muss nicht gleich alles zum Einfrieren bringen, denn es ist ja gerade nichts super-eiliges an Daten zu übertragen.
An der Stelle hast Du natürlich völlig recht, wenn Tobit den David Client sauberer programmiert hätte müsste der Editor im Vordergrund gar nichts davon mitbekommen wenn es im Hintergrund gerade irgendwo klemmt.
in einer Kommunikation mit Tobit via Intercom von 2017 wurde mal empfohlen einen Loopback Adapter einzurichten. Kennt das jemand? Das simuliert wohl eine beständige Verbindung. Vielleicht erledigt sich damit ja das "einfrieren" ?
"Loopback" macht jetzt für mich irgendwie grad keinen Sinn.
Sinn machen würde hingegen ein VPN Client der ein niedriges Keepalive Intervall hat um die Verbindung aktiv und damit mehr responsive zu halten und noch dazu udp statt oder zusätzlich zu tcp zur Übertragung nutzt.
Generell würde ich mir Eure Router und was die sonst so zu tun haben näher anschauen.30 Sekunden einfrieren ist nämlich schon ziemlich extrem, das kenne ich nicht mal wenn ich im Homeoffice neben einem Chrome welcher einige hundert Tabs in einem dutzend Fenstern offen und aktuell hält remote arbeite, da sind es allenfalls mal einstellige Sekunden und das auch nur wenn mein dortiger Router grad richtig am ackern ist.
-
Das "kurz" würde ich nicht unterschreiben. Ich arbeite mit meinem Notebook 2x die Woche in einem anderen Büro und greife von dort per Direktzugriff (Port Forwarding) auf meinen Server zu. Oft vergesse ich am nächsten Tag, über Netzwerk -> Server wieder auf den LAN-Namen umzustellen, und so verbindet sich der Client "von hinten durch die Brust ins Auge" über david.[meinedomain].de quasi in mein eigenes Netz. Und das funktioniert im Prinzip auch.
Reproduzierbar ist dann aber folgendes Verhalten: Der Client steht da und zeigt keine Fehler, aber wenn man z. B. ins Fenster klickt kommt der "Warte-Kreisel" - das passiert immer dann, wenn eine Weile keine Aktionen im Client durchgeführt wurden. Bislang war es in der Tat meist so, dass sich das Programm innerhalb von ca. 30 Sekunden wieder gefangen hat, aber dezeit (seit Rollout xxx?) muss ich den Client via Taskmanager abschießen, da geht nichts mehr. Der Neuaufruf funktioniert innerhalb weniger Sekunden (und genau das ist der Teil, den ich nicht verstehe - wenn die Kommunikation offenbar klappt, warum kann der Client sie nicht wieder aufnehmen?)
David nervt schon lange mit diesen Abbrüchen, sehr sporadisch hatte ich das bei Kunden auch schon im LAN auf einzelnen Rechnern. Ein vernünftiger lokaler Cache und cleverere/fehlertolerantere Verbindungsstrategien wären durchaus wünschenswert.Das was Du da beschreibst lässt auf ein Problem des Routers bei Euch lokal schließen.
Sowas hatten wird früher durchaus auch.
Inzwischen arbeiten unsere reisenden Leute seit gut 3 Jahren lokal genau wie wenn sie unterwegs sind ausschließlich über die externe Adresse unseres David Servers und ist für die Nutzer im arbeiten kein Unterschied zur lokalen Nutzung fühlbar.
