The problem you describe is caused by the KXRPC service not running properly on one or more of your logon servers.

Please check the PDC and all BDCs and stop and restart the KXRPC service on all of them if you have to.

ps. I would not recommend copying the script to the clients. The KiXtart executables okay, but not the scripts. Your looking for syncronization problems that will drive you crazy.

Make sure the PDC and all BDCs are running the same version of the KXRPC service also.

Please post an update on your findings.

IF (@INWIN = 1)
$CallDrv = (SUBSTR (@LDRIVE, 1, LEN (@LDRIVE)-1)) ; REM ** Removes trailing '\'.
ELSE
$CallDrv = @LDRIVE
ENDIF

CALL @LDRIVE + "\myscript.kix" (this runs for NT just fine, fails for Win 9x, but this method only fails for Win 9x systems after another script has run just prior to a script call. Ex:

Line 1-2:
COPY @LDRIVE+"\myscript.kix" "c:\myscript.kix"
CALL "C:\myscript.kix" (this works fine for both platforms)

Line 3:

CALL @LDRIVE+"\myscript2.kix" (call fails at this point)
Kix errors stating it cannot find the script this is for Win 9x systems only...NT/2000 call and execute the script just fine.

Maybe the environment is losing the handle to the file.

Just for trial, try keeping a copy of all the files on the LOGON share and calling all of them from the Logon share and see if Windows 9x still has a problem finding them.

Do they work if run from a command prompt on Win9x instead of the logon script?

You could also try KIX32.EXE /D yourscript.kix

Then see if anything more specific comes up in the code. Maybe a run or shell statement that Windows NT/2000 is okay with that Win9x is not.

quote:

---

Theoretically, there is no limit to the number of scripts that can be nested. Obviously, the practical limit on the number of scripts you can call is determined by the amount of available memory at the time KiXtart runs, the size of the scripts, the number of variables defined, and so on.

---

However, keep in mind we are supposed to be helping the users get their job done, not neccessarily making ours easier (if ours gets easier during the process that is good though) if our scripts are so long and slow that it takes the user 5 minutes to logon, how can we justify that we are really helping them?

I reduced our main logon script from 2,300+ lines of code to around 200 and call only a couple of smaller scripts now depending on conditions. This has cut logon speed in half which most users appreciated.

[ 07 September 2001: Message edited by: NTDOC ]

Now, can the macro value change - I do not know. I belive when run this dynamically checks current setting, so if invoked 2x in script, KiX checks 2x to see what is @LDRIVE. Can some process be deleting the 'Z:' drive mapping?

Try a simple
IF @INWIN = 2
? @LDRIVE
SLEEP 3
ENDIF

Bill

[ 07 September 2001: Message edited by: bleonard ]

"PDC" is Windows 2000 but most other DCs are NT 4.0. Presently we are running in a mixed mode as our AD is not yet in place. The master DC is running in NT emulation mode.

I'm interested in your comment about 'provider order'; can you elaborate?

Regards

Geoff

code:

---

Known Problems of KiXtart on Windows 9x
The following is a list of known issues that may be encountered when using KiXtart on Windows 9x:
If KiXtart is used on systems that are configured to run both Microsoft Networking client software and Novell Netware client software,
compatibility issues can cause KiXtart to fail to retrieve network information and/or find any script. 
If these problems occur, make the following change in the registry of the affected clients:
HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Services
           MSNP32
              Network Provider	CallOrder	[00 00 00 40]  >change to> [00 00 00 20]
           NOVELLNP
               Network Provider	CallOrder	[00 00 00 20]  >change to> [00 00 00 40]

---

[ 11 September 2001: Message edited by: LLigetfa ]