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

I distribute a utility for developers which is designed to reside on a server share and is executed from the server on the local PC or Terminal Services/Citrix session. It does not require any admin privileges. There is no install process other than dragging and dropping it on a server share. It is digitally signed.

I'm told some IT depatrtments don't like having exes on the server share in this fashion. What can I do to help explain to IT departments that my utility is benign.

Added

I'm the developer of the tool, Auto FE Updater, and it's deliberately designed to not require admin priviliges. It's a stand alone exe with no installation dependencies other than a few config (INI) files created by the developer using the tool.

This tool is executed by the users for brief moments of time while it checks to see if there are any updates to the Access front end database and associated files on the server. The developer using the tool might run it for two or five minutes while updating settings.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.