There are a couple of considerations here.

I tokenize many of my scripts, mostly to prevent unauthorized modification. Any script that we support commercially is tokenized. The performance difference of tokenized/plain text in most situations is negligible. You might see worthwhile improvement of tokenized scripts over low-performance WAN and dialup links, although these are becoming increasingly rare nowadays.

With KGen's BAT reformat capability, I also use the .BAT extension for many Kix scripts that are NOT tokenized, allowing me to distribute the Kix script and a copy of Kix - they both run from the same folder without any prep. .BAT is a normal extension to execute from the command line, so this form allows me to avoid having to register any extensions.

I do install Kix32 locally, but only on Servers and Admin workstations, where we rely on many of our administrative scripts to be available - Wus/WusSvc, tsAdm, LogMaint, Cleanup, and several other diagnostic and administrative tools.

As for installing Kix32 and scripts on every workstation, this quickly becomes unmanageable as Kix and the scripts are updated. Many of the sites I support have >5000 workstations and as many as 30,000. Managing the updates on all those compared to Kix32 and the login scripts on the NetLogon share is a no-brainer in favor of a single (replicated) location. The one partial exception to this is our Universal Login Script, which caches the INI file on the local computer. We found that repeated queries to the INI file over the LAN or WAN impacted performance. With the INI file local, it was cached in memory and was very fast. The script does have some overhead in determining if the local copy is current and consistent with the Netlogon version, but again, negligible.


PS - Grave robbing is right! I think that 10 years is the record for necro'ing a thread! \:\)
Actually I am a Rocket Scientist! \:D