1

This question is a follow up to Why do some admins dislike exes being executed from a server share? I have developed a utility which makes life much easier for Access developers. One option I will be making available, due to the feedback in the afore mentioned link, is making an MSI file available for install on the client systems by the IT department.

One option I was thinking about was to give the developers the ability to copy the exe from the server share to the users Application Data folder. Another possibility is an exe/msi which the user could execute which would also place the exe in the users Application Data folder.

Comments?

I notice that Google has installed Chrome, Google Talk and a whole bunch of update exes and dlls in the App Data folder. As well as a few other programs. Not that I'm trying to use that as an excuse.

Added

I've had comments from developers stating that they only need my utility on a small subset of the systems in use. IT departments will spend months and months evaluating things and don't want to deal with such programs unless they are part of the corporate imaging systems. Also the developers may want to push out updates of my utility a lot quicker than the IT dept will deal with it.

Community
  • 1
Tony Toews
  • 352
  • 1
  • 10
  • look at the current sysinternals tools they don't require local installation you can run them directly from the sysinternals website. Its true they make mods to the local files\reg system but I think only within the current users space. Quite frankly I'm not sure that ms specifies the locations of exe's. I think the only thing they require is an uninstaller. – tony roth Sep 06 '10 at 22:19

4 Answers4

5

Well, in the (quite common) case of a networked home folder, you still have all the problems associated with starting from a network share, because in fact that's what happening.

Honestly, I don't get it. There are certain ways programs are supposed to be installed and run on the Windows platform. Why don't you just follow these proven methods? Really, at great deal of the problems I face with Windows apps can be traced back to programmers who either don't know how windows programs are expected to install and behave or who think it's to complicated and take some shortcuts or something like that.

(Granted, I often deal with scientifc programs that are written by experts in their domain who don't care at all about the platform or even try to write platform independent, but still).

Sven
  • 97,248
  • 13
  • 177
  • 225
  • 2
    True dat, Way too many problems come from programmers being lazy and/or creative in how they do things. Build your MSI, put the program in %ProgramFiles% and user configuration data in %AppData%. These are simple rules put together to make everybody's life easier. Why screw with things that work and work well? – Richard June Sep 06 '10 at 21:24
  • Because those Windows conventions are oriented (still!) to a 1980's single-computer environment. They make updates, patches, version checks, etc. much, much more complex than necessary. Imagine if you only needed to patch a half dozen servers on Patch Tuesday, instead of 3,000 desktops. – mpez0 Sep 07 '10 at 01:13
  • No. Because today, Windows user profiles are adapted to networked environments. It's (to some extent) a problem of misbehaving software that desktop management is so complicated. – Sven Sep 07 '10 at 06:55
1

I second SvenW's comments, the comments in the other thread and would like to add a few.

What happens if the user has a roaming profile and I'm trying to install the MSI out via GPO? Does this mean the user gets it or the machine? Whats the case with multiple users using the same machine?

What happens if the profile moves from a computer where they are supposed to run things to one they aren't like a print server in a Uni lab? Will the application follow?

How do I control versions if for example it was installed on another computer, the profile migrated to a new machine? The msi won't be there in a consistent state and when you release a new version I might not catch it or something may break?

There are good security reasons for making sure your executables and your data are completely separate, additionally in a number of environments you may not be able to expect the user has execute permission to their appdata folder.

I don't know how big your app is but do I really want a backup of it for every user when I run the backup jobs for the profiles?

Your application sounds really portable and self contained, thats great and there are work arounds to each of the above. But why rock the boat and force it somewhere it shouldn't go when it's just as easy to put it where it's expected? I can't speak for anyone else but the above cases make things fall into the "unpredictable" basket and that isn't great.

As to Google, it depends on your usage case, they are pushing to a lot of home users maybe who don't care? You sounds like your pushing to corporate IT and it can't hurt to get on the good side of the people who will be testing and deploying your app. They will spend less time thinking of ways to replace it if yours is stable, predictable and works like every other one they have.

Antitribu
  • 1,709
  • 3
  • 23
  • 37
  • FWIW my app is about 1.5 Mb in size and won't grow too much over the years. Maybe double in size but that's about it. The configuration files are only 1 kb or less in size. – Tony Toews Sep 06 '10 at 23:29
1

Also common in corporate Windows environments is Software Restriction Policies. This underutilized feature of modern Windows allows the administrator to allow or restrict executables from running based on the path or even based on a cryptographic signature. I routinely only allow executables to run only in the windows or program files directories. Otherwise users could download to AppData or even their user directory and basically be running anything. What's the point of forcing users to be limited users if they can run any EXE they want to? I make exceptions for GoToMeeting, but not as of yet Chrome.

Knox
  • 2,453
  • 2
  • 26
  • 33
0

Yes, I mind. And the reason is simple....roaming profiles.

While your app might not be that large, add in all the others who decide that AppData is the place to do their installations and profiles get huge...users login times increase...and than we're to blame for slow systems/network (yes this goes for those who should know better too).

My soon to be released AppLocker policies will kill these examples of bad Windows programming so all is not lost.

edusysadmin
  • 536
  • 2
  • 8