How It Works
Most of what the Documentor script does is fairly plain and unsophisticated. The UI is completely dynamically generated inside of Internet Explorer using JScript; there is a lot of similarity between JavaScript (ECMAScript) and JScript (Windows Scripting Host and ASP). I'm taking advantage these similarities to generate a UI and avoid the encumbrances of security surrounding MTH and HTM files. There was, for a short time only, a version of the script that leveraged loading and external HTML file that was just too painful to deal with.
The data gathered by the script is done through WMI queries which are basically executed remotely over RPC connections. Because of this there is a little bit of quirkiness in credential handling that I am taking advantage of. When you bind a WMI connection to a localhost, that is the computer you're executing the script from, you are unable to pass credentials to this system and any attempt to do so whether they are correct of not will result in an denial of access. Conversely connections to remote require a username and password and a connection cannot be established established with out them--this behavior is why the script is able to scan a local machine without credentials being added, and contrary what may seem intuitive does not perform much of its work assuming the identity of the user executing the script.
Even in cases where the script is doing work like extracting product keys and listing installed patches/applications, WMI is being used to access the registry remotely.
In the case of the Excel and Vision the script manipulates these installed applications and plants this data into the app interactively. If you alter these applications while the dump is occuring you may corrupt the output to the applications.
In the case of txt and xml files, the data dump occurs natively within the script and a file or the files is deposited in the same folder the script is executing from.