Why do some admins dislike exes being executed from a server share?

Here are some reasons why I don't like loathe executables getting launched across the network:

• Client locks prevent the tool from being updated until there is a point when nobody is executing the file. This eliminates the concept of on-demand updating from the user perspective
• Server reboots become necessary in some instances when dangling locks occur due to a client falling off the network or a process dying
• Extra bandwidth overhead for the network
• Extra load time for the client, this often comes back as a perceived slow network

EDIT:

Your added information makes it even worse! Now there are other external dependencies that add further risk of failure.

EDIT 2

Regardless of what is going on in the processes, the best thing to do is to launch them from a local disk. In over 15 years of IT I have not seen any kind of process where the benefit of launching it across a network share outweighs the risks that I've listed. (I'll qualify that by saying in a standard Windows workstation / file server environment; I don't have the *nix experience to make that claim there).

As far as your calls to standard Windows API's, that's all well and good. Yes, they are fairly stable in and of themselves. Putting Access in the mix opens up more. But the process is still being launched across the network and the risks I, and others, have already mentioned still apply. A small process is still a process and it's still vulnerable to instability It's simply not worth bringing an entire server down when one client process goes haywire if it can be avoided by moving the binaries local to the client.

Yes, smaller processes that have a shorter lifetime have less risk of failure and thus less risk of causing the bad things that we've described. I'm fairly conservative in my administration beliefs, though, so I wouldn't want to see it in my environment. And maybe it is fine in your environment, I don't know.

Despite how I feel about my ex cough, I don't want to see her executed and I'm an admin.

Having said that, you haven't given us much background, so I'll have to make a few assumptions.

I can't tell you specifically why some admins don't like .exe's on their shares. There can be installation problems when you launch executables from server shares is a for instance. You also make a pretty big assumption that your executable doesn't require any admin rights run. How would you know?

I will tell you that if you are in the business of selling programs, in a Windows environment at least, it's much more admin friendly to distribute your programs in msi format. I can't imagine that they would have qualms about having msi's on their server shares.

Updated to add:

Tony, you will find as time goes on, if you haven't already, that more and more environments are feeling the need to be locked down. Whether legally or not, it just makes sense in this day and age to do that. While the time invested in making your program as amenable to that scenario as possible can be great, my believe is that it will pay HUGE benefits in the long run (while trying to keep the sysadmin OUT of the loop will not).

Sysadmins are not in the business of keeping people from doing their jobs. Quite the opposite. If there is anyone you want to have as a friend on the other side of a tech support call, it's the sysadmin trying to get your software to work. Making your software easier to deploy and update for him/her is where you want to be.

There are numerous reasons why an admin would prefer not to have executables on the network, as others have listed.

What can I do to help explain to IT departments that my utility is benign

Nothing. Their policy is set, and you as an outsider have no control over it unless someone important enough within the company needs (or really wants) your software on the network.

Some admins don like executables being run from shares just because Windows warn about this. I think it's a Windows protection to avoid other programs (like viruses) running remote exes without authorization, but that's other case.

However there is no big problem to do that. What the computer actually does is reading the exe into memory and running it.

However there are some programs that read files from it's exe directory and that will probably not work as expected when being executed through a network, mostly programs that has external dependencies like shared files, components, etc. The program will just crash.

Personally, I don't allow "remote" exe's because if I allowed it, the user's would be able to download anything which doesn't require an installer and run it on the network. Un cool from a security perspective- I only allow apps to execute from "C" and the user has read & execute rights to "C".