Well, shucks. Then you may have to do this the hard way.
Access Control Lists aren't exposed through the GUI in this version of Vista
when you're booted up normally. However, there are many ways to skin this
The first step is gathering data on the application. The technical support
people for the application should be able to tell you exactly what areas of
the file system and registry that software must have permissions for -- in
other words, why it has to be run as an admin. (They should also be providing
feedback from end users like you to their development folks that they need to
get off their keisters and join the best practices crowd.)
But I'm not going to assume that their tech support folks will be any help
at all, that being par for the course with companies that are still selling
software that requires the end users to write to protected system locations.
In that case you can download Process Explorer and / or Process Monitor from
Microsoft. My guess is that Process Monitor may be your best bet for this
job. You can start it up, set it to filter strictly for events that pertain
to the processes that are created by the errant software application. When
you run the application, as a non-admin, you should get a log of the failures
the software has as it tries to do its thing. Make sure you turn off the
logging function of Process Monitor as soon as you've gathered your data.
Logs, especially if gathering data for multiple processes, can become quite
large, quite quickly. You can make a list of the registry and file system
locations that it is trying (and failing) to write to.
After you have your list you can boot the system to Safe Mode, log on as
admin, and alter the Access Control Lists to grant write access (or, heaven
forfend, full control if it turns out that its required) to the failure
locations for the specific end users who need to run the software. Not having
any of the home versions of ANY Windows product around here I'm not exactly
certain what this is all going to look like. I seem to recall helping someone
with a WinXP system several years ago in a similar circumstance. I think we
actually saw the Permissions locations in the properties dialogs for various
file system locations. Or we may have used a command line utility like XCACLS
to modify the file system permissions. Of course you should try to make the
changes to the most limited number of file system locations possible. Chances
are that you'll be lucky, and the only real problem this application has is
that it tries to write some type of data back to its installation location
instead of to the end users profile (which is the proper way to handle things
like user settings, for instance). So you might only have to give write
permission to the installation directory of the application.
If there are restricted registry locations involved, you can grant
permissions for changing those to the end users using regedit. (If you
haven't done this before, you really, really, really want to be careful about
As you may have surmised already, this process may not be much fun. The
primary reason for that would be that you may go through the whole process,
launch the application, and then have it fail (or have features of it fail)
later on. At that point you have to break out Process Monitor again and find
out why the application is failing, and then make some more permissions
changes wherever they're required.
The other utility I mentioned, Process Explorer, can actually show you
exactly what files and registry locations an application is accessing as it
runs, but I'm thinking that this might be too much information with a scope
that's too general for this purpose.
There may be, and probably are, simpler ways to do this. This is my process
because I'm always having to make really bad software run on recent operating
systems for the company where I work as a sysadmin. I need to more-or-less
stick with Microsoft's own tools when working with Windows because adding in
extra third party vendors while trying to make crappy software work is a good
way to get finger-pointing instead of technical support when something goes
I hope this information is helpful, and I hope you'll forgive me if my
warnings about changing ACLs and registry location permissions are not
needed. I included them because I'm not sure about your level of familiarity
with this stuff.
> On Aug 2, 3:14 am, LeftFoot <LeftF...@xxxxxx>
> > ... Unfortunately, the /savecred switch will not work for Vista Home versions or
> > Starter Edition, so you're out of luck with this technique of you're running
> > one of those versions.
> Thanks for that. Unfortunately it is Vista Home Premium.