Need to Install Program to Standard User Windows XP as that User, not Administrator

Two suggestions -

1.  Install the program to the ALL USERS profile instead.
2.  Code your program so it checks for the existence of the data you need - if it doesn't have it, then it creates it when it's first run.

Can you temporarily grant the user Administrator or Power User rights?

"But when we do the run as and select an administrator account it installs everything to the administrator's profile, not the standard user's."

This is expected behaviour. Why does the app need Admin Rights to run? Is it trying to update a .log file/reg key etc? If it is trying to modify a .log file in ProgramFiles\YourApp, then that requires Admin Rights even... Might be all it needs.....

Find out where the permissions are too restrictive, and adjust that so the app runs for ALL USERS......

Process Monitor
http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx

Set the filter at the top to Include "Result" is "Access Denied" then "Include", and then try and recreate the errors by launching the app as a limited user... Then go look at the logging, and it will tell you where the permissions are restrictive. Once you open those up, keep retrying until you get the desired results....

Leew:

I don't want it to install to the All Users profile because I want the data to be local to the user themselves. In addition I have it in the local settings because the database becomes very large and I don't want it to go between roaming profiles. The program comes with data preinstalled into the database, and some other files that go into the local folder which it uses to generate stuff for the user. The reason I stopped using the Program Files folder to hold all my data files is because I wanted it to be per-user and then finally because in windows vista and 7 the program files folder is locked down, so I have chosen to seperate the executables/dlls and the user data. Creating these files after the program is installed is not really a feasible solution, since the db comes with data already in it and the other files are web page reports and outlines and things like that.

Ultimately I am looking for a way to grant the standard user the ability to install the program. Currently the install will fail because the user has no rights to write to the program files folder. Switching to an adminstrator account to install results in all the data files being put in the administrator's local data folder instead of the user's.

I was looking at an article I thought might be promising..
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/runas.mspx?mfr=true
but I'm not really sure from reading it if this will work and from trying to test it, it's not seeming to do what I'm wanting. That is runas <user> with <administrator's permissions>.

GregPoole:
Yes I want to know how to give them administrator rights over the installer program specifically so we can instruct our customer's admins how to install the program on their worker's machines (who are not administrators).
I suppose advising them to temporarily raise the user's status would work and then get rid of it after the install, but it would be better if there was simply a command one could run to do that. Any ideas? Currently my best method is simply to install under the user's profile but to C:\<My Program Name>\ instead of the Program Files folder. This works, but it leaves my executables open to being modified by viruses and is therefore not as safe.

Thanks! ~Jeffrey

johnb6767:

the application doesn't need administrative rights to run. However, the installer requires administrative rights to install to this folder
   C:\Program Files\Foreclosure Update Pro\

The user's data folder where the other files must go is
  C:\Documents and Settings\TestUser\Local Settings\Application Data\Foreclosure Update Pro

The problem really is that when I am not installing as the standard user the data files are not going to the correct folder as per the user who is going to run the program. Like I was saying if I just install the exe to somewhere besides the program files folder this all works, but I didn't really want to do that. I'm surprised microsoft didn't give windows xp a way to do something that works easily and well in vista and windows 7.

Thanks! ~Jeffrey

> I'm surprised microsoft didn't give windows xp a way to do something
> that works easily and well in vista and windows 7.

Consider that Microsoft ADDS features to new OSs - so the fact that it's not there in a 9 year old operating system but is in a 3 year (and 1 year) old system is not surprising at all to me.

What about my second suggestion?  Put another way, WHY does the program have to setup the USER portion to start with?  Why can't it setup the user portion AFTER?

What happens when my company uses your program and Joe installs it on his PC.  2 months later, Joe is promoted and I get his old PC... so now I'm logging in... but because your program only sets up the user when it's installed I have to reinstall it?  If that's the case, I start thinking this was poorly written.  (MY OPINION - but if my opinion is valued in the company and my boss here's it... )

Leew:

Yeah I'm not really surprised about XP not having the feature, but I was kinda hoping there was still a way to do it.
Really, the only reason I care about how it works on XP is we do have customers that still use XP. I imagine in a few years it won't matter.

The truth is the program used to be designed for all users, and everybody would share the same database on the same computer. There are a variety of reasons why it's better when done for a per-user basis for this program in particular.
Another feature of the program is whenever we release an update it takes all the data from the old db and brings it into the new one. So some files are even pre-existing on their computer.
Further, there are easy options to export the data out and reimport it for newer/different users if that is desired (such as what you're talking about).

The program isn't badly written, I promise - it is designed to work that way.

So what I'm asking is really simple.
Is there a way the administrator of the computer can choose to run the setup.exe program as the user with elevated administrative rights on windows XP?

Thanks! ~Jeffrey

> The program isn't badly written, I promise - it is designed to work that way.
Maybe... maybe it's done fantasitcally well and you should work for Symantec (they need all the GOOD programmers they can get... seems they have very few), but PERCEPTION is key.  If I'm the user and I have to reinstall the ENTIRE program to setup my own database, I may view the program as poorly written.

> Is there a way the administrator of the computer can choose to run the setup.exe
> program as the user with elevated administrative rights on windows XP?
Not that I am aware of.  That's why I'm trying to get you thinking about alternatives.

I am curious why you are still not addressing my 2nd point.  
I'll rephrase.  Why not have the program check at launch if it has been setup for the user.  IF NOT, then setup the user.  This removes the problem AND allows multiple users to access their own data without a fresh install for each user.

So far these are the temporary solutions I've got.. some are better than others.

1. Upgrade the user's status to administrator or power user such as GregPoole said. Install the program and then drop the user's account level back down.

2. Install the program to C:\Foreclosure Update Pro\ as the standard user and then run the program from there.

3. Do step 2, but after installing move the folder into the Program Files folder (as the administrator)

4. Install as administrator and move the data files folder to the user's equivalant location. Maybe this one could be done programatically for the install program. The setup solution includes the main executable, and then a compiled installer dll that is in charge of launching the program after install. This program could be used to move files around once the program is installed I suppose. Maybe it could detect the user accounts on the computer and offer a list where the administrator can choose which profile to copy the files to.

5. Change the way the program installs to the all users folder, verify that roaming profiles don't copy the db back and forth (as it becomes rather large!), change all references in the program to point to this new location, verify that all 3 versions of windows work properly with using the all users folder. Test rigorously if multiple users on the same computer can all edit and change records in the db concurrently (might be possible in .net since it uses the oledb and disconnected datasets instead of the old adodb) without creating errors in the program, and add days to the development time just to make someone on experts happy..

6. Maintain and produce two seperate versions of the program, one for XP and one for Vista/7.

When it all comes down to it, creating the data files as the user starts the program could be possible but would be easiest accomplished by copying them out of some sort of standard location where the program just keeps them handy. There's an icon file, two html outline files (I use them to generate html reports in the program), an empty upgrading database that always has the most current db configuration, and then a db which contains all the data that the program comes with.
Once the program installs if there is an older database it uses a copy of the empty upgrading database to bring in the data from the old db, otherwise it simply uses the pre-made current version database that contains the most current data for the user.

But there are multiple files that come with the program that instead of recreating these, it would be a /ton/ simpler to copy them into the required location from somewhere else, perhaps on the program launch and not the install. What you are saying about doing it on launch might really be the right approach.

The main reason that the data files are seperate to each user is mainly that I don't want two users changing the db at the same time, if they are sharing a computer. (For example if the program is installed on Windows Server 2003). The main reason I wanted them in the local user's application data has to do with the stuff I read about Roaming when I was doing research on how to set this up. The database is too big for using on a Roaming profile. The program does contain easy ways to move your data around
if you were for example to get Joe's computer and need to reinstall.

I don't know. I definitely gotta ponder the ramifications of any changes to the way I'm currently doing it before going through the work to change it, because there actually is alot of work that would have to be done to redesign where everything goes and the installer programs and all that. I was really hoping I could just have it install to the right folder, that would've made my life easy.

~Jeffrey

Leew:

So what you're saying is that I should, for example, install my basic files to a publicly accessible location, something all user accounts can access, and then when my program launches (it will have standard rights at that time) have it look in the folder..

  C:\Documents and Settings\TestUser\Local Settings\Application Data\Foreclosure Update Pro

..And if the database is there and currently versioned, then the user has it installed. Otherwise, copy the basic files the user needs out of, for example the application data for All Users, and into the local profile.

So the basic program still operates as before, but whenever a new user runs it, give them a local copy of the db as necessary.

I think that's what I get out of what you're saying for how to do this. Does this sound like it'll work for windows xp, windows server 2003, windows vista, and windows 7? Is this what you would do?

Thanks!~Jeffrey

It's a common misconception that Windows 7 is alot different then Windows XP but really it's not much different when it comes to permissions... The only difference is that when you installed windows XP you were given an administrator account by default and almost every user used that account that simply meant that all process that launched had administrative tokens. The only difference in Vista and Windows 7 is that even if your an administrator account the process actually runs in the users session. This is the same as a limited or standard account on Windows XP and nothing more than that. It  boils down to this  Vista/ Windows 7 is just like running a process on a Windows XP standard/limited account at all times until you elevate the process.
 
 

Exactly.  Otherwise, as you've described it's operation, MY VIEW is that it's providing at the very least a poor user experience AT LEAST to subsequent users.  

I'm no programmer, but I play one in my mind... and in my mind, adding a check for the DB should be simple enough and moving the setup routine for the user specific stuff, if the app is designed modularly, should be pretty simple as well.

Wandervogel:

I have been testing the command thing you were talking about and it seems to install fine (but for whatever reason the shortcuts for the program are missing) and all the essential files in the program are going to the right place.

This is the command-line I'm using:
RUNAS /env /user:<workcomp>\<myAdminUsername> "\\<serverComp>\d\Michael's\FUP\Setup.exe"
with of course the proper things subbed in.

So I'm testing it just a little bit more, but I think this is part of the answer I was looking for, so I'm pretty encouraged..

Thanks! ~Jeffrey

Both those ideas were workable answers, so I'll take those.