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

Hallo inno,

halb so wild. Das Update auf 2.0k ist (hoffentlich) das einzige, bei dem entgegen der sonst üblichen Praxis die Clients der alten Variante d) geupdatet werden müssen. Also jeden TS einmal in den Installationsmodus und im Datenverzeichnis ...\VersionsUpdate\Setup\ setup.exe ausführen.

Edith meint, daß du außerdem noch die "persönlichen" Windowsverzeichnisse der TS-User löschen solltest, damit nach dem Update auf jeden Fall die aktualisierten Daten gezogen werden.

CU
Frank

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 Frank,
danke für die Info.

Nach Löschen der sfirm-Dateien (sfirm32.ini, sfirm32.ctx und sflicence.inf) im windows-Verzeichnis des user-Profils kann sfirm32 wieder gestartet werden (danke Edith).
Allerdings gibt es Probleme mit der Konfiguration (er startet bei Kontoabruf jetzt den Automaten auf dem TS, obwohl wir ausschließlich die DFÜ auf dem Applikationsserver laufen lassen). Können wir die sfirm32.ini hier einfach ändern?

Dieser Vorgang läßt uns die Nackenhaare zu berge stehen...

Was passiert eigentlich bei Start der Installationsroutine auf dem Terminalserver? Welche Dateien werden wohin kopiert, welche Einträge werden wo hinterlegt?

Danke für baldige Unterstützung
Hartmut

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

Schau mal unter Extra->Optionen->Admin(1)->verfügbare DFÜ Wege festlegen und nimm den Filter rechts für "nur diese Station anzeigen" raus.
Da solltest du sowohl den TS als auch den Appli-Server finden können.

Die Konfiguration kann mittlerweile grafisch erfolgen, ein händisches Verbiegen der ini nach der Installation muss nicht mehr sein.

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

Häh?

Wenn man sich das ganze vereinfacht darstellt, ist doch der Aplli-Server zusammen mit den TS Servern eine simple Netzwerkinstallation. Im Prinzip ist der Appli-Server auch nur eine Arbeitsstation innerhalb der Netzwerkinstallation, beherbergt aber auch die Datenbank und ist somit ein FileServer für die TS-Server.

Kannst du auf dem Appli-Server Sfirm direkt starten und dir da mal die obige Konfiguration aufrufen? Ich kann mir nicht vorstellen, das die Station nicht sichtbar sein sollte, es sei denn in den Überlegungen steckt noch irgendwo ein Denkfehler.

Wenn ich mich nicht täusche, werden die DFÜ-Wege seit einiger Zeit in der Datenbank an sich gesetzt, es kann daher sein das bei Start Sfirm die dort ausliest und darauf basierend die inis anpasst.

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

Wenn du die Installationsart D auf den TS verwendest, haben diese logischerweise keine eigenen Programmverzeichnisse. Das ist ja gerade Sinn der Sache.
Das Programmverzeichnis ist dann identisch zu dem des Servers, also hier dem Applikationsserver (Fileserver für den TS).

Wieviele Rechner hängen in welchen Eigenscahft da dran?

Nochmal zu Kontrolle:

Appli-Server:
Installation lokal auf ein (Programm und Daten gemeinsam) gemountetes Netzlaufwerk, oder auf zwei verscheidene Netzlaufwerke wenn Daten und Programm getrennt sein sollen.

TS-Server:
Installation als Netzclient (früher Variante d) in dieselben Netzlaufwerke wie oben.

Auf dem Appli-Server sagt man DFÜ = hier, auf dem TS sagt man: du machst nix.

Die TS-Clients arbeiten dann ja via Remote-Desktop nur stellvertretend für den TS-Server, sind als aus Sicht der Anwendung ganz normale SFirm Arbeitsstationen.

PS: Kann da bitte nochmal einer mit "drüberdenken"? Ist heute zu warm für solche Gedankenspiele...

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

Irgendwas ist da durcheinander.

Der Appliserver und die 4 TS Server sind zusammen nach Adam Riese 5 Arbeitsstationen, komischerweise sehen/kennen sich aber nicht alle.

Rechts von ansicht im Menü findest du das ?, in dem Menü bitte mal Info über Sfirm32 auswählen und Konfiguration anzeigen wählen.

Dabei wird ein kompletter Installationsreport erstellt. Da müsste man etwas detaillierter sehen wer was wo wie installiert ist udn was nicht passt. Am besten mal von verschiedenen Arbeitsstationen aufrufen und vergleichen.

Insbesondere der Punkt: Sfirm32 Installation ist interessant.

Ausschnitte kannst du auch hier posten, aber nicht alles. Unter anderem ist da der Lizenzcode drin. Oder schick es mir per PN.

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

Der ganze Kram hängt sicher an der lieben sfirm32.ini im Windoof Verzeichnis. Dort steht auch drin, wie die Station heisst (FTxxxx).

Jetzt kommt wieder die Terminalserver-Denke.... alles was ein TS-Client für sich ändert, landet als Kopie im Verzeihnis des Userprofils auf des TS-Server.
Wenn sich eine Arbeitsstation nach Aktualisierung eines der TS-Server frisch anmeldet, tut er das zu einer Zeit wo die sfirm32.ini noch unvollständig ist. Daher sieht udn kennt er möglicherweise am Ende nicht alles. Kannst du die Datei bitte mal überall prüfen?

Ich würde sie auf dem Appli-Server löschen (Sicherheitskopie), dann den Server mit einer Über-Installation lauffähig machen. Dann die TS-Server neu in Variante d (jetzt zusätzlicher Netzwerkplatz) dazuinsten und erst wenn das fertig ist die TS-Clients der Reihe nach aufrufen. Vorher aber deren Kopie der sfirm32.ini vernichten, so das sie sich eine frische ziehen.

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

noch eine Ergänzung von meiner Seite, die Ihr vielleicht mal an BIVG weitergeben könnt.

Auf der Serverfarm arbeiten wir bei den TS mit load balancing und servergestützten Profilen. D.h., bei der ersten Anmeldung eines Nutzers an sfirm wird eine sfirm32.ini für ihn erstellt mit der FTAM-Stationsnummer des TS, auf den das load balancing ihn gerade zugewiesen hat. Bei der Abmeldung von der Farm wird das Profil und damit die sfirm32.ini zurückgeschrieben. Landet er bei der nächsten Anmeldung auf der Farm auf einem anderen TS, passen die FTAM-Stationsnummern nicht zusammen. Wir haben damit kein Problem, weil auf keinem TS DFÜ erlaubt ist.

Nochmals danke an Euch und Grüße
Hartmut