Vista Enigma...

I should start off by saying that I tried to post this yesterday, but
it doesn't appear that it went through. Also, I am still in the midst
of testing, but here is what is going on....

We have an application installation that we are prepping for Vista
target systems. When testing the installation for Standard Users with
UAC enabled, the process appears to complete successfully after
supplying Admin credentials at time of install, of course.

In addition to this, we have a utility that checks and .ini file for
version information in the installing users profile (Standard User in
this case) to determine if an update is required. If it is determined
that a new/updated .msi is present in the installation location
(network share) it is fired off.

The problem is that the utility requires Admin credentials. After
providing such, the utility starts to go about its business, but fails
because it can't find the information storing .ini file. It's
searching in the Admin profile instead of in the Standard User's
profile as I hoped it would as this is who actually initiated the
utility. Once credentials are applied, I guess it actually runs as
that user and doesn't simply apply the rights for the Standard User.

Anyway, to get around this problem I tried to add the .ini to the
Allusers Application Data area (ProgramData in Vista) and tweak the
update utility to look there instead of a specific user area. That
seemed to have done the trick as it appeared that our update process
then proceeded, again after supplying Admin credentials, but
initiating the process as a Standard User.

However, upon initial start of our application after the update
process, the Windows Installer's Self Repair mechanism was fired.
Something was amiss. After checking the Event Viewer's Application
log, it appears that information was missing from the Admin user's
profile area! Why would this be? It seems now that Windows Installer
thinks that the application should be installed for the Admin user
whose credentials were used to elevate our update process for the
Standard User who actually initiated that process. I would have hoped
that simply applying credentials for the .exe to run would have simply
elevated it for the Standard User, but that does not appear to be the
case.

Every time I think I have a grasp on Vista's user setup and security,
I am baffled by something new.

Does anyone know what is going on? Would manifesting the .exe solve
anything or have anything to do with this? Any points to information,
solutions, recommendations, etc. are greatly appreciated!

Thanks in advance to anyone who takes a crack at this!! Again, sorry
if my initial attempt to post this pops up and causes duplication.

When you provide Over-The-Shoulder credentials in Vista you get a different
user profile loaded. Therefore, the behavior you are seeing where you are all
of a sudden accessing the admin's profile is quite expected.

To solve this I think you need to look into a custom action in the
installer. Aaron Stebner has a lot of good information on those in his blog:
http://blogs.msdn.com/astebner/archi...r/default.aspx


---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Superfreak3" wrote:

> I should start off by saying that I tried to post this yesterday, but
> it doesn't appear that it went through. Also, I am still in the midst
> of testing, but here is what is going on....
>
> We have an application installation that we are prepping for Vista
> target systems. When testing the installation for Standard Users with
> UAC enabled, the process appears to complete successfully after
> supplying Admin credentials at time of install, of course.
>
> In addition to this, we have a utility that checks and .ini file for
> version information in the installing users profile (Standard User in
> this case) to determine if an update is required. If it is determined
> that a new/updated .msi is present in the installation location
> (network share) it is fired off.
>
> The problem is that the utility requires Admin credentials. After
> providing such, the utility starts to go about its business, but fails
> because it can't find the information storing .ini file. It's
> searching in the Admin profile instead of in the Standard User's
> profile as I hoped it would as this is who actually initiated the
> utility. Once credentials are applied, I guess it actually runs as
> that user and doesn't simply apply the rights for the Standard User.
>
> Anyway, to get around this problem I tried to add the .ini to the
> Allusers Application Data area (ProgramData in Vista) and tweak the
> update utility to look there instead of a specific user area. That
> seemed to have done the trick as it appeared that our update process
> then proceeded, again after supplying Admin credentials, but
> initiating the process as a Standard User.
>
> However, upon initial start of our application after the update
> process, the Windows Installer's Self Repair mechanism was fired.
> Something was amiss. After checking the Event Viewer's Application
> log, it appears that information was missing from the Admin user's
> profile area! Why would this be? It seems now that Windows Installer
> thinks that the application should be installed for the Admin user
> whose credentials were used to elevate our update process for the
> Standard User who actually initiated that process. I would have hoped
> that simply applying credentials for the .exe to run would have simply
> elevated it for the Standard User, but that does not appear to be the
> case.
>
> Every time I think I have a grasp on Vista's user setup and security,
> I am baffled by something new.
>
> Does anyone know what is going on? Would manifesting the .exe solve
> anything or have anything to do with this? Any points to information,
> solutions, recommendations, etc. are greatly appreciated!
>
> Thanks in advance to anyone who takes a crack at this!! Again, sorry
> if my initial attempt to post this pops up and causes duplication.
>
>

On Aug 15, 9:44 am, Jesper <Jes...@discussions.microsoft.com> wrote:
> When you provide Over-The-Shoulder credentials in Vista you get a different
> user profile loaded. Therefore, the behavior you are seeing where you are all
> of a sudden accessing the admin's profile is quite expected.
>
> To solve this I think you need to look into a custom action in the
> installer. Aaron Stebner has a lot of good information on those in his blog:http://blogs.msdn.com/astebner/archi...taller/default...
>
> ---
> Your question may already be answered in Windows Vista Security:http://www.amazon.com/gp/product/047...otectyourwi-20
>
>
>
> "Superfreak3" wrote:
> > I should start off by saying that I tried to post this yesterday, but
> > it doesn't appear that it went through. Also, I am still in the midst
> > of testing, but here is what is going on....
>
> > We have an application installation that we are prepping for Vista
> > target systems. When testing the installation for Standard Users with
> > UAC enabled, the process appears to complete successfully after
> > supplying Admin credentials at time of install, of course.
>
> > In addition to this, we have a utility that checks and .ini file for
> > version information in the installing users profile (Standard User in
> > this case) to determine if an update is required. If it is determined
> > that a new/updated .msi is present in the installation location
> > (network share) it is fired off.
>
> > The problem is that the utility requires Admin credentials. After
> > providing such, the utility starts to go about its business, but fails
> > because it can't find the information storing .ini file. It's
> > searching in the Admin profile instead of in the Standard User's
> > profile as I hoped it would as this is who actually initiated the
> > utility. Once credentials are applied, I guess it actually runs as
> > that user and doesn't simply apply the rights for the Standard User.
>
> > Anyway, to get around this problem I tried to add the .ini to the
> > Allusers Application Data area (ProgramData in Vista) and tweak the
> > update utility to look there instead of a specific user area. That
> > seemed to have done the trick as it appeared that our update process
> > then proceeded, again after supplying Admin credentials, but
> > initiating the process as a Standard User.
>
> > However, upon initial start of our application after the update
> > process, the Windows Installer's Self Repair mechanism was fired.
> > Something was amiss. After checking the Event Viewer's Application
> > log, it appears that information was missing from the Admin user's
> > profile area! Why would this be? It seems now that Windows Installer
> > thinks that the application should be installed for the Admin user
> > whose credentials were used to elevate our update process for the
> > Standard User who actually initiated that process. I would have hoped
> > that simply applying credentials for the .exe to run would have simply
> > elevated it for the Standard User, but that does not appear to be the
> > case.
>
> > Every time I think I have a grasp on Vista's user setup and security,
> > I am baffled by something new.
>
> > Does anyone know what is going on? Would manifesting the .exe solve
> > anything or have anything to do with this? Any points to information,
> > solutions, recommendations, etc. are greatly appreciated!
>
> > Thanks in advance to anyone who takes a crack at this!! Again, sorry
> > if my initial attempt to post this pops up and causes duplication.- Hide quoted text -
>
> - Show quoted text -

When providing elevation when executing the initial .msi install, it
doesn't appear that user information is written to the elevating
user's profile, but the initiating Standard user's profile. This is
seemingly good behavior and appears that rights are elevated, but the
Admin user profile is not loaded upon applying the credentials. Is
this correct? Does providing Admin credentials act differently for
Windows Installer installations?

If so, I don't know how wrapping installations in wrappers helps with
UAC, because it seems if the installation is fired from a setup.exe
for example, elevation is required. You basically, then are
installing for the credential supplying user. That seems misleading
and I would think could cause many problems.

Our .exe is named OurappUpdate.exe so I guess it is being detected as
an installer by Vista. Would or could manifest'ing the .exe help in
any way. I would guess if we run as invoker, process would fail for a
Standard User. I don't think using any of the the three execution
level options would help in our scenario.

If the app is named setup.exe I don't think a manifest changes anything in
how it runs. UAC performs "intelligent" detection to detect installers. One
of the triggers is the word "setup."

I honestly do not know all that much about installers. I recommend reading
Aaron Stebner's blog, or someone else may be better than I am. It is a murky
area, and UAC made it more complicated.

---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Superfreak3" wrote:

> On Aug 15, 9:44 am, Jesper <Jes...@discussions.microsoft.com> wrote:
> > When you provide Over-The-Shoulder credentials in Vista you get a different
> > user profile loaded. Therefore, the behavior you are seeing where you are all
> > of a sudden accessing the admin's profile is quite expected.
> >
> > To solve this I think you need to look into a custom action in the
> > installer. Aaron Stebner has a lot of good information on those in his blog:http://blogs.msdn.com/astebner/archi...taller/default...
> >
> > ---
> > Your question may already be answered in Windows Vista Security:http://www.amazon.com/gp/product/047...otectyourwi-20
> >
> >
> >
> > "Superfreak3" wrote:
> > > I should start off by saying that I tried to post this yesterday, but
> > > it doesn't appear that it went through. Also, I am still in the midst
> > > of testing, but here is what is going on....
> >
> > > We have an application installation that we are prepping for Vista
> > > target systems. When testing the installation for Standard Users with
> > > UAC enabled, the process appears to complete successfully after
> > > supplying Admin credentials at time of install, of course.
> >
> > > In addition to this, we have a utility that checks and .ini file for
> > > version information in the installing users profile (Standard User in
> > > this case) to determine if an update is required. If it is determined
> > > that a new/updated .msi is present in the installation location
> > > (network share) it is fired off.
> >
> > > The problem is that the utility requires Admin credentials. After
> > > providing such, the utility starts to go about its business, but fails
> > > because it can't find the information storing .ini file. It's
> > > searching in the Admin profile instead of in the Standard User's
> > > profile as I hoped it would as this is who actually initiated the
> > > utility. Once credentials are applied, I guess it actually runs as
> > > that user and doesn't simply apply the rights for the Standard User.
> >
> > > Anyway, to get around this problem I tried to add the .ini to the
> > > Allusers Application Data area (ProgramData in Vista) and tweak the
> > > update utility to look there instead of a specific user area. That
> > > seemed to have done the trick as it appeared that our update process
> > > then proceeded, again after supplying Admin credentials, but
> > > initiating the process as a Standard User.
> >
> > > However, upon initial start of our application after the update
> > > process, the Windows Installer's Self Repair mechanism was fired.
> > > Something was amiss. After checking the Event Viewer's Application
> > > log, it appears that information was missing from the Admin user's
> > > profile area! Why would this be? It seems now that Windows Installer
> > > thinks that the application should be installed for the Admin user
> > > whose credentials were used to elevate our update process for the
> > > Standard User who actually initiated that process. I would have hoped
> > > that simply applying credentials for the .exe to run would have simply
> > > elevated it for the Standard User, but that does not appear to be the
> > > case.
> >
> > > Every time I think I have a grasp on Vista's user setup and security,
> > > I am baffled by something new.
> >
> > > Does anyone know what is going on? Would manifesting the .exe solve
> > > anything or have anything to do with this? Any points to information,
> > > solutions, recommendations, etc. are greatly appreciated!
> >
> > > Thanks in advance to anyone who takes a crack at this!! Again, sorry
> > > if my initial attempt to post this pops up and causes duplication.- Hide quoted text -
> >
> > - Show quoted text -
>
> When providing elevation when executing the initial .msi install, it
> doesn't appear that user information is written to the elevating
> user's profile, but the initiating Standard user's profile. This is
> seemingly good behavior and appears that rights are elevated, but the
> Admin user profile is not loaded upon applying the credentials. Is
> this correct? Does providing Admin credentials act differently for
> Windows Installer installations?
>
> If so, I don't know how wrapping installations in wrappers helps with
> UAC, because it seems if the installation is fired from a setup.exe
> for example, elevation is required. You basically, then are
> installing for the credential supplying user. That seems misleading
> and I would think could cause many problems.
>
> Our .exe is named OurappUpdate.exe so I guess it is being detected as
> an installer by Vista. Would or could manifest'ing the .exe help in
> any way. I would guess if we run as invoker, process would fail for a
> Standard User. I don't think using any of the the three execution
> level options would help in our scenario.
>
>