XP user profiles and program installs?

[Busie23]

Ok, I use several large scale scanning programs at work and they are a real pain to install in general, but throw XP in the mix and the crap hist the fan. What is the deal with this profiel stuff? Half teh time i install something logged in as the admin and then it won't run logged in as a power user, or any other user for that matter? Is there a trick to doing installs on XP? I have used google to find something on this but have had no luck?

Help!

 

[prosaic]

From your brief description of your problem I'm not quite sure what's going on. I'll try to give you enough info to help you figure this out. Forgive me if this is at too simple a level. I'm just not sure where you're starting from.

In NT-style Windows operating systems each user has his own profile. That profile not only contains that user's data, but also his own version of the Start Menu. When you install software under such an OS that software may, or may not, be using an installer that is aware that the target system has multiple user accounts / profiles on it. If the installer is aware, it will ask you if you wish to install the program for all users or just for the current user. If you answer all users, it places the program shortcuts in the All Users profile's Start Menu. The contents of that Start Menu show up in the effective Start Menu for every user on the system. If you answer current user during the installation, then the shortcuts are placed only in the Start Menu for the current user. However, if the installer is unaware of the multiple-user-profile nature of the OS, it will just install the shortcuts (usually) into just one profile. Depending upon the way the installer was written and the way the target system environment is configured the shortcuts could wind up either under All Users or under the current user.

If the above is the problem, you fix that by going under the "\Documents and Settings" directory structure (in Windows 2000 and XP) and under the \%SYSTEM ROOT%\PROFILES directory structure in NT 4 and earlier and making copies of the needed shortcuts under whichever user profiles' Start Menus require them.

If the problem is NOT that the shortcuts are not showing up under your other user profiles but, rather, that the shortcuts are there but that the programs simply won't run, then that would likely be a permissions problem. Some programs perform operations that require higher user systems permissions levels than other programs. A text editor program doesn't try to exert much in the way of device control, but a DVD burning program certainly does. It is typical for lower level users on NT-style operating systems to be unable to write to removeable media or to install or directly control hardware. Sometimes you can enable lower level users to have access to these functions through judicious (we hope) manipulation of the Access Control Lists and / or policies (local or domain, depending upon how the system is set up). Another ploy used commonly, especially with Windows XP, is to allow a more limited user to run the program under the credentials of a user with higher system permissions levels. The RUNAS feature in Windows XP has a /SAVECRED switch that enables you to give this power to limited users without giving them the password for an account with higher permissions levels. RUNAS also exists in Windows 2000, but that version doesn't have the /SAVECRED switch, so is more suited for occasional use by an admin when he just happens to be logged in under a lower permissions level account to save him from having to log out and log in to get the permissions he needs.

- prosaic

 

[dbwillis]

I always create a 'setup' profile..then install under that ID and then after installing the apps and configuring PC..log in under the admin account and copy the setup profile to the Default user profile...then everyone gets the same profile..same start menu....but I dont think that helps if your apps wont run because of a permission issue

 

[Busie23]

Thanks for the in depth description Prosaic. That isn't really the problem, but your info helps out as I'm very new to XP, etc. It's definitely some sort of sharing problem that I'm running into, but I can't get it figured out. Maybe certain dll's need shared, etc?

Anyways, I am trying to run a large scale, very expensive, PDF OCR'ing program on a win XP professional machine on a NT network. When I did the install there was no prompt etc, for "all users" or "one user", etc. Come to think of it have never seen that before with programs that I have installed on these XP machines. The main program that comes to mind is Adobe Acrobat and that didn't prompt for anything about users. Everything else like office, etc came pre-installed. Other large scale scanning programs have also given me trouble but eventually I got them to work by messing with the permissions, but I wasn't really exactly sure what eventually solved the problem?

I get the power user, user, admin, stuff and thought that installing the program as the admin and then logging in as a power user would work but it doesn't. I get funny errors, which I currently don't remember. Then I set the permissions for the install directory to allow that power user full access. That still resulted in the same error message. So I looged back on as admin and ran the program and it worked.

Then I bumped up the power user to admin level and logged back in under that name and the program worked. So apparently, someone with admin rights can use the program, but a power user can't. i messed with the permissions on a few other folders but still could't get it to work when the other user was a power user?

I hope all that makes some sense! Also, I'm not to concerned about the shortcuts showing up in the start menu, because the programs are showing up in start --> prgrams --> OCR program, and I just send that to the desktop. Its not like I'm rolling this out on multiple machines or setting up a machine with numerous users. Basically it will be used by the admin occasionlly and then looged on as the power user and running the prgram as a service in the background all of the time 24x7.

I have searched for some good articles on the XP profiles, sharing, permissions, etc. but haven't found anything really good yet. Anyone know of anything off teh top of your head that is a good read? Any good books? Or does it sound like I just need to learn Nt based stuff better before I mess with this stuff?

Thanks!

 

[dawks]

The differences between Windows 2000 and XP in this area are very small, so if you have experience with 2K, you should understand relativly easily whats going on in XP.

When the application you are installing asks if you would like to install for 'All Users' or 'One User', Its refering to if it should install Start Menu Items and desktop items on all users on that computer, or just the current account from which the program is being installed. ie, If your Jimbo, and you choose, 'One User' it will install the Start Menu Items in C:\Documents And Settings\Jimbo, as opposed to C:\Documents And Settings\All Users if you had chosen 'All Users'.

As for you trying to run a program as 'Power User' and receiving errors, it all depends on how that particular program is setup. You'd have to do some research on it to see what it needs access too. For example, I was experimenting with Office XP access, and tried to give Users only Read access to C:\Windows\, at which point, Office XP would just go into a continuous install loop whenever a certain user tried to run it on their profile.

Office would work, but you'd have the 'Install' dialoge box on the screen all the time. Changing the permissions back fixed the problem.

 

[prosaic]

I think you've answered you own question, perhaps without quite knowing it. Essentially, this program requires admin privileges to run. I think you will be far better off using RUNAS to enable the power user to run the program under an admin account's privileges. Messing around with access control lists when you don't understand them is a good way to break security or break the system so that you can't use it. When doing this sort of work you should always keep an exact accounting of the default permissions you found when you first looked at a directory/file structure, and exactly what you did to change it, as well as what happened as a result. If you don't accomplish what you wished by making such changes, return them to the state they were in before you began experimenting. Otherwise, you can get an unwieldy snowballing effect with changes made in permissions at various levels in the file system hierarchy.

Anyway, you can know a LOT about NTFS' granular permissions controls and still have a heck of a time tinkering around enough with the file system and registry key permissions before you get a given program to work under an account type that isn't suited for it. I know. I've done this before just for the experience. By all means do some research on the file system and the use of permissions, but handle this problem the easy way. I'm pretty sure you won't regret it.

You can go into the Properties dialog for the shortcut that runs the program and use RUNAS in conjunction with the program's startup executable. You set up that command just as though you were using RUNAS from a CMD prompt. For information on how to use RUNAS, just open a CMD prompt and type

RUNAS /?

then hit the Enter key to get a listing of the command's syntax and some examples. In particular you will want to make use of the /SAVECRED switch so that the password for the admin account only needs to be entered the first time the altered shortcut is used. If you have any difficult figuring the use of RUNAS out just post back with the exact original contents of the Target field

You will wind up with the Power User running everything except this program under his/her own credentials. But this program will run under the credentials of whatever admin account you assign in the shortcut. You don't have to fiddle around with permissions and risk compromising system functionality or security.

You might be able to do this the other way, but you might have to know a great deal about the program and exactly what places it writes to in the registry as well as parts of the file system that it uses. This sort of information is obtainable using some fairly simple tools and spending some time, but I can't imagine that there's any advantage to doing it that way when a powerful tool like RUNAS is available. I fell in love with it the moment I met it!

- prosaic

 

[Busie23]

This is some great info. I will try it out first thing tomorrow when I get in.

Our network is NT based and we are currently upgrading all of the remaining NT machines to 2K. All of our clients are 98se due to some old program we have to run until we finish rewriting it, which will be about a year or so. So most of my experience has delt with the 98 machines and a little bit with the servers, but I'm starting to do more and more with them. There just isn't enough time in the day to learn all the stuff I want?

Thanks Prosaic!

 

[prosaic]

You're welcome. I hope the information is helpful.

- prosaic

 

[Green Man]

What about a group policy? You could set a local group policy to always install with elevated privileges and then the processes would have System privilege access, or if that's too risky you could Apply the compatws security policy to an OU that contained the user groups you wanted to be able to run the programs?