yep, same here: On the regular client PCs, nothing is installed, everything is run from the netlogon share (no, not really - due to network access, data transfer and execution speed issues, the login.bat caches the KIX32.exe (plus everything else) in a local directory via robocopy, and then runs everything from there if caching was successful. But this cache verification is done every time before the kix-stuff is called, so it's always identical to the items on the netlogon share.

As in your case, the admin/developer's PCs do have access to all versions of KIX32, but usually, everything is done using the production version named just KIX32.exe.


If you or anybody likes, please give it a try, to see if you get the same bahaviour as me:

On any PC, create a directory which contains a directory (like this: D:\data\kixtest) which contains the KIX32.exe and the KIX script that does the ADO AD access.
Then, share the D:\data directory as \data. From a remote PC, call the kix32.exe adotest.kix, to verify that everything works and you get the content of the AD attribute.

Then, revoke as much rights as possible from D:\data only, leaving at least read access (break ACL inheritance here) on D:\data\kixtest. Now, when running a
dir \\computer\data
you should see no files or dirs at all.
When running a
dir \\computer\data\kixtest
you should see the files, and be able to access them. If you can't, grant just enough rights to achive the above situation (but the \data diretory content itself must be without rights)

Then, run the kix script again, using a Win7 client, and it should refuse to list the AD attribute content. From a WinXP client, everything should work in both cases.

I know that this is perhaps not a regular case of a netlogon share, but you never know ... and it's strange anyway (or might have other side-effects) !

Regards,
Andy