Hallo,

folgende Nettigkeit: es handelt sich um eine Neuinstallation von SFirm32 in einer Terminalserverfarm. Hierbei erfolgt die Datenablage auf einem zentralen Datenpfad im Netz + Netzlaufwerk auf einem Fileserver (Windows 2000 SP4, Updates, OP-Lock, etc. pp.). Weiterhin läuft ein einfacher DÜ-Server (Windows 2000 SP4, 128 MB RAM, AVM KEN-Client/ISDN, etc. pp.), auf welchem der SFAutomat läuft und der sich auch die DÜ-Jobs "abholt" und per ISDN (via KEN) zu den Banken überträgt. Sfirm32 als Clientanwendung an sich ist dann auf z.Zt. zwei (künftig evt. auch drei) Terminalservern installiert.

Soweit so gut... rein Funktional klappt auch alles prima & bestens (Terminalserver-Installationshinweise wurden beachtet, INI auf die Laufwerke, Pfade und TS angepasst, Virenscannerausnahmen definiert, etc. pp.).

Trotzdem: Sfirm32 braucht auf den Terminalservern (die als VMs auf einem 2xQuadCore-Host mit 8 GB RAM laufen und innerhalb der VMs je knapp 3,5 GB zur Verfügung haben) auch bei unausgelasteter CPU und z.B. nur einem eingeloggten User ~ 30 Sekunden vom Doppelklick bis zum Anmeldebildschirm von SFirm. Der Healthcheck an sich dauert hierbei üblicherweise auch nur 4 Sekunden. Danach läuft die SFmain.exe 'ne ganze Weile bei 05-10% CPU-Last. Lt. ProcessExplorer greift der Prozess in dieser Zeit auf temporäre JET-Dateien im TEMP-Pfad zu und legt dort wohl auch sowas wie 'ne MDB an (Dateitypen LDB für's Lockfile und XXX was wohl eine umbenannte MDB ist).

Auf dem DÜ-Server (im Verhältnis zu den TS-VMs eigentlich eine lahme Kiste) dauert das ganze nur einige Sekunden.

Der kostenpflichtige 0900er-Support war eher nicht hilfreich (30 Minuten Telefonat, Resultat=0, noch nicht einmal Logfiles überprüft und dabei nur Standardantworten wie Virenscanner, etc. pp.).

Hat jmd. eine Idee? Was tut SFmain.exe eigentlich nach dem Healthcheck und vor dem Loginscreen?

Vielen Dank.

Gruß, B. Wettstein.

Eine berechtigte Frage, die mir ein Kunde auch schon stellte, der ähnliche Zeitverzögerungen hat seit der 2.2 - und das ganz ohne Terminalserver und Netzwerkinstallation.

Meine Versuche, bei der BIVG dazu was rauszubekommen, führten leider auch nur zu den Pauschalantworten rund um den Virenscanner usw. Insofern würde mich die Frage "was macht SFmain.exe in dieser Zeit" auch brennend interessieren, um dem Kunden gegenüber nicht ganz blöd achselzuckend in der Gegend zu stehen.....

Vor allen Dingen diese Unterschiede je nach Rechner sind für mich auch das große Rätsel - die reine Performance des Rechners kann es ja offenbar nicht sein, woran es liegt.....

Gruß aus Lübeck,

Jens Gerwien

Hallo,

welchen Virenscanner hast Du im Einsatz? Ich hatte das gleich Problem in Netzwerk. Es lag am Virenscanner

Hallo,



Wir haben Sophos für TerminalServer im Einsatz.

Folgende Ausnahmen sind bereits fest hinterlegt:

archie32.exe
d:\DATEV\PROGRAMM\DATEVDMS
D:\Programme\SFirm32
H:\SFirm32.db
kostst.mdb
kr????.mdb
KR?????.n??

Die meisten der Ausnahmen sind wg. DATEV bereits vor der SFirm-Installation hinterlegt gewesen. Trotz Ausnahme der o.g. SFirm-Pfade (lokaler Programmpfad, zentraler Netzdatenpfad) keine Wirkung auf das Problem.

Um die Sache einzugrenzen, hatte ich auch schon die Virenscanner aller Terminalserver + Fileserver bereits mal experimentell deaktiviert: Wirkung=0 .

Gruß, B. Wettstein.

Hi,

hast Du die Möglichkeit ein Testnetzwerk mit Sopohs auszustatten???

Hallo,



ja (dank VMWare), aber jetzt werde ich schon neugierig: was wird das bringen, wenn auch das testweise Deaktivieren von Sophos im Produktivsystem nichts ändert?

Vielen Dank.

Gruß, B. Wettstein.

Hallo B. Wettstein.



Kennst Du filemon (von www.sysinternals.com bzw. nun von MS http://www.microsoft.com/techn…lemon.mspx)? Damit könntest Du mitprotokollieren, was die SFmain.exe macht.

Gruß Michael

Hallo allerseits,

sfmain.exe -> beim Starten von sFirm ist sie abgestürzt. Nach Änderung des Druckertreibers ging es auf einmal wieder ohne Probleme. Also schaut sich die Gute die Konfiguration des Rechners schon etwas gründlicher an...

Gruß
Gregor

Ich denke mal das die sfmain.exe beim Start die Konsistenzprüfung der Installation durchführt und bei fehlenden/falschen Versionsständen von einzelnen Dateien oder eines Clients die Reparatur oder ein Update anbietet. Nach der Konsistenzprüfung erfolgt erst der Start des Hauptprogrammes.

->jedenfalls ist das meine Vermutung...

Möglicherweise macht das aber auch das Hauptprogramm selbst.

Hallo,



Vielen Dank für alle bisher genannten Lösungsansätze. Der Fehler blieb ja bei uns bekanntermassen trotz aller erwähnten Tricks und Standardverfahren (OPLOCK, Virenscanner, Druckerwarteschlange, etc. pp.). Ein über die Bank initiierter Support hatte noch die Druckerwarteschlange bei uns derart in Verdacht, als dass wir als standortübergreifende WTSFarm eine längere Liste festzugeordneter und lokal installierter Druckertreiber die durchs VPN kommunizieren bereithalten müssen (wobei ich auch hierzu meine Zweifel hatte, denn für was soll SFirm von z.B. 20 Druckern alle Configs einzeln auslesen)... egal, denn:

Unglaublicherweise habe ich den Fehler selbst gefunden, an welchem sich diverse Supporthotlines und Banken daran die Zähne ausgebissen haben. Selbst in einer Netviewer-Session wurde alles geprüft, nur das Folgende nicht...

Die Option "Symbole aus SFirm32 Version 2.0 weiterhin verwenden" ist verantwortlich für das Problem auf unserem System (wie schon gesagt Windows 2000 Service Pack 4, Terminalserver im Anwendungsmodus).

Nachdem diese bei allen Usern standardmässig aktivierte Version deaktiviert ist, startet SFirm32 bei mir in weniger als 5 Sekunden (wenn's im Cache ist braucht's noch nichtmal mehr eine Sekunde). Sowie die Option wieder aktiviert wird entsteht reproduzierbar das gleiche Problem wieder.

Toll... so generiert man auch 0900er-Hotlineumsatz... wer testet sowas eigentlich? (ja ich weiss, die Kunden...).

Vielleicht findet sich ja noch einen INI-Schalter dafür... bis dahin stellen wir diese Option gerade manuell bei allen Nutzern in der WTSFarm ein.

Gruß, B. Wettstein.

P.S.: achso ja... was sfmain.exe so zwischen Healthcheck und Login tut, weiss man bei der Hotline immernoch nicht....