Ok, the "referral returned from server" is because your manifest has
uiaccess=true but your exe is not signed with a digital certificate.

Based on what you have said, your application should not need
uiaccess=true, so I would suggest removing that line from the
manifest, and it should make things work as you expect.

I am confused about it asking for continue/cancel without a manifest
though... it should just run without asking anything.

- JB

On Mon, 14 May 2007 15:26:31 -0400, "AC" wrote:

Thanks Jimmy..

Got this feedback from our testers (no vista machine in front of me).

If they put the manifest file in play, they get this error even when
launching the EXE manually, not at startup:

A referral was returned from the server.

However, if they remove the manifest, they can launch the program manually
(they are asked to cancel or allow, but if they allow, all is OK)




"Jimmy Brush" wrote in message
news
So your application doesn't need admin privileges at all?

OK ... I guess I glazed over 'asInvoker' in your manifest and thought
it said 'highestAvailable'.

If your app doesn't need admin privileges under any circumstances,
then you are doing everything correctly, you don't need to use task
scheduler, and it should be working...

Try removing 'uiaccess=true' from your manifest.

On Mon, 14 May 2007 15:01:59 -0400, "AC" wrote:

We can't rearchitect the application. We need to support Win98, and we
need
it to run the way it is. Most (98%?) run our program as a startup
program, but some do not. Without getting too detailed, we can't change
the
application that dramatically.

Our testers took the manifest file I gave them, and when they put it in
play, all of a sudden the Blocked Programs popup bubble did not come back
when they restarted. HOWEVER, the program did not seem to do as expected.

We need the application to run whether it's an admin or not an admin.
Obviously, an admin installs our app, but from that point, in most cases,
the same account will run the application, but in others, it will NOT be
an
admin running the program.

Scheduling via a task scheduler sounds promising, but I need to be able to
do this automatically via our installer, and not rely on the users to do
that. Are there registry settings/etc I can set? Is there something in
my
manifest that can be done to get this to work?

Our startup "program" does the following:

1) Checks a folder on the local PC to see if an update has been
downloaded
by our updater (happens during our auto synchronization every evening, and
if an update is there)

2) Once the update files areput in their proper places, it launches
another
EXE, but stays in memory. It monitors this EXE it launched, and if it is
shut down, with the right exit code, it knows it's time to apply the
update
and relaunch. If it exits normally, then it just closes itself as well..




"Jimmy Brush" wrote in message
...
Basically, what I am saying, is that if your program needs
administrator privileges AND needs to be interactive on the desktop
AND needs to be running on every administrative user's desktop that
uses the computer, you need to have the task scheduler start your
program instead of Windows Explorer (which starts programs in the
startup folder).

Windows Explorer cannot start elevated applications without prompting
the user (which is blocked for startup apps), Task Scheduler can.

If *only* administrators will use your program, or all users on the
computer are administrators, you can have your installer register your
program with Windows' task scheduler, as i mentioned in my last post,
and instruct the task scheduler to start your program when
administrators on your machine log in.

This will do what you want, but only for administrator accounts on the
computer.

The task scheduler is just an alternate way of having your program
start that will work on vista, as opposed to putting it in the startup
folder (which doesn't work for your needs).

You can use the task scheduler API's inside your setup program to do
this without requiring the end user to do anything special.

If your program UI needs to run inside both standard user and
administrative accounts, then your program should be rearchitected so
that the UI runs as a non-privileged application and the privileged
core runs as a Windows Service.

In fact, based on what you've said about your application, this might
be a better way to implement your application.


On Mon, 14 May 2007 14:18:44 -0400, "AC" wrote:

Thanks. I tried using the manifest and it did not work.

Our program is not installed in the program files directory
(unfortunately,
I'd love it to be, but the clients AND support staff of our clients do
not
want it there).

I need the program to launch when the user logs in. It's OUR task
scheduler
which checks for updates, synchronizes with our server, etc etc. It has
an
UI. It sits in the task tray, and allows the user to show it to see the
UI.

I'm not 100% following what you say, but I need to have this happen from
our
install program. I can't expect the users to do anything on their end.



"Jimmy Brush" wrote in message
om...
Hello,

Applications that will request from the user permission to run (when
UAC is enabled) are blocked from being started in this manner.

A few reasons this is so:

- The user may not be around to approve the application to start when
the computer starts up or the account is logged on

- The user would find it very annoying to have to approve your
application (and possibly multiple applications) to start every time
they log on

To "get around" this limitation, instead of putting your application
in the startup folder, you can put your application in a secure
location (such as Program Files, which is required for uiAccess=true
btw, are u sure u really need uiaccess?), and then create an entry in
the task scheduler for the administrative user(s) that want your
application to run whenever they log in, specifying your application
to run on user log-on condition as well as specifying that the
application should run with highest privilege.

This will allow your application to start "elevated" on the admin's
desktop when the specified administrator(s) log in, without prompting
them for permission.

You can use this task scheduler method for non-admin users, but you
are not able to specify that the application run with "highest
privilege" for non-admins.

If you do, the application will start with highest privilege when the
non-admin logs on, but it will start non-interactively in Session 0
(the services session).

With UAC enabled, non-admin users should be able to put your program
(with the manifest you described) in their startup folder or in the
user-specific "run" registry key without being blocked.

On Mon, 14 May 2007 13:07:32 -0400, "AC" wrote:

Our application installs a .NET 1.1 EXE created with VB.NET into the
startup
folder on the PC. This works perfectly on Win98SE and XP. If the
User
Access Control is OFF on Vista, it also works perfectly there.
However,
if
the UAC is on, the program is BLOCKED.

I tried to build a manifest file....

assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"
asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
asmv3:security
asmv3:requestedPrivileges
asmv3:requestedExecutionLevel level="asInvoker" uiAccess="true"
/
/asmv3:requestedPrivileges
/asmv3:security
/asmv3:trustInfo
/assembly

It didn't help.

Any way to get this program to launch even if the UAC is turned on?
Users
can launch it by right clicking and allowing it to run, but how can it
run
normally, like it does on XP, Win98 or Vista when the UAC is off?

Your testers will also need to log off/log or possibly reboot the
computer after updating the manifest, as it seems Windows caches the
contents of the manifest and stops looking at the manifest file once
it is loaded into memory, ignoring any changes.

- JB

On Mon, 14 May 2007 15:26:31 -0400, "AC" wrote:

Thanks Jimmy..

Got this feedback from our testers (no vista machine in front of me).

If they put the manifest file in play, they get this error even when
launching the EXE manually, not at startup:

A referral was returned from the server.

However, if they remove the manifest, they can launch the program manually
(they are asked to cancel or allow, but if they allow, all is OK)




"Jimmy Brush" wrote in message
news
So your application doesn't need admin privileges at all?

OK ... I guess I glazed over 'asInvoker' in your manifest and thought
it said 'highestAvailable'.

If your app doesn't need admin privileges under any circumstances,
then you are doing everything correctly, you don't need to use task
scheduler, and it should be working...

Try removing 'uiaccess=true' from your manifest.

On Mon, 14 May 2007 15:01:59 -0400, "AC" wrote:

We can't rearchitect the application. We need to support Win98, and we
need
it to run the way it is. Most (98%?) run our program as a startup
program, but some do not. Without getting too detailed, we can't change
the
application that dramatically.

Our testers took the manifest file I gave them, and when they put it in
play, all of a sudden the Blocked Programs popup bubble did not come back
when they restarted. HOWEVER, the program did not seem to do as expected.

We need the application to run whether it's an admin or not an admin.
Obviously, an admin installs our app, but from that point, in most cases,
the same account will run the application, but in others, it will NOT be
an
admin running the program.

Scheduling via a task scheduler sounds promising, but I need to be able to
do this automatically via our installer, and not rely on the users to do
that. Are there registry settings/etc I can set? Is there something in
my
manifest that can be done to get this to work?

Our startup "program" does the following:

1) Checks a folder on the local PC to see if an update has been
downloaded
by our updater (happens during our auto synchronization every evening, and
if an update is there)

2) Once the update files areput in their proper places, it launches
another
EXE, but stays in memory. It monitors this EXE it launched, and if it is
shut down, with the right exit code, it knows it's time to apply the
update
and relaunch. If it exits normally, then it just closes itself as well..




"Jimmy Brush" wrote in message
...
Basically, what I am saying, is that if your program needs
administrator privileges AND needs to be interactive on the desktop
AND needs to be running on every administrative user's desktop that
uses the computer, you need to have the task scheduler start your
program instead of Windows Explorer (which starts programs in the
startup folder).

Windows Explorer cannot start elevated applications without prompting
the user (which is blocked for startup apps), Task Scheduler can.

If *only* administrators will use your program, or all users on the
computer are administrators, you can have your installer register your
program with Windows' task scheduler, as i mentioned in my last post,
and instruct the task scheduler to start your program when
administrators on your machine log in.

This will do what you want, but only for administrator accounts on the
computer.

The task scheduler is just an alternate way of having your program
start that will work on vista, as opposed to putting it in the startup
folder (which doesn't work for your needs).

You can use the task scheduler API's inside your setup program to do
this without requiring the end user to do anything special.

If your program UI needs to run inside both standard user and
administrative accounts, then your program should be rearchitected so
that the UI runs as a non-privileged application and the privileged
core runs as a Windows Service.

In fact, based on what you've said about your application, this might
be a better way to implement your application.


On Mon, 14 May 2007 14:18:44 -0400, "AC" wrote:

Thanks. I tried using the manifest and it did not work.

Our program is not installed in the program files directory
(unfortunately,
I'd love it to be, but the clients AND support staff of our clients do
not
want it there).

I need the program to launch when the user logs in. It's OUR task
scheduler
which checks for updates, synchronizes with our server, etc etc. It has
an
UI. It sits in the task tray, and allows the user to show it to see the
UI.

I'm not 100% following what you say, but I need to have this happen from
our
install program. I can't expect the users to do anything on their end.



"Jimmy Brush" wrote in message
om...
Hello,

Applications that will request from the user permission to run (when
UAC is enabled) are blocked from being started in this manner.

A few reasons this is so:

- The user may not be around to approve the application to start when
the computer starts up or the account is logged on

- The user would find it very annoying to have to approve your
application (and possibly multiple applications) to start every time
they log on

To "get around" this limitation, instead of putting your application
in the startup folder, you can put your application in a secure
location (such as Program Files, which is required for uiAccess=true
btw, are u sure u really need uiaccess?), and then create an entry in
the task scheduler for the administrative user(s) that want your
application to run whenever they log in, specifying your application
to run on user log-on condition as well as specifying that the
application should run with highest privilege.

This will allow your application to start "elevated" on the admin's
desktop when the specified administrator(s) log in, without prompting
them for permission.

You can use this task scheduler method for non-admin users, but you
are not able to specify that the application run with "highest
privilege" for non-admins.

If you do, the application will start with highest privilege when the
non-admin logs on, but it will start non-interactively in Session 0
(the services session).

With UAC enabled, non-admin users should be able to put your program
(with the manifest you described) in their startup folder or in the
user-specific "run" registry key without being blocked.

On Mon, 14 May 2007 13:07:32 -0400, "AC" wrote:

Our application installs a .NET 1.1 EXE created with VB.NET into the
startup
folder on the PC. This works perfectly on Win98SE and XP. If the
User
Access Control is OFF on Vista, it also works perfectly there.
However,
if
the UAC is on, the program is BLOCKED.

I tried to build a manifest file....

assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"
asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
asmv3:security
asmv3:requestedPrivileges
asmv3:requestedExecutionLevel level="asInvoker" uiAccess="true"
/
/asmv3:requestedPrivileges
/asmv3:security
/asmv3:trustInfo
/assembly

It didn't help.

Any way to get this program to launch even if the UAC is turned on?
Users
can launch it by right clicking and allowing it to run, but how can it
run
normally, like it does on XP, Win98 or Vista when the UAC is off?

Jimmy,

I tried this, and got this feedback:

"OK - I copy the X.exe.manifest file that you included into the C:\X folder
and rebooted. After I logged on, I received the Windows has Blocked Startup
Programs message. When I try run the blocked startup program, nothing
happens. If I try to run the Xt from the Startup folder, nothing happens. If
I delete the manifest file and try to run the same program, it runs after I
get prompted for cancel or allow"

assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
asmv3:security
asmv3:requestedPrivileges
asmv3:requestedExecutionLevel level="asInvoker" /
/asmv3:requestedPrivileges
/asmv3:security
/asmv3:trustInfo
/assembly

Any advice?



"Jimmy Brush" wrote in message
...
Ok, the "referral returned from server" is because your manifest has
uiaccess=true but your exe is not signed with a digital certificate.

Based on what you have said, your application should not need
uiaccess=true, so I would suggest removing that line from the
manifest, and it should make things work as you expect.

I am confused about it asking for continue/cancel without a manifest
though... it should just run without asking anything.

- JB

On Mon, 14 May 2007 15:26:31 -0400, "AC" wrote:

Thanks Jimmy..

Got this feedback from our testers (no vista machine in front of me).

If they put the manifest file in play, they get this error even when
launching the EXE manually, not at startup:

A referral was returned from the server.

However, if they remove the manifest, they can launch the program manually
(they are asked to cancel or allow, but if they allow, all is OK)




"Jimmy Brush" wrote in message
news
So your application doesn't need admin privileges at all?

OK ... I guess I glazed over 'asInvoker' in your manifest and thought
it said 'highestAvailable'.

If your app doesn't need admin privileges under any circumstances,
then you are doing everything correctly, you don't need to use task
scheduler, and it should be working...

Try removing 'uiaccess=true' from your manifest.

On Mon, 14 May 2007 15:01:59 -0400, "AC" wrote:

We can't rearchitect the application. We need to support Win98, and we
need
it to run the way it is. Most (98%?) run our program as a startup
program, but some do not. Without getting too detailed, we can't change
the
application that dramatically.

Our testers took the manifest file I gave them, and when they put it in
play, all of a sudden the Blocked Programs popup bubble did not come
back
when they restarted. HOWEVER, the program did not seem to do as
expected.

We need the application to run whether it's an admin or not an admin.
Obviously, an admin installs our app, but from that point, in most
cases,
the same account will run the application, but in others, it will NOT be
an
admin running the program.

Scheduling via a task scheduler sounds promising, but I need to be able
to
do this automatically via our installer, and not rely on the users to do
that. Are there registry settings/etc I can set? Is there something in
my
manifest that can be done to get this to work?

Our startup "program" does the following:

1) Checks a folder on the local PC to see if an update has been
downloaded
by our updater (happens during our auto synchronization every evening,
and
if an update is there)

2) Once the update files areput in their proper places, it launches
another
EXE, but stays in memory. It monitors this EXE it launched, and if it
is
shut down, with the right exit code, it knows it's time to apply the
update
and relaunch. If it exits normally, then it just closes itself as
well..




"Jimmy Brush" wrote in message
m...
Basically, what I am saying, is that if your program needs
administrator privileges AND needs to be interactive on the desktop
AND needs to be running on every administrative user's desktop that
uses the computer, you need to have the task scheduler start your
program instead of Windows Explorer (which starts programs in the
startup folder).

Windows Explorer cannot start elevated applications without prompting
the user (which is blocked for startup apps), Task Scheduler can.

If *only* administrators will use your program, or all users on the
computer are administrators, you can have your installer register your
program with Windows' task scheduler, as i mentioned in my last post,
and instruct the task scheduler to start your program when
administrators on your machine log in.

This will do what you want, but only for administrator accounts on the
computer.

The task scheduler is just an alternate way of having your program
start that will work on vista, as opposed to putting it in the startup
folder (which doesn't work for your needs).

You can use the task scheduler API's inside your setup program to do
this without requiring the end user to do anything special.

If your program UI needs to run inside both standard user and
administrative accounts, then your program should be rearchitected so
that the UI runs as a non-privileged application and the privileged
core runs as a Windows Service.

In fact, based on what you've said about your application, this might
be a better way to implement your application.


On Mon, 14 May 2007 14:18:44 -0400, "AC" wrote:

Thanks. I tried using the manifest and it did not work.

Our program is not installed in the program files directory
(unfortunately,
I'd love it to be, but the clients AND support staff of our clients do
not
want it there).

I need the program to launch when the user logs in. It's OUR task
scheduler
which checks for updates, synchronizes with our server, etc etc. It
has
an
UI. It sits in the task tray, and allows the user to show it to see
the
UI.

I'm not 100% following what you say, but I need to have this happen
from
our
install program. I can't expect the users to do anything on their
end.



"Jimmy Brush" wrote in message
news:867h43d45grfumk5vksm260nfof2u5drrd@4ax. com...
Hello,

Applications that will request from the user permission to run (when
UAC is enabled) are blocked from being started in this manner.

A few reasons this is so:

- The user may not be around to approve the application to start
when
the computer starts up or the account is logged on

- The user would find it very annoying to have to approve your
application (and possibly multiple applications) to start every time
they log on

To "get around" this limitation, instead of putting your application
in the startup folder, you can put your application in a secure
location (such as Program Files, which is required for uiAccess=true
btw, are u sure u really need uiaccess?), and then create an entry
in
the task scheduler for the administrative user(s) that want your
application to run whenever they log in, specifying your application
to run on user log-on condition as well as specifying that the
application should run with highest privilege.

This will allow your application to start "elevated" on the admin's
desktop when the specified administrator(s) log in, without
prompting
them for permission.

You can use this task scheduler method for non-admin users, but you
are not able to specify that the application run with "highest
privilege" for non-admins.

If you do, the application will start with highest privilege when
the
non-admin logs on, but it will start non-interactively in Session 0
(the services session).

With UAC enabled, non-admin users should be able to put your program
(with the manifest you described) in their startup folder or in the
user-specific "run" registry key without being blocked.

On Mon, 14 May 2007 13:07:32 -0400, "AC" wrote:

Our application installs a .NET 1.1 EXE created with VB.NET into the
startup
folder on the PC. This works perfectly on Win98SE and XP. If the
User
Access Control is OFF on Vista, it also works perfectly there.
However,
if
the UAC is on, the program is BLOCKED.

I tried to build a manifest file....

assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"
asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
asmv3:security
asmv3:requestedPrivileges
asmv3:requestedExecutionLevel level="asInvoker" uiAccess="true"
/
/asmv3:requestedPrivileges
/asmv3:security
/asmv3:trustInfo
/assembly

It didn't help.

Any way to get this program to launch even if the UAC is turned on?
Users
can launch it by right clicking and allowing it to run, but how can
it
run
normally, like it does on XP, Win98 or Vista when the UAC is off?

I tested that manifest and it works on my computer.

I renamed an application that does not contain a manifest to
update.exe (which triggers Windows to ask for elevation for that
application).

I then created a link to this app into the all user's startup folder.

I then logged into another admin account and the program was blocked
from running.

I logged out from that account, added the manifest file you described
from another account, logged back in, and the program was allowed to
run without prompting the user.

So ... I am stumped now as well.

- JB


On Mon, 14 May 2007 16:14:39 -0400, "AC" wrote:

Jimmy,

I tried this, and got this feedback:

"OK - I copy the X.exe.manifest file that you included into the C:\X folder
and rebooted. After I logged on, I received the Windows has Blocked Startup
Programs message. When I try run the blocked startup program, nothing
happens. If I try to run the Xt from the Startup folder, nothing happens. If
I delete the manifest file and try to run the same program, it runs after I
get prompted for cancel or allow"

assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
asmv3:security
asmv3:requestedPrivileges
asmv3:requestedExecutionLevel level="asInvoker" /
/asmv3:requestedPrivileges
/asmv3:security
/asmv3:trustInfo
/assembly

Any advice?



"Jimmy Brush" wrote in message
.. .
Ok, the "referral returned from server" is because your manifest has
uiaccess=true but your exe is not signed with a digital certificate.

Based on what you have said, your application should not need
uiaccess=true, so I would suggest removing that line from the
manifest, and it should make things work as you expect.

I am confused about it asking for continue/cancel without a manifest
though... it should just run without asking anything.

- JB

On Mon, 14 May 2007 15:26:31 -0400, "AC" wrote:

Thanks Jimmy..

Got this feedback from our testers (no vista machine in front of me).

If they put the manifest file in play, they get this error even when
launching the EXE manually, not at startup:

A referral was returned from the server.

However, if they remove the manifest, they can launch the program manually
(they are asked to cancel or allow, but if they allow, all is OK)




"Jimmy Brush" wrote in message
news So your application doesn't need admin privileges at all?

OK ... I guess I glazed over 'asInvoker' in your manifest and thought
it said 'highestAvailable'.

If your app doesn't need admin privileges under any circumstances,
then you are doing everything correctly, you don't need to use task
scheduler, and it should be working...

Try removing 'uiaccess=true' from your manifest.

On Mon, 14 May 2007 15:01:59 -0400, "AC" wrote:

We can't rearchitect the application. We need to support Win98, and we
need
it to run the way it is. Most (98%?) run our program as a startup
program, but some do not. Without getting too detailed, we can't change
the
application that dramatically.

Our testers took the manifest file I gave them, and when they put it in
play, all of a sudden the Blocked Programs popup bubble did not come
back
when they restarted. HOWEVER, the program did not seem to do as
expected.

We need the application to run whether it's an admin or not an admin.
Obviously, an admin installs our app, but from that point, in most
cases,
the same account will run the application, but in others, it will NOT be
an
admin running the program.

Scheduling via a task scheduler sounds promising, but I need to be able
to
do this automatically via our installer, and not rely on the users to do
that. Are there registry settings/etc I can set? Is there something in
my
manifest that can be done to get this to work?

Our startup "program" does the following:

1) Checks a folder on the local PC to see if an update has been
downloaded
by our updater (happens during our auto synchronization every evening,
and
if an update is there)

2) Once the update files areput in their proper places, it launches
another
EXE, but stays in memory. It monitors this EXE it launched, and if it
is
shut down, with the right exit code, it knows it's time to apply the
update
and relaunch. If it exits normally, then it just closes itself as
well..




"Jimmy Brush" wrote in message
om...
Basically, what I am saying, is that if your program needs
administrator privileges AND needs to be interactive on the desktop
AND needs to be running on every administrative user's desktop that
uses the computer, you need to have the task scheduler start your
program instead of Windows Explorer (which starts programs in the
startup folder).

Windows Explorer cannot start elevated applications without prompting
the user (which is blocked for startup apps), Task Scheduler can.

If *only* administrators will use your program, or all users on the
computer are administrators, you can have your installer register your
program with Windows' task scheduler, as i mentioned in my last post,
and instruct the task scheduler to start your program when
administrators on your machine log in.

This will do what you want, but only for administrator accounts on the
computer.

The task scheduler is just an alternate way of having your program
start that will work on vista, as opposed to putting it in the startup
folder (which doesn't work for your needs).

You can use the task scheduler API's inside your setup program to do
this without requiring the end user to do anything special.

If your program UI needs to run inside both standard user and
administrative accounts, then your program should be rearchitected so
that the UI runs as a non-privileged application and the privileged
core runs as a Windows Service.

In fact, based on what you've said about your application, this might
be a better way to implement your application.


On Mon, 14 May 2007 14:18:44 -0400, "AC" wrote:

Thanks. I tried using the manifest and it did not work.

Our program is not installed in the program files directory
(unfortunately,
I'd love it to be, but the clients AND support staff of our clients do
not
want it there).

I need the program to launch when the user logs in. It's OUR task
scheduler
which checks for updates, synchronizes with our server, etc etc. It
has
an
UI. It sits in the task tray, and allows the user to show it to see
the
UI.

I'm not 100% following what you say, but I need to have this happen
from
our
install program. I can't expect the users to do anything on their
end.



"Jimmy Brush" wrote in message
news:867h43d45grfumk5vksm260nfof2u5drrd@4ax .com...
Hello,

Applications that will request from the user permission to run (when
UAC is enabled) are blocked from being started in this manner.

A few reasons this is so:

- The user may not be around to approve the application to start
when
the computer starts up or the account is logged on

- The user would find it very annoying to have to approve your
application (and possibly multiple applications) to start every time
they log on

To "get around" this limitation, instead of putting your application
in the startup folder, you can put your application in a secure
location (such as Program Files, which is required for uiAccess=true
btw, are u sure u really need uiaccess?), and then create an entry
in
the task scheduler for the administrative user(s) that want your
application to run whenever they log in, specifying your application
to run on user log-on condition as well as specifying that the
application should run with highest privilege.

This will allow your application to start "elevated" on the admin's
desktop when the specified administrator(s) log in, without
prompting
them for permission.

You can use this task scheduler method for non-admin users, but you
are not able to specify that the application run with "highest
privilege" for non-admins.

If you do, the application will start with highest privilege when
the
non-admin logs on, but it will start non-interactively in Session 0
(the services session).

With UAC enabled, non-admin users should be able to put your program
(with the manifest you described) in their startup folder or in the
user-specific "run" registry key without being blocked.

On Mon, 14 May 2007 13:07:32 -0400, "AC" wrote:

Our application installs a .NET 1.1 EXE created with VB.NET into the
startup
folder on the PC. This works perfectly on Win98SE and XP. If the
User
Access Control is OFF on Vista, it also works perfectly there.
However,
if
the UAC is on, the program is BLOCKED.

I tried to build a manifest file....

assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"
asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
asmv3:security
asmv3:requestedPrivileges
asmv3:requestedExecutionLevel level="asInvoker" uiAccess="true"
/
/asmv3:requestedPrivileges
/asmv3:security
/asmv3:trustInfo
/assembly

It didn't help.

Any way to get this program to launch even if the UAC is turned on?
Users
can launch it by right clicking and allowing it to run, but how can
it
run
normally, like it does on XP, Win98 or Vista when the UAC is off?