Friday, May 12, 2006 5:44 PM
I have created a .exe that uses My.Computer.FileSystem and now receive an error "Open File - Security Warning" dialog starting:
"The publisher could not be verified."
The file is located on a Windows File Server under ADS on a mapped drive. It was created under VB2005 and the .exe was copied using Windows Explorer drag and drop to the mapped drive.
If I select to Run the file I get a security error.
Same problem happens with new Access MDBs stored on the same file server.
I have backed off all the IE zone settings to no avail. MS KB articles have been no help. ADS security properties look like I have permission to run OK.
Files (exe and mdb) run fine from the desktop.
I'm guessing somehow the files are being flagged as coming from the Internet instead of from the LAN. MS KB suggestion indicates there is a file property that appears indicating Internet origin - that is not showing up.
IE 7 Beta 2 is installed.
Please help - this error is suspending project work!
Thursday, November 30, 2006 10:35 AMModerator
That is an IE7 bug that's been reported often recently (but I doubt MS would classify it as a bug rather than a feature). When executable is not in local computer it runs in intranet context. Fixing it might not be desired (since MS thought of it as a security hole and they know much better than me) so I'd say do one of these solutions at your own risk (and hopefully helps - I haven't installed IE7):
1) Add \\server\share to your trusted sites.
2) Set security for intranet sites to low.
3) Add your exe to exceptions list (God help developers- can you imagine adding each and every test executable to exception list!).
Good luck. I hope you didn't install IE7 to your production box.
Thursday, November 30, 2006 6:04 PM
Go to User Configuration >> Administrative Templates >> Windows Components >> Attachment Manager
Add "*.exe" to the "Inclusion list for moderate risk file types" setting.
"This policy setting allows you to configure the list of moderate risk file types. If the attachment is in the list of moderate risk file types and is from the restricted or Internet zone, Windows prompts the user before accessing the file. ..."
In other words, this allows you to run an .exe from the Intranet zone without a prompt, but it will warn before running one from the Internet.
Thursday, November 30, 2006 6:06 PMModeratorIt's for vista,no?
Thursday, December 28, 2006 8:57 PMthank you this worked
Monday, June 04, 2007 8:56 PM
That worked great thanks! I couldn't find a fix in the microsoft articles on how to turn those [TOTALLY ANNOYING] security warnings off. Surprisingly, since I've installed IE7 on each computer (one at a time, testing that there were no major problems), we had almost NO problems with it. The main computer, which doesn't really qualify as a server did not get the update until recently. I had chosen to leave the IE6 alone because the user of that particular computer does not take well to computer problems, even minor ones. When they found out they could "shrink" websites for printing in IE7, I was forced to update that computer (and not being the owner of the company, I couldn't very easily say no).
I actually don't believe there were any problems until today, but I may have not been made aware until now. Whenever files were opened from the so-called "remote" location (same computer but through the network) the security warning popped up. I was reading that you can add publishers to the trusted publishers list but one of our applications that we use for our main agency management software came up as "unknown publisher" and another, although it had a cert., just came up with a different security warning. The other computers that had IE7 and WERE ACTUALLY running these programs remotely didn't have any security warnings which seems a backwards. (If that didn't make any sense I apologize, it's Monday.)
Anyhow, the above fix worked. I didn't change any security levels though, I just typed in the location of one of the files (mapped to the F:\ drive) and IE7 automatically changed the location to file://[computer_name] which fixed everything. I know about the exe exceptions list but I can never find it when I really need it so this is an easy way to go about it.
P.S. When I tried using one of my two "free emails" to Microsoft Support, it asks for a product ID (not the product key) but when you click on the link to see where to find it I only got a 403 Error...so besides not finding the answer in any Microsoft articles, I couldn't even CONTACT them....Mac anyone?
Thursday, January 10, 2008 4:20 PM
Thank you for sharing your solution. It worked great!
Sunday, September 21, 2008 6:52 PMThanks Raider74 that worked for me too !! cheers!
Monday, October 27, 2008 4:16 PMthanks raider74! perfect! :)
Thursday, April 08, 2010 1:58 PM
Your solution is still working (and still needed) four years down the line.
As posted above, it was doing so since the program's shortcut pointed to the exe's "share name" (\\computername\folder) location rather than a drive letter, and, as above, the problem was only occurring on one of the client's workstations.
...ironically, in this case, the share was located on that workstation's own hard drive.
Also, IE7 was installed, but not running and another browser was the default browser.
Thanks,Beverly Howard [(former) MS MVP-Mobile Devices]
Thursday, October 21, 2010 5:21 AM
This did not solve my issue. I have added *.exe, *.pdf, *.js etc but no luck!
I am going to uninstall IE8.
Thursday, January 12, 2012 5:44 AM
This has come up a few times for our IT department.
If you do the gpedit.msc you are effectively saying that all EXE files (or whatever file extension you add) may run from any zone without prompting for a certificate - that is, with no warning. This includes the internet.
The way we have overcome the problem is in IE 7 or 8 go to Tools, Internet Options, Security, Intranet, Sites, then remove the tick for "Automatically detect intranet network". We leave the other 3 ticks ON. You can then add server names in the advanced button, but we havent found this necessary.
- Marked As Answer by CetinBasozModerator Thursday, January 12, 2012 2:41 PM
Thursday, January 12, 2012 2:41 PMModerator
This is a better solution. I never trusted the idea to make exes trustable via gpedit.
On the other hand what we do for our products is to digitally sign it with the certificate we bought from a security provider (name would be promotion I think).