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.


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.

  • Why not just make a basic MSI installer and be done with it, instead of pushing back? The free version of Advanced Installer would work fine for your purposes. – Skyhawk Aug 12 '10 at 0:57
  • Given that I can pass parameters to the MSI install this is looking like it could solve a lot of these problems. However I'd prefer to install the exe to APPDATA but judging from jscott's comments that route is blocked too. I also produce updates to the utility every month or two. Installing to Program Files requires admin privileges which then means the IT department has to be involved. Which I'm trying to avoid but not succeeding in these locked down situations. <smile> – Tony Toews Aug 12 '10 at 1:47
  • Correct. In locked down situations, the IT department is supposed to be involved. But, you certainly can provide both options. – Skyhawk Aug 12 '10 at 4:23
  • Folks, this has been a very educational discussion for me. I have no idea how I should accept an answer because they are all pretty much valid and bring out useful viewpoints. Any suggestions? Personally I'd go for the answer with the humour in the first sentence. <smile> So what's fair? – Tony Toews Aug 14 '10 at 3:24
  • 2
    I'm glad you're getting something useful out of the discussion! You are, of course, free to do with it what you will :) As far as what answer to accept, that's completely up to you. The point of accepting an answer on this site is to let the community know which answer best helped you solve your problem. Don't necessarily just go with what everyone else thinks is the best. It's your question! :) – squillman Aug 14 '10 at 15:19

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


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


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.

  • 3
    Not to mention that a network disconnect will often make the application crash, generating helpdesk calls. – joeqwerty Aug 11 '10 at 22:10
  • This tool is executed by the users for brief moments of time. The developer using the tool might run it for two or five minutes. – Tony Toews Aug 11 '10 at 22:35
  • @Tony Toews - your executable might run for a couple of minutes, but we get a bit funny because the reasons @squillman describes generally apply to executables that run for longer (say a full day). – Ben Pilbrow Aug 11 '10 at 22:42
  • @joeqwerty: true dat @Tony: doesn't matter how long it runs for, especially when you start piling up the number of people who use it at any given time. All it takes is one crash to bring a server down and that is the stuff that brings out the dark side of sysadmins. Also, see my edit. – squillman Aug 11 '10 at 23:10
  • squillman, but all I'm doing with the config files is using the standard MS API calls to read them as they are INI files. Given that those APIs have been around since Windows 3.1 days if not earlier they shouldn't have any problems. – Tony Toews Aug 14 '10 at 3:22

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.


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.

  • 1
    +1 because your first sentence made me chuckle. – joeqwerty Aug 11 '10 at 22:09
  • <chuckle> I've added some more details. I've been working with the MSI format the last few days as well due to another feature and may very well do that as an option. Trouble is I would need to someone pass a parameter to the MSI file and I don't know if the MSI file supports that. – Tony Toews Aug 11 '10 at 22:41
  • @Tony MSIs will allow you to do [just about] anything you want. Have a look into the CustomAction table's details. – jscott Aug 11 '10 at 23:43
  • jscott, yes, I was just looking at that a short while ago. Looks like that will work for my purpose. – Tony Toews Aug 12 '10 at 1:42
  • In thinking about this passing a parm to the MSI file won't work for a variety of reasons. But I do have plans in the future of using multicast addressing to allow client exes to communicate with the developers exe. The user would then run the utility and broadcast their existence. The developer would then see this new system available and tell the client exe which configuration(s) to use. Then the client exe does it's thing and is self supporting thereafter. Alternatively, assuming the utiliy is installed in the same locn on the clients the dev can email a shortcut. – Tony Toews Aug 12 '10 at 20:40

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.

  • I was quite disappointed and irritated after going throught the effort of purchasing a digital certificate and getting it working to see that Windows still gave a message. The only thing the utility does on the server is read several configuration (INI) files from the server and then copy files down from the server to the workstation. – Tony Toews Aug 11 '10 at 22:43

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".

  • But what's the difference between a user downloading an exe to a network share and to their My Documents folder? – Tony Toews Aug 11 '10 at 23:07
  • @Tony One difference: We use Software Restriction Policies to prevent EXEs running from anywhere within the user's profile. This helps stop a lot of auto-download-crapware. – jscott Aug 11 '10 at 23:34
  • jscott, I didn't realize those policies even existed. Then my utility wouldn't work at all for those servers. This then means that all software which runs on the client systems must be installed by the admin into Program Files? – Tony Toews Aug 12 '10 at 1:44
  • @Tony SRPs can be configured for either whitelisting or blacklisting. It is completely at the discretion of the admin. SRPs can allow/disallow using rules for: binary hash, cert, path or Internet Zone. – jscott Aug 12 '10 at 10:36
  • jscott, do you have a few useful URLs on SRPs? I'd like to include those as links on my website. If I just searched on SRPs I'm likely find lots of useless links too which is why I ask. – Tony Toews Aug 18 '10 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.