Parallelbetrieb mehrerer SFIRM32-Netzwerkinstallationen

Hallo,

ich habe habe heute mal ein ganz besonderes Anliegen.

Einer unserer Großkunden wünscht den Parallelbetrieb einer Zahlungsverkehrssoftware. Hintergrund ist, dass der Kunde die Buchhaltung für einen weiteren größeren Betrieb führt und keine Datenvermischung zwischen dem eigenen und dem anderen Betrieb gewünscht ist.

Bisherige Konstellation war die Installation zweier MultiCash-Installationen. Diese liefen einwandfrei und ohne Probleme. Es wurden die gleichen EU-Disketten, Benutzer etc. pp. verwendet. Das war möglich, da die Reg-Einträge an (fast) einer Hand abzählbar waren.

Zur Zeit haben wir eine MC-Lizenz abgelöst und SFirm32 erfoglreich plaziert. Jetzt mein Problem: Führt eine weitere SFirm32-Lizenz auf den Clients unweigerlich zu Schwierigkeiten?

Folgendes dazu (Eigener Test): Der Parallelbetrieb auf einem Stand-Alone-PC/Laptop ist möglich. Einzig und allein der Versionsstand muß übereinstimmen, sonst "zeigt" die niedrigere Version die höhere an und will sich ständig updaten. Das ist aber nicht möglich, da die Registrierungen bereits auf die Laufwerkressourcen der neueren SFirm32-Installation verweisen. Liegt dagegen ein gleicher Versionstand vor, werden jetzt maximal nur unterschiedliche Lizenzierungen angezeigt, was jedoch in Normalfall ein Mausklick bedeutet. Letzteres wäre aber bei unserem Großkunden nicht der Fall sein, da er die gleichen Module einsetzen würde.

Ich habe jetzt folgendes vor: Die bereits installierte Version (Variante a/d) wurde auf Rechner A installiert und auf den Rechner C bis G eingerichtet. Die nächste Installation würde ich auf Rechner B durchführen und per Variante d auf den Rechner C - G installieren. Mein Gedanke ist, dass bei einem Update (egal ob Online oder per CD) immer nur die beiden Hauptrechner A + B geupdatet werden müssen und ich somit evtl. Fehlern/Hinweise/Abbrüchen aus dem Weg gehen kann. Die Registrierungen (Spalten etc.) würden ja für beide Versionen gelten - hoffe ich zumindest.

So - ich habe bestimmt irgendetwas vergessen - aber das Thema ist schon schwer genug.

Gruß Wilischgeist

Hallo,

wir haben auch einige Paralell-Versionen im Einsatz auch bei Kunden. Laufen ohne Probleme!

Wie Cap schon sagte, daß einzig nervige ist das Update!

Hallo,

an dieser Stelle mal meine Erfahrungen der letzten 2 Kundentermine:

Bei der ersten hatte der Admin 2 PC´s, die für die Installation gleich als jeweiliger"Hauptrechner" (Standardinstallation) genutzt werden konnten. Die erste komplette Installation, sprich die weitere Einrichtung der Arb.station verlief ohne Pobleme (Variante d). Die zweite SFirm-Anwendung habe ich dann mal mit Variante d und dann mit dem Anlegen einer einfachen Verknüpfung versucht (da ja die Systemdateien von der anderen Installation her dasein müssten). Beides bringt aber beim Starten einer der SFirm-Anwendung einen Fehler bzw. eine Warnung. Und zwar so ähnlich:

***************************************
Das FTAM/Web-Modul kann nicht genutzt werden. Bitte Setup erneut ausführen, um Fehler zu beheben.
***************************************

Wie gesagt eine von den beiden Anwendungen bringt immer diese Fehlermeldung und ich habe (m.E.) schon alles versucht.

Das Gigantische aber ist, wenn die Fehlermeldung weggeklickt wird, dann funktioniert trotzdem alles. Übertragung per FTAM/Web i.O.

Lange Rede, kurzer Sinn - die Warnung kommt mit Garantie aus der Reg. Dort ist ja nur die jeweilige (letzte) Setup-installierte SFirm-Anwendung bekannt. Die DFÜ klaptt, weil dann u.U. Dateien von FTAM/Web aus der jeweiligen anderen Installation genutzt werden (bin ich mir fast sicher). Da das ja die gleichen Einstellungen sind, gibt es kein Problem.

Bei dem anderen Kunden ist es etwas anderes. Dort treffen sich auf dem Chef-PC (gerade dort 2 SFirm Anwendungen unterschiedlicher Fachbereiche und von unterschiedlichen Sparkassen (wir und eine aus den ABL). Der Sachverhalt ist aber genau der Gleiche:

Was die Kunden nämlich stört - ist die Fehlermeldung. Hat irgendjemand einen Hinweis.

Dankeschön

Wie sich zeigt, ist eine zweifache Installation von SFIRM32 auf einem Rechner "HICKHACK". So etwas muss softwaretechnisch realisiert werden. Es stellt sich dann natuerlich die Frage, ob eine solche Realisierung Sinn macht (ich kenne sonst keine Software, die man gleich zweimal installieren muss :? ).

Es gibt vielleicht einige Tips und Tricks, wie man Deine Konstellation auch ohne softwaretechnische Realisierung (SFIRM32) durchsetzen koennte, ohne "HICKHACK" zu erleben. Aber solche Loesungen sind nicht "sauber" und "riechen" nach einer Menge Support und Aerger, zumal schon die naechste Version gegebenenfalls nicht mehr nach Deinen Erfordernissen arbeiten wird.

Einziges Workaround, welches mir im Sinne einer "sauberen" Loesung einfaellt, ist: SFIRM32 auf ZWEI Terminalservern oder mindestens EINEM Terminalserver (die zweite SFIRM32-Konfig dann auf "normaler" LAN-Basis).

Die Systemadministration Deines Grosskunden wird es interessieren!

Hallo "MrNett",



Das wirst nicht *DU* entscheiden. "Willischgeist" hat bisher nicht beschrieben, ob Terminalserver ueberhaupt (!) im Einsatz sind. Wenn ja, waere das von mir beschriebene WorkAround ggf. (Systemvoraussetzungen) annehmbar. Erst seit kurzem sind Terminalserver seitens der BIVG zugelassen. Unter Umstaenden hat "Willischgeist" auch noch unter anderen Bedingungen beraten.



Ich weiss nicht so recht, was ich von Deinen "einfach...komplett getrennten Versionen von SFIRM" halten soll. Vielleicht beschreibst Du das einmal naeher. Vor allem wuerde mich dann die DFUE (FTAM/ISDN) interessieren. Es hat auch momentan nur wenig Bedeutung fuer mich, sofern der Softwarehersteller nicht hinsichtlich der Programmierung klar und eindeutig Abhilfe bzw. eine Loesung geschaffen hat. Mit "zusammengemanschten" Konfigurationen, die kurzfristig weiterhelfen, kann es ebenso kurzfristig Aerger geben -vielleicht schon beim naechsten Update-.
Dass es bei "einem" Kunden problemlos laeuft, ist kein Grund fuer mich, dass ich es bei einer solchen "Quick and Dirty"-Konstellation immer wieder genauso machen wuerde....

Und immerhin schreibst Du ja in einem vorhergehenden Beitrag:


Das bringt so ueberhaupt nichts!

Dann reiche doch lieber einen Verbesserungsvorschlag ein! :?
Und vergiss nicht die Begruendung!

Grundsätzlich ist die Lösung mit zwei getrennten Installation keine Wunschkonstellation, schon klar. Das ist an sich ja auch keine vorgesehene Variante.

Wer keine Lust hat (oder andere Gründe hat, s.o.) die Installation gleich richtig, also mit Hilfe der Benutzerverwaltung und getrennten Zugriffsrechten auf die einzelnen Auftraggger und Konten sowie die einzelnen Menüpunkte zu machen muss eben mit dieser Krücke leben.

Klar verliert man bei notwendigen Nutzung der Benutzerverwaltung seine Adminrechte, da ein Admin nun mal alles darf und somit auch alles sehen kann.
Aber ist das in Betriebssystemen anders?

Wer keine Lust hat, dort seinen Admin aufzugeben und lieber alles doppelt installiert muss auch dort mit dem ständigen Reboot leben

HAAAALLLLOOOO !!!!

Kommt bitte beide mal wieder runter. Mit persönlichen Angriffen untereinander könnt ihr Willischgeist nicht helfen.

Zum Problem ist nicht eigentlich alles gesagt:
Wenn nur der Chef auf Rechner A beide Installationen sehen soll, dann installier so, wie du es geplant hast, also mit zwei a/d - Installationen z.B. in LW Y und Z. Da bei a/d das Update für das ganze Netz nur an einem Client gestartet werden muß, mußt du nur noch sicherstellen, daß das Update nicht vom Chef-Rechner gestartet wird, sondern jeweils von einem anderen aus. BTW: Welchen Vorteil soll ein TS dabei bringen? Soll der Chef sich beim "Firmenwechsel" jedesmal ab- und mit einem neuen Profil anmelden ?? Nicht wirklich, oder ??
Die sauberste Lösung von allen ist aber auf jeden Fall EINE Installation, bei der die Trennung über Benutzerrechte geregelt wird. Die BIVG hat sich bei der Möglichkeit der Anlage von getrennten Auftraggebern schon was gedacht. Es ist zwar etwas mühselig zu den Rechten passende Zahlungsordner anzulegen, aber das ist einmalige Arbeit.

CU

Frank

@cepe2005

Du forderst eine sachliche Diskussion, versuchst mich aber durch Stichelleien zu reizen! Soviel zu Deiner sachlichen Argumentation! Alles andere naja!

@all

das es bessere Lösungen gibt ist keine Frage! Das problem ist nur, daß die Kunden es so einfach und sicher haben wollen wie es denn geht!

Da bleibt manchmal nur zwei Installationen!

Das Problem mit FTAM ist bekannt, läßt sich aber lösen!

@Wilischgeist


Wie hast Du das denn installiert? Wie sehen die Pfade bzw die Datenbanklaufwerke aus?

Jaja:
Je groesser die Insel, desto laenger die Kueste der Verzweiflung.

Ich versuche lediglich, Dir klar zu machen, dass die Informationen und Fakten fehlen. Wir diskutieren hier ueber ein Problem, zu dem schlichtweg zu wenig Details vorhanden sind.

Ausserdem diskutieren wir ueber Work-Arounds, zu denen seitens des von "wilischgeist" angesprochenen Kunden ebenfalls keine Fakten vorhanden sind (ich schliesse mich da ein). Deshalb habe ich es auch "gewagt", einen vielleicht vorhandenen Terminalserver in die Diskussion einzubeziehen und als :!: moeglichen :!: Vorschlag aufzunehmen.



Sofern Du damit Deine Mehrfachinstallation meinst: Das sehe ich nicht so!



Auch in diesem Falle kann ich Dir nicht folgen.



Bitte genau spezifizieren. Sonst reden wir wieder aneinander vorbei.
Meintest Du jetzt in Bezug auf Mehrfachinstallationen die Online-Updates oder gar die Datenfernübertragung oder moegliche Fehler bei Folge-Versionen?

Hallo,

vorab erst mal die Information, daß SFirm32 bei den Kunden (mit der genannten Einschränkung) ohne weitere Probleme läuft.

Ich wollte aber auch keine Diskussion zwischen den beiden Produkten MultiCash und SFirm32 in Gang setzen. Das sind zwei unterschiedlichen Welten.

Und drittens - Dankeschön an alle, die bereits mitgewirkt haben. Das zeigt deutlich, wie gut und intensiv homebanking-hilfe.de genutzt wird.

Doch jetzt zum eigentlichen Thema:

Terminalserver grundsätzlich ja (eigener Standpunkt), aber derzeit beim Kunden nicht umsetzbar. Der Admin gibt mir die Netzwerk-Hierachie vor. Es waren 2 Installationen notwendig, da der Kunde eine strikte Trennung zwischen seiner Buchhaltung und der des Eigenbetriebes haben mußte. U.a. auch deswegen, weil die Mandaten-/Mehrbenutzerfähigkeit in SFirm32 nicht den Bedingungen des Kunden entsprach. So kann man ein Konto in der Ordnerleiste sehen, obwohl der Zugriff per Benutzerverwaltung untersagt ist. Das ist ein (kleines) Ansichtsproblem, für den Kunden dagegen ein Grund, ggf. die Software nicht einzusetzen.

Ich gehe an dieser Stelle mal nur auf die Installation beim Großkunden ein, da das Ganze sonst zu umfangreich wird.

Auf den Workstations (insgesamt 4 an der Zahl) wird mit beiden Anwendungen gearbeitet. SFirm32_DieErste (ich nenne die mal so) wurde dabei über die Installationsroutine von der CD Variante (d) ausgeführt. Die Einrichtung und Nutzung läuft einwandfrei. Die Standardinstallation (Variante a) wurde auf dem Rechner "Admin_DerErste" durchgeführt. Mit dieser Installation gibt es keine Probleme. Das Update (egal ob automatisches oder Online-Upd.) kann per Programmfunktion erfolgen. Sprich - eine klassische Installation.

Die zweite wurde dann wie folgt durchgeführt:

Die Standardinstallation erfolgt auf dem Rechner "Admin_DerZweite", also einem weiteren PC. Danach führte ich eine Datensicherung in der Anwendung SFirm32_DieErste durch und habe diese in der SFirm32_DieZweite wiederhergestellt. Hintergrund war die sehr umfangreiche Benutzer-/Bankenanzahl und die Vorgabe, die gleichen EUs für beide Anwendungen nutzen zu können. Alles andere (Datenbanken wie z.B. Auftraggeber, Empfänger, Archiv und DFÜ-Aufträge etc.) wurde komplett rausgelöscht. Auf Grund der Sicherheit (Rechner Admin_DerZweite darf nicht Online gehen) ist für die Anwendung SFirm32_DieZweite nur das manuelle Update möglich, funktioniert aber einwandfrei. Somit laufen beiden Anwendungen auf dem jeweiligen Admin-Rechner für sich und ohne Probleme. Und - beide haben den gleichen Versions- bzw. Patchlevelstand. Auf den Workstations habe ich dann nur eine Verknüpfung angelegt, da ja die Systemdateien im Hintergrund durch die SFirm32_DieErste aktuell gehalten werden. Ich habe bewußt keine Installation nach Variante (d) durchgeführt, um den reibungslosen Betrieb der SFirm32_DieErste zu gewährleisten.

Beide Anwendungen laufen - man muß dazu sagen "bisher" - stabil. Will heißen, daß bis heute keine Reorg (egal ob extern oder intern) notwendig waren. Der Admin ist "instruiert" kein Update ohne vorherige Absprache durchzuführen und regelmäßig die Datensicherung aus den beiden Anwendungen heraus zu starten. Die Rechner ADmin_DerErste und Admin_DerZweite haben auch keine Verknüpfung zu der jeweiligen anderen SFirm-Anwendung. Will heißen, der Admin ruft die Anwendungen immer auf den jeweiligen PC´s auf.

So weit, so viel, so gut

Unabhängig davon, ob es mal ein Problem wegen dem Update geben wird (und da bin ich optimistisch, weil wenn das Update in SFirm32_DieErste aus dem Programm herausgestartet wird, erfolgt gleichzeitig das manuelle Einlesen in SFirm32_DieZweite), habe ich jetzt immer noch das Problem der Fehlermeldung. Umsonst bringt SFirm32 nicht diese Fehlermeldung. Da interessiert mich aber, was genau im Hintergrund passiert bzw. wie kann ich nachvollziehen, welche DFÜ-Pfad verwendet wird. Meine ersten Gedanken wären jetzt, das Trace-Protokoll zu aktivieren und schauen, wo es hingeschrieben wird. Die DFÜ-Pfade in der FTAMISDN.INI verweisen auf die jeweiligen Installationspfade. Die CAPI20.INI sind identisch. Evtl. kommt das Problem wegen der AddrIsdn.ini. Im Trace-Protokoll selber wird nur der Pfad der AddrIsdn.ini (u.a mit Tilde ~) bzw. der zu übertragenden Dateien angezeigt, keine anderen Pfadangaben. Sonst erfolgt ordnungsgemäß das Schreiben der abgeholten Dateien in die jeweiligen SFirm32-Verzeichnisse.

Meine Erkenntnis:
Ich hatte nie Latein gehabt, bin aber mit selbigen am Ende.

Ich höre jetzt mal auf, den mittlerweile zuckt mein rechtes Auge, die Finger bluten und mein Magen meldet sich. Wenn ich etwas vergessen haben sollte, dann einfach fragen.

Danke