I recently encountered a script (.vbs) that automated a number of steps taken to install the necessary applications onto a fresh computer. The script would first identify if the OS was 32-bit or 64-bit and then run the appropriate script to install compatible apps. Designed with a modular approach, the 32-bit/64-bit script would launch a series of scripts for each application so it could be updated, documented, separately. Unfortunately with the move to a different server, a Windows “Open File – Security Warning” prompt showed up with the launch of every script and executable. The (nearly) unattended script had become much less useful as a result and I had to look into options to make this security “feature” far more manageable.
“Do you want to open this file?”
“While files from the Internet can be useful, this file type can potentially harm your computer. If you do not trust the source, do not open this software. What’s the risk?”
Having encountered this before, my first assumption was to check the properties of the files after the move and ‘unblock’ each file. ‘Unblock’ wasn’t an option, permissions were correct, and taking ownership of the file did not resolve the issue. A quick search of the web came up with a suggestion to use SysInternals’ Streams or Nirsoft Alternate Data Streams utilities to view and remove the files’ streams that said it was from another computer (the Internet). Both utilities confirmed that the files did not have any streams metadata attached. Another approach suggested in that thread is to compress all the files into a single .zip file and then unblock the .zip. Once you extract the files to where you want them, they will be unblocked. This took a long time and did not solve my problem.
After some testing from a different angle, I confirmed the problem was resolved when I added the UNC path of the server share to Internet Explorer’s Intranet Zone. This could be set via Group Policy but that depends on the workflow if the script is run after it is connected to the domain or before. The setting is under:
Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment List: Enabled Then click the Show button – and add the appropriate Name and Value – eg: \server.fqdn.local with a value of 1 for Intranet Zone
Finally, I found the solution that I ended up going with. It’s always the last place you look (mostly because you stop looking). Microsoft KB article 889815 discusses my exact issue. Their suggested workaround is to set a flag that bypasses the IE security zone checks while your script is running and then removes the flag at the end of your script.
'Run this segment at the beginning of your script
set oShell= CreateObject("Wscript.Shell")
set oEnv = oShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1
'Run your code in the middle
oShell.Run "c:ms04-038WindowsXP-KB834707-x86-enu /quiet /passive /norestart",0,True
'At the end of the script, remove the variable you set earlier.
oEnv.Remove("SEE_MASK_NOZONECHECKS")The other suggested workaround is to run your code using a command script instead. (Thanks…)
Fortunately, I was able to implement their suggested code and it worked to solve the problem I was facing. You are now able to run the script, answer the first prompt, and walk away for 20 minutes while the various installs progress unattended.