No - not in the user profile, but in any manual invocation or your bat file for VPN users.. Your examples above illustrated a full path for Kix32 but NOT for the script, and also to a specific server. That could cause the (correct) script to not be found in specific situations. when invoking manually from \\DOMAIN\Netlogon, prefix both Kix32 and the script with the UNC path to avoid any ambiguity.
Having "Kix32.exe script.kix" in the user profile should be fine and is the correct configuration.
Did you add the shell command I recommended to check the local environment? Find anything odd? The PATH must have the netlogon folder listed FIRST during a logon session.
Your error isn't coming from Kix that the script is failing or not found, it's coming from the O/S reporting that the Kix32.exe wasn't found. This points to an AD or possible replication issue. If one server fails to fully replicate, the file may not "be" an exe even though it has that extension. In your testing, you've been specifying a single server, but logins are serviced by the first responding DC. You need to run your test against every DC. Also- be sure that your Sites are set up properly. We had a DC on the west coast that was both mis-configured and in the east coast site. It was responding to login requests at the HQ site and took a long time to process the login script - 40-seconds instead of the typical 2-3 seconds - when it worked at all. This will also show up in the environment dump that I recommended as %LOGONSERVER%.
I'd verify the Sites & Subnets first, then remove the EXE's from the PDCe and force a replication, middle of the day when logins aren't likely or over the weekend. Do the files disappear from the other DCs? Wait 30 minutes - do any still exist or reappear? For a properly configured WAN setup, replication could take up to 3 hours unless you then force the replication. (I'd still wait the 30 minutes before forcing.)
Verify the replication - run \\server\netlogon\kix32 /? and verify that they all report the same and desired version and do not report a failure of any kind.
Finally, if you aren't calling wkix32.exe for your scripts, don't put it in netlogon - its just one more file to replicate needlessly. Use one or the other - they are both the same except that wkix won't open a command window by default unless you generate output. It's designed for silent operation apps, such as Windows Services and KixForms GUI apps, or scripts that should not (and will not) display any text output.
Glenn
_________________________
Actually I
am a Rocket Scientist!
