It would help when you need to sit at the machine not working properly and you want to debug the script. If I want to run the script manually and step through the commands using the debugger how will this work with a tokenized file?

Sounds like many of you suggest using an archived copy (which should be the same as on the system but you cant be entirely sure) and running it on the machine in detokenized format. That means either the script must be modified to run from the users system (instead of the shared location it was originally on) or I have to store the detokenized version on the central location and point the machine to it. I wont have access to the same resources at a users desk as I would at my workstation so I have to go back to retrieve this archived copy.

What if the problem with the machine was that he didnt get the latest version of the script. Preventing me from detokenizing and comparing agaisnt the standard copy makes troubleshooting a little harder. I could do a CRC check against the two to verify this but this again takes another application I may not have access to at a users desk.

All of this adds up to more time troubleshooting. If I have access to the tokenized file and a kix executable I should be able to extract then debug the script at the location.

I do have a use for a script that is unreadable. Engineers love to circumvent our standard software installations, virus scanners for example. They will reverse engineer the method to detect virus scan installation and create dummy positives. If I could hide this script from them it would be very hard. This data would be stored in a second script with the "do not allow detokenize" enabled.