Dringender Hilferuf - sfirm 2.0k in einer Terminalserverfarm

Hallo zusammen,
nach meinem Thema "Installationsart D - Terminalserver" vom April habe ich die dort empfohlene Installationsrat hergestellt: Installationsrt A auf dem Applikationsserver, Installationsart D auf allen Terminalservern (Anmeldeservern). Vor dem update auf 2.0k gestern war ich dann recht optimistisch.
Das online-update des Applikationsservers (w2000) funktionierte reibungslos, sfirm ließ sich dort auch problemlos starten. Bei erstem Aufruf von sfirm als administrator auf einer Terminalserver-Console (ebenfalls w2000) aus kommt die Meldung "Auf Ihrer Arbeitsstation sind nicht die zu 2.0k passenden Systemdateien installiert, update vorhanden, jetzt starten?".
Ich werde dann durch das update-Prozedere geführt, bis diese irgendwann mit einer Meldung "Verzeichnisse können nicht erstellt werden" abbricht.
Mit dem neuen Installationstool hatte ich gehofft, daß sfirm fehlende Systemdateien sich automatisch holen könnte, aber da lag ich wohl falsch.
Jetzt stehe ich recht unter Zeitdruck, wer kann helfen?
Freundliche Grüße und danke
inno

Servus inno,

hast du den Patchlevel 3 für die 2.0k Version schon drauf?

Hier wurde in Sachen TS etwas geändert:

"Die Ermittlung der von SFirm32 benötigten Systemdateien wurde für Terminal-Server Installationen verbessert."

Starte doch einfach mal das ADU! Vielleicht ist damit dein Problem ja schon gelöst

Hallo,
Patchlevel 3 war ein guter Tip, danke.
"Die Ermittlung der von SFirm32 benötigten Systemdateien wurde für Terminal-Server Installationen verbessert." ... traf zu!

Ich habe jedoch noch das bereits geschilderte Problem, daß in die sfirm32.ini des jeweiligen Beutzers bei jedem Start von sfirm32 im Abschnitt [COCONET] NODFUE auf 0 gesetzt wird und somit der Automat auf dem jeweiligen Terminalserver gestartet wird, anstatt wie nötig auf dem Applikationsserver.
Woher holt sich sfirm diese Info? Wie kann ich das dauerhaft ändern? (wenn ich nach gestartetem sfirm32 NODFUE auf 1 setze, wird ein DSFÜ-Auftrag wie gewünscht auf dem Applikationsserver abgearbeitet).
Danke und Grüße
Hartmut

Hallo Captain Frag,
leider steht der Applikationsserver als DFÜ-Weg dort nciht zur Verfügung. Habe ich sfirm32 gestartet und setzte dann in der sfirm32.ini des users NO DFUE auf 1 im Abschnitt Coconet, dann läuft die DFÜ wie gewünscht, bis ich sfirm32 verlassen und neu aufrufe.
Wo holt sich sfirm32 beim Starten NO DUER=0 her?
Ich würde mich ja gern belesen, aber wo???...
Danke und Grüße
Hartmut

Hallo,
ich glaube, im attachment sehen wir die Ursache für das, was hier passiert.
die Stationen nutzne gemeinsame Prog.verzeichnisse???
Wie kann ich das ändern?

In den verfügbaren DFÜ-Wegen sehe ich immer nur diese beiden Stationen.

Grüße
Hartmut

Hallo,
hier die Konfiguration:

1. Applikationsserver installiert mit Installationsart A (identisches Programm- und Datenverzeichnis auf einem Netzwerklaufwerk), mit DFÜ (Automat läuft ständig auf der Console)

2. 4 Anmeldeserver RUBAVE-TS-A, -B, -C und -D installiert mit Installationsart D (nur Systemdateien), keine DFÜ (Programm- und Datenverzeichnis wie oben)

Sie läuft seit April stabil (damals habt Ihr mir bei der Herstellung einer "sauberen" Konfiguration geholfen...).

Ich denke, mit dem attachment sind wir schon dicht dran.

Ich bin auf einer Sitzung am TS-B. In Extras -> Optionen -> Administrator(1) -> "verfügbare DFÜ-Wege festlegen" existieren nur 2 Wege FT0001 (RUBAVE-TS-B) und FT0002 (RUBAVE-TS-D).

Auf der Konsole des Applikationsservers: In Extras -> Optionen -> Administrator(1) -> "verfügbare DFÜ-Wege festlegen" existieren nur 2 Wege FT0001 (RUBAVE-FS-1 - der Appli-Server(!)) und FT0002 (RUBAVE-TS-D).

Gebe ich hier den DFÜ-Weg FTAM für FT0001 frei, dann ist er auch für den TS-B freigegeben (da beide aus welchem Grund auch immer es zu diesem Mist kam). Beim nächsten Aufruf von sfirm32 am TS-B und auslösen eines DFÜ-Auftrags öffent sich sofort der Automat am TS-B und läuft ins Leere, da wir dort keine DFÜ machen können.

Auf einer Sitzung auf Terminalserver TS-A ist in den DFÜ-Wegen dann FT0001 für RUBAVE-TS-A freigegeben ...

Ich muß also die DFÜ-Wege bereinigen, im ganzen System existiert nur einer auf dem Applikationsserver, aber wie umsetzen???
Hier muß bei dem update auf die 2.0k etwas schief gelaufen sein.

Danke und heiße Grüße
Hartmut

Da stimmen die FTxxxx Angaben auf den einzelnen Servern nicht!!! :?
Es scheint, als wenn sich die Einstellungen gegenseitig aufheben /über-
schreiben.

RUBAVE-FS-1 ist FT0001 = ok

Überprüf mal die SFirm32.ini im "echten" Windowsverzeichnis auf den
Anmeldeservern. Jeder der Server sollte ein eigene Stationsangabe
haben.

Z.B.:
RUBAVE-TS-A = FT0002
RUBAVE-TS-B = FT0003
RUBAVE-TS-C = FT0004
RUBAVE-TS-D = FT0005

Wenn du bisher weiter keine Änderungen der SFirm32.ini manuell
gemacht hast, würde ich zusätzlich 1x aus allen "Benutzer-Windows-
Verzeichnissen" die ganzen SFirm32.inis weglöschen.

Viel Erfolg und ein schönes Wochenende

Hallo zusammen,
vielen Dank, es looft (nicht nur der Schweiß).
Ich habe überall alle sfirm32.ini's in den user-Profilen gelöscht. Der Applikationsserver war FT0001, 2 andere TS auch, warum auch immer... Auf jeden Fall haben sind wir uns recht sicher, es weder in der Kühle der Nacht noch in der Hitze des Tages eingetragen zu haben...

Dieses update hat uns viele Stunden gekostet, weil wir a) kaum Informationen haben und b) nicht wissen, was sich geändert hat und wie sfirm funktioniert. Es hat bis zum update auf 2.0k funktioniert, was hat sich geäündert?

Unabhängig davon Danke für die kompetente und engagierte Unterstützung!!!
Schönes Wochenende
Hartmut