Goed, ik zal even de situatie vertellen.
Iedere pc in het netwerk heeft deze regel in zijn loginscript staan
start /b \\filesrv1\dnetc$\dnetc.exe -quiet
De ini staat dus ook op die server en de packets haat hij op via een proxy.
ini file :
<begin>
[parameters]
id=x@x.x
[triggers]
pause-on-no-mains-power=no
pause-watch-plist=taskmgr.exe|perfmon.exe
[misc]
project-priority=RC5,DES=0,CSC=0,OGR=0
[networking]
autofindkeyserver=no
keyserver=filesrv1
[rc5]
fetch-workunit-threshold=15
<end>
Tevens draait er op die server (filesrv1) een perproxy.
Het probleem..
Met de oude client 463 werkt alles prima. MEt de nieuwe client 465 (die overigens echt sneller is) heb ik soms dat hij opstart en dan geen .ini vindt waardoor gebruikers opeens een configscherm voor zich krijgen.
dit is dus duidelijk NIET de bedoeling.
Waardoor zou dat kunnen komen ? Wat mijn ingeving was dat die nieuwe client continue in die .ini loopt te schrijven/lezen en dat hij daardoor lang bezet is waardoor de client een time out krijgt met de ini lezen.
Iedere pc in het netwerk heeft deze regel in zijn loginscript staan
start /b \\filesrv1\dnetc$\dnetc.exe -quiet
De ini staat dus ook op die server en de packets haat hij op via een proxy.
ini file :
<begin>
[parameters]
id=x@x.x
[triggers]
pause-on-no-mains-power=no
pause-watch-plist=taskmgr.exe|perfmon.exe
[misc]
project-priority=RC5,DES=0,CSC=0,OGR=0
[networking]
autofindkeyserver=no
keyserver=filesrv1
[rc5]
fetch-workunit-threshold=15
<end>
Tevens draait er op die server (filesrv1) een perproxy.
Het probleem..
Met de oude client 463 werkt alles prima. MEt de nieuwe client 465 (die overigens echt sneller is) heb ik soms dat hij opstart en dan geen .ini vindt waardoor gebruikers opeens een configscherm voor zich krijgen.
dit is dus duidelijk NIET de bedoeling.
Waardoor zou dat kunnen komen ? Wat mijn ingeving was dat die nieuwe client continue in die .ini loopt te schrijven/lezen en dat hij daardoor lang bezet is waardoor de client een time out krijgt met de ini lezen.