UAC file & registry virtualiztation

we have an app that runs as admin, writes to some LM keys and a couple of ini
files. I keep hearing about file & registry virtualiztation, but it never
really describes how to set it up, only that you can have an application
started by a standard user that elevates with admin rights. when i start the
app i see .ini files getting written to the virtual store in my profile, but
the app still crashes unless i run as admin. I found stuff on using ACT to
create application shims, but the lack of documention and a webcast that
explains how to use the tool to find apps in a domain but not actually fix
applications let me to get to the same place i started at, with a concept
that is documented greatly without actual steps to get it working. We greatly
appreciate any advice.

Hello,

Virtualization exists to allow incompatible applications to run correctly
inside of Windows Vista. If your application is running into virtualization,
its behavior needs to be modified.

Each user account in Vista is seperated from one another. One user account
cannot create or modify files or registry keys that can affect another
account. However, you should have read access to most system configuration
information (HKLM, Program Files [your application has no write-access to
this folder], Windows, etc).

The result is that your application can only write to folders that have been
set aside for the user account your program is running under - such as the
user's profile directory, HKCU, and a few other storage locations set aside
for program usage.

If your application is not an administrative program, it should be modified
to work under this environment.

Otherwise, if your application is an administrative application that needs
write-access to system configuration data (HKLM, Program Files, etc) or other
user's files, it should be manifested as requiring administrator or needing
the full rights of the user who is logged in.

Manifesting your application in this way will cause Windows to prompt the
user for permission to use administrator powers everytime that it starts.

If your entire app doesn't need admin permissions, only certain parts, you
should seperate those "needing-admin" chunks of your app into secondary apps
or COM components, and only manifest those apps as needing admin - this way,
your program can be run in non-administrative mode and will only ask for
admin rights when it actually needs them.

This document goes into much more detail

http://www.microsoft.com/downloads/d...displaylang=en

- JB

Little bit of clarification here, im not a developer, its not my app. I dont
have the ability to change it so that it can run under the standard user
account. Microsoft documentation says "In Windows Vista, many legacy
applications that were not designed to support standard user accounts can run
without modification, using the built-in file/registry virtualization
feature". How can this be setup? and if its automatic why won't the app run?

"Jimmy Brush" wrote:

> Hello,
>
> Virtualization exists to allow incompatible applications to run correctly
> inside of Windows Vista. If your application is running into virtualization,
> its behavior needs to be modified.
>
> Each user account in Vista is seperated from one another. One user account
> cannot create or modify files or registry keys that can affect another
> account. However, you should have read access to most system configuration
> information (HKLM, Program Files [your application has no write-access to
> this folder], Windows, etc).
>
> The result is that your application can only write to folders that have been
> set aside for the user account your program is running under - such as the
> user's profile directory, HKCU, and a few other storage locations set aside
> for program usage.
>
> If your application is not an administrative program, it should be modified
> to work under this environment.
>
> Otherwise, if your application is an administrative application that needs
> write-access to system configuration data (HKLM, Program Files, etc) or other
> user's files, it should be manifested as requiring administrator or needing
> the full rights of the user who is logged in.
>
> Manifesting your application in this way will cause Windows to prompt the
> user for permission to use administrator powers everytime that it starts.
>
> If your entire app doesn't need admin permissions, only certain parts, you
> should seperate those "needing-admin" chunks of your app into secondary apps
> or COM components, and only manifest those apps as needing admin - this way,
> your program can be run in non-administrative mode and will only ask for
> admin rights when it actually needs them.
>
> This document goes into much more detail
>
> http://www.microsoft.com/downloads/d...displaylang=en
>
> - JB

Sorry, looks like I misunderstood you.

Yes, the virtualization is automatic and IS enabled for the application if
it is writing into the virtual store. And if the application works when
using Run As Administrator but not otherwise, it does sound like UAC is what
is tripping it up. However, specifically why the program is crashing is a
mystery to me, without knowing anything else about the situation. You can
try changing compatability settings from the compatability tab of the
program's property page; this will use a "general-purpose" shim to try and
get it to work.

As for creating a custom shim, I'm afraid I can't offer any more help than
what the documentation provides.

- JB

Thanks Jimmy, you are probably right, UAC is killing the app. the app is run
from a a network drive so I can't change compatibility settings. From what I
have read there is no way to turn off UAC for certain applications, but I
just want to see if someone can verify that for me. Can anyone else comment
on the shims?

"Jimmy Brush" wrote:

> Sorry, looks like I misunderstood you.
>
> Yes, the virtualization is automatic and IS enabled for the application if
> it is writing into the virtual store. And if the application works when
> using Run As Administrator but not otherwise, it does sound like UAC is what
> is tripping it up. However, specifically why the program is crashing is a
> mystery to me, without knowing anything else about the situation. You can
> try changing compatability settings from the compatability tab of the
> program's property page; this will use a "general-purpose" shim to try and
> get it to work.
>
> As for creating a custom shim, I'm afraid I can't offer any more help than
> what the documentation provides.
>
> - JB
>

GaryGoneGonads wrote:
> we have an app that runs as admin, writes to some LM keys and a couple of ini
> files. I keep hearing about file & registry virtualiztation, but it never
> really describes how to set it up, only that you can have an application
> started by a standard user that elevates with admin rights. when i start the
> app i see .ini files getting written to the virtual store in my profile, but
> the app still crashes unless i run as admin. I found stuff on using ACT to
> create application shims, but the lack of documention and a webcast that
> explains how to use the tool to find apps in a domain but not actually fix
> applications let me to get to the same place i started at, with a concept
> that is documented greatly without actual steps to get it working. We greatly
> appreciate any advice.

Virtualisation is a hack which MS put in to save old apps from
completely dying on Vista. It's well known that this hack will not
remain for ever (ie. in future OS versions it may be removed).

If an application is written to be aware of UAC etc, then Vista will
disable virtualisation. You only get virtualisation for legacy apps.

However, virtualisation only works for a handful of folders and registry
keys, it doesn't cover other 'admin' APIs which if called from a
non-admin app will cause the app to crash.

The only way to solve this is to run the app as Admin (right click, Run
As Admin), or modify the app to not make those calls.

It sounds like your app is making calls to Admin level APIs which is
causing the app to crash when run as a standard user.

Hope that helps,

D

David,
not arguing; just a point,
if the manufacturers of an operating system put in functionality like
virtualization, to begin with; I wouldn't neccesarily call it a "hack".
In fact, far from a hack,
it's meant to be there, for specifically the reasons you state.

Jeff

"David Hearn" <dave@NOswampieSPAM.org.uk> wrote in message
news:4u7sl1F1716eoU1@mid.individual.net...
> GaryGoneGonads wrote:
>> we have an app that runs as admin, writes to some LM keys and a couple of
>> ini files. I keep hearing about file & registry virtualiztation, but it
>> never really describes how to set it up, only that you can have an
>> application started by a standard user that elevates with admin rights.
>> when i start the app i see .ini files getting written to the virtual
>> store in my profile, but the app still crashes unless i run as admin. I
>> found stuff on using ACT to create application shims, but the lack of
>> documention and a webcast that explains how to use the tool to find apps
>> in a domain but not actually fix applications let me to get to the same
>> place i started at, with a concept that is documented greatly without
>> actual steps to get it working. We greatly appreciate any advice.
>
> Virtualisation is a hack which MS put in to save old apps from completely
> dying on Vista. It's well known that this hack will not remain for ever
> (ie. in future OS versions it may be removed).
>
> If an application is written to be aware of UAC etc, then Vista will
> disable virtualisation. You only get virtualisation for legacy apps.
>
> However, virtualisation only works for a handful of folders and registry
> keys, it doesn't cover other 'admin' APIs which if called from a non-admin
> app will cause the app to crash.
>
> The only way to solve this is to run the app as Admin (right click, Run As
> Admin), or modify the app to not make those calls.
>
> It sounds like your app is making calls to Admin level APIs which is
> causing the app to crash when run as a standard user.
>
> Hope that helps,
>
> D