11
Wie kann man eine Lexware Financial Office Pro Installation über 2 Subnetze benutzen ?
Die Lexware Financial Office Pro Software kann als Client/Server Installation betrieben werden in dem die Datenbank auf einem Rechner installiert wird und als Service auf diesem Rechner läuft damit die Clients von anderen Rechnern aus darauf zugreifen können. Sinnigerweise müssen laut Lexware Server UND Client im gleichen Subnetz sein damit die kommunikation funktioniert. Ist in unserem Betrieb aus Sicherheitsgründen nicht der Fall und dehmentsprechend stressig ist die Installation bis jetzt gelaufen. Da Subnetze kein revolutionäres Konzept sind und sich die Firma Lexware Marktführer schimpft kann ich kaum glauben das ich der erste ITler mit diesem Problem bin. Wenn irgenjemand eine Lösung oder einen Workaround weiss : sagt bitte bescheid.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72821
Url: https://administrator.de/forum/wie-kann-man-eine-lexware-financial-office-pro-installation-ueber-2-subnetze-benutzen-72821.html
Ausgedruckt am: 23.12.2024 um 15:12 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
es scheint, das dein Client den (Lexware) Server nicht finden kann. (Namensauflösung? Freigaben für den (Lexware) Sever richtig gestzt?
Peter
es scheint, das dein Client den (Lexware) Server nicht finden kann. (Namensauflösung? Freigaben für den (Lexware) Sever richtig gestzt?
Peter
Blöde Frage: Die Route hast du im Router aber schon eingetragen, oder? Das müsste doch reichen. Habt ihr vielleicht irgendwelche Firewalls dazwischen?
Wir schlagen uns auch seit zwei Jahren mit diesem Tool rum und ich muss sagen, dass professionelle Software anders supported wird. Btw. mit welcher Lösung fahrt ihr statistische Auswertungen? Wie wir jetzt nach (fast) einem Jahr vom Support erfahren haben, wird planung+controlling von der 2007er einfach nicht mehr unterstützt.
Wir schlagen uns auch seit zwei Jahren mit diesem Tool rum und ich muss sagen, dass professionelle Software anders supported wird. Btw. mit welcher Lösung fahrt ihr statistische Auswertungen? Wie wir jetzt nach (fast) einem Jahr vom Support erfahren haben, wird planung+controlling von der 2007er einfach nicht mehr unterstützt.
Firewalls sind als Problemursache schon eliminiert worden. Die Rechner selber können sich gegenseitig pingen etc , nur Lexware kommt nicht weiter als sein eigenes Subnetz. Über statistische Auswertungen machen wir uns im Moment noch keine Gedanken. Die Software muss erstmal zum laufen gekriegt werden.
Aus Erfahrung kann ich dir nur sagen: Lexware und "zum Laufen bringen" sind zwei Dinge, die sich wie gleichgepolte Magnetenden abstossen. Problemlos lief das Zeug bei uns erst lange nach der Einführung und ständig tauchen neue Probleme auf.
Lass doch mal Ethereal/Wireshark mitlaufen und guck, welche Pakete da nicht durchkommen. Vielleicht wird dann klarer, wo das Problem liegt. Innerhalb des gleichen Subnetzes hat es funktioniert?
Hast du schon die Datenquelle auf dem Server getauscht? Siehe hier:
http://64.233.183.104/search?q=cache:5sw-_opCxXMJ:www.lexware.de/suppor ...
Lass doch mal Ethereal/Wireshark mitlaufen und guck, welche Pakete da nicht durchkommen. Vielleicht wird dann klarer, wo das Problem liegt. Innerhalb des gleichen Subnetzes hat es funktioniert?
Hast du schon die Datenquelle auf dem Server getauscht? Siehe hier:
http://64.233.183.104/search?q=cache:5sw-_opCxXMJ:www.lexware.de/suppor ...
Ich bedanke mich! Nachdem die Einstellungen die im Artikel http://www.google.com/search?q=cache:5sw-_opCxXMJ:www.lexware.de/suppor ... beschrieben waren vorgenommen wurden ist unser 2-Subnetze Problem gelöst.
Danke Herr Oswald.
Danke Herr Oswald.
Servus,
das thema ist zwar schon älter .. klinke mich trotzdem nochmal ein.
Hat jemand mittlweiler schon eine Lösung für das Problem gefunden ?
Meine Erfahrungen ..
Subnetze mag Lexware gar nicht. besonders dann wenn der Traffic auch noch über kaskadierte Switche rennt.
Konnte zwar die Fehlermeldungen verringern mit diversen Versuchen.
Jedoch beim Arbeiten in der Software nach wie vor Fehler bzgl. DB nicht gefunden.
Da also offensichtlich grundsätzlich eine Verbindung zur DB steht (Client lässt sich öffnen und sogar Artikel usw anlegen), geh ich davon aus das broadcasting läuft einfach fehlerhaft.
Lösung bisher war nur möglich, wenn Client + Server im selben Subnet laufen.
Dann läuft alles fehlerfrei.
Fazit .. sobald die angebliche "Netzwerk Lösung" es mit echten und komplexen Netzen zu tun bekommt .. verweigert die SW einfach ein fehlerfreies arbeiten.
Hat jemand noch ein workaround wie es dennoch möglich ist in verschiedenen Netzen zu arbeiten ?
*der link über mir funktioniert leider nicht mehr
danke vorab.
vg,
sven
*vorstellung folgt noch
das thema ist zwar schon älter .. klinke mich trotzdem nochmal ein.
Hat jemand mittlweiler schon eine Lösung für das Problem gefunden ?
Meine Erfahrungen ..
Subnetze mag Lexware gar nicht. besonders dann wenn der Traffic auch noch über kaskadierte Switche rennt.
Konnte zwar die Fehlermeldungen verringern mit diversen Versuchen.
Jedoch beim Arbeiten in der Software nach wie vor Fehler bzgl. DB nicht gefunden.
Da also offensichtlich grundsätzlich eine Verbindung zur DB steht (Client lässt sich öffnen und sogar Artikel usw anlegen), geh ich davon aus das broadcasting läuft einfach fehlerhaft.
Lösung bisher war nur möglich, wenn Client + Server im selben Subnet laufen.
Dann läuft alles fehlerfrei.
Fazit .. sobald die angebliche "Netzwerk Lösung" es mit echten und komplexen Netzen zu tun bekommt .. verweigert die SW einfach ein fehlerfreies arbeiten.
Hat jemand noch ein workaround wie es dennoch möglich ist in verschiedenen Netzen zu arbeiten ?
*der link über mir funktioniert leider nicht mehr
danke vorab.
vg,
sven
*vorstellung folgt noch
So wie das aussieht, wird das niemals gehen..
die Lexware-Programmierer haben offenbar noch nie was davon gehört, dass eine Client-Software seine Datenbank niemals über einen Broadcast suchen sollte. Da der Router der natürliche Feind eines jeden Broadcasts ist, funktioniert das nie reibungslos.
Wireshark hat das bei uns sogar bestätigt (wir suchen uns in dem Fall schon länger die Füße wund).
Wir haben das jetzt auf eine "relativ elegante" Weise gelöst:
Im Subnetz des Lexware-Datenbank-Servers haben wir einen VMware-Server hingestellt und einzelne VMs aufgesetzt. Mit dem VMware-Server 2 (kostenlos bei www.vmware.com) braucht man auch keine Client-PCs in dem Sinne mehr, sondern arbeitet in einem Browser, bzw. Desktop-Shortcut.
Wir haben das Glück, dass nur 3 Leute die Lexware-Software benutzen müssen, wovon Einer sich schon im "DB-eigenen Subnetz" befindet. Somit war das leicht. Die Nötige Hardware war ein Core2Duo um die 2.5 GHz mit einer schnellen Platte und 3 GB DDR2-RAM (das ganze unter einem optimierten Linux, hier Debian Etch).
Ich hoffe, das bringt euch etwas weiter.
Gruß
Doc
die Lexware-Programmierer haben offenbar noch nie was davon gehört, dass eine Client-Software seine Datenbank niemals über einen Broadcast suchen sollte. Da der Router der natürliche Feind eines jeden Broadcasts ist, funktioniert das nie reibungslos.
Wireshark hat das bei uns sogar bestätigt (wir suchen uns in dem Fall schon länger die Füße wund).
Wir haben das jetzt auf eine "relativ elegante" Weise gelöst:
Im Subnetz des Lexware-Datenbank-Servers haben wir einen VMware-Server hingestellt und einzelne VMs aufgesetzt. Mit dem VMware-Server 2 (kostenlos bei www.vmware.com) braucht man auch keine Client-PCs in dem Sinne mehr, sondern arbeitet in einem Browser, bzw. Desktop-Shortcut.
Wir haben das Glück, dass nur 3 Leute die Lexware-Software benutzen müssen, wovon Einer sich schon im "DB-eigenen Subnetz" befindet. Somit war das leicht. Die Nötige Hardware war ein Core2Duo um die 2.5 GHz mit einer schnellen Platte und 3 GB DDR2-RAM (das ganze unter einem optimierten Linux, hier Debian Etch).
Ich hoffe, das bringt euch etwas weiter.
Gruß
Doc
Was steht in den ODBC Einträgen für Adaptive Server Anywhere auf dem Lexware-Client unter System DSN?
Gruß
Kinken
Gruß
Kinken
Hallo,
bei uns verweisen die System-DSN-Einträge direkt auf den Server. Wir haben es mit nem FQDN und ner direkten IP-Adresse versucht.. beides erfolglos ... nur die Sache mit der VM war das Einzige, was bei uns funktioniert hatte.
In irgendeinem Thread der Lexware-Hotline wurde das auch noch bestätigt.. kann euch den Thread aber leider nicht mehr nennen... ist zu lange her
Gruß
Doc
bei uns verweisen die System-DSN-Einträge direkt auf den Server. Wir haben es mit nem FQDN und ner direkten IP-Adresse versucht.. beides erfolglos ... nur die Sache mit der VM war das Einzige, was bei uns funktioniert hatte.
In irgendeinem Thread der Lexware-Hotline wurde das auch noch bestätigt.. kann euch den Thread aber leider nicht mehr nennen... ist zu lange her
Gruß
Doc
Hi,
wir hatten heute selbes Problem.
Einfach in dem leeren Feld neben den TCPIP Harken im ODBC HOST=IP_DES_SERVERS;PORT=2638 einsetzen.
Dann war bei uns Ruhe.
Gruß Daniel
wir hatten heute selbes Problem.
Einfach in dem leeren Feld neben den TCPIP Harken im ODBC HOST=IP_DES_SERVERS;PORT=2638 einsetzen.
Dann war bei uns Ruhe.
Gruß Daniel
Zitat von @dfritz:
Hi,
wir hatten heute selbes Problem.
Einfach in dem leeren Feld neben den TCPIP Harken im ODBC HOST=IP_DES_SERVERS;PORT=2638 einsetzen.
Dann war bei uns Ruhe.
Gruß Daniel
Hi,
wir hatten heute selbes Problem.
Einfach in dem leeren Feld neben den TCPIP Harken im ODBC HOST=IP_DES_SERVERS;PORT=2638 einsetzen.
Dann war bei uns Ruhe.
Gruß Daniel
Etwas ungenau formuliert:
Über den ODBC Administrator nach der DSN ->LXSYDSN suchen, dann auf den Netzwerk-Reiter gehen und alle Protokolle außer TCP/IP deaktivieren.
Im Feld neben dem TCP/IP Haken eintragen: "HOST=IP_DES_SERVERS" eintragen, also zum Beispiel "HOST=192.168.178.20"
Die Angabe des Ports ist nicht erforderlich.
Um die Sache zu Beschleunigen, kann noch der Schalter "DoBroadCast=None" mitgegeben werden.
