Welcome to KORG!

As the owner of the login script, my profile is usually different from all other users - where other users have "kix32.exe kixtart.kix", mine is "kix32a.exe kixtart.kix". When I update Kix, I copy it to "kix32a.exe" so I get the new version first and verify that it works. After validating the operation, I copy Kix32a.exe to kix32.exe so both versions are the same file, not just the same version. This should let you check independent of the users.

Also - related - it's always better to put the "old" designation in the middle of the file name, not change the extension. This way, you can find the original version by its name OR extension, and having the OLD between the name and extension is pretty obvious - "Kix32.OLD.exe", for example. I also maintain a copy of every version of Kix available in my tools directory - in my PATH - so I can run any version at will - these are named "Kix32-4.xx.exe", where the "xx" represents the minor version.

Other things to check:
  • Is your login script tokenized? Re-gen it if so.
  • Delete all copies* of Kix32.exe from all DCs, then place the Kix file on one DC's netlogon folder. Verify that it replicates to ALL of the other DCs. *Make sure you have a local copy of your original Kix 4.53 executable.
  • Add "Shell %COMSPEC% /c Set > %TEMP%\Env.txt" to the login script - check the file. Does the environment look normal? Is the NetLogon folder FIRST in the PATH statement? If the PATH isn't set properly, it won't find the Kix32.exe file.
  • Do you run AV on your DCs? Make sure the NetLogon physical path is excluded, or at least, exclude "Kix32*.exe" from AV on all systems.
  • Try running the script after logon, via "\\YourDomain\Netlogon\Kix32.exe \\YourDomain\Netlogon\scriptname.kix" - does that work? If so, I'd be focused on the session state at logon time - path, env, etc all set correctly and all necessary files replicated in all netlogon share folders.
  • Modify your account as I mentioned above to use the new Kix version - log on/off of a machine a couple of times, then try a few other machines to verify before updating the rest of the users.
  • Give my logon script a try, even if you only invoke it to define a command that runs your logon script. When invoked with --D, it creates a TON of diagnostic information in the user's %USERPROFILE% folder. This has helped several organizations identify corrupt platforms and faulty replication in their environment. If you want to try this and have more than 4 DCs, PM me and I'll give you a 30-day trial license key. The script is free for environments with up to 4 DCs.
Good luck! Let us know what you find.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D