Software Deployment Issues - Help

[Mikey]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

I'm trying to use software deployment via Group Policy to
push down an in-house application but I am having problems
and can't seem to figure it out. We are about to replace
about 90% of our office PCs over the next three months
with Windows XP Pro boxes (so long Windows 98). Since we
are doing this, we want to take advantage of being able
to "lock down" the machines - especially to keep users
from installing software on them. These workstations have
no cd-rom or floppy drives in them.
So here's the deal - I have created an OU with a couple of
users and created a Group Policy for the OU and assigned
the application to the users. On the workstations, they
are just normal domain users (I did not make them
administrators of their machines). I can log in as one of
the users, and the icon for the application will be there,
but when I go to install it I get an error message that
the user does not have access to write something into the
Program Files directory. I went back into Group Policy and
enabled the "Always install with elevated priviledges" in
both the user and computer configurations, refreshed the
policy, allowed it replicate and tried it again - and got
the same result. The only way I can get the program to
install is to make the user a power user or administrator
of the local machine - which I would seriously like to
avoid. I thought it could have been a problem with the
application so I tried the same thing with Acrobat Reader
(after repackaging) and VirusScan Enterprise and got the
same results. Right now I'm at a loss - can anyone give me
a clue as to what I may have missed?

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Mikey-
You typically see this when there is something hard-coded into the MSI
package that is requiring administrator rights--or the package is setup as a
"per-machine" deployment. That would be the first place I would look--in the
package. There is a property called ALLUSERS, which should be set to 2 for a
non-privileged per-user installation. If you look in the Property table in
the MSI package, double-check that property value.


--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com



"Mikey" <anonymous@discussions.microsoft.com> wrote in message
news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
> I'm trying to use software deployment via Group Policy to
> push down an in-house application but I am having problems
> and can't seem to figure it out. We are about to replace
> about 90% of our office PCs over the next three months
> with Windows XP Pro boxes (so long Windows 98). Since we
> are doing this, we want to take advantage of being able
> to "lock down" the machines - especially to keep users
> from installing software on them. These workstations have
> no cd-rom or floppy drives in them.
> So here's the deal - I have created an OU with a couple of
> users and created a Group Policy for the OU and assigned
> the application to the users. On the workstations, they
> are just normal domain users (I did not make them
> administrators of their machines). I can log in as one of
> the users, and the icon for the application will be there,
> but when I go to install it I get an error message that
> the user does not have access to write something into the
> Program Files directory. I went back into Group Policy and
> enabled the "Always install with elevated priviledges" in
> both the user and computer configurations, refreshed the
> policy, allowed it replicate and tried it again - and got
> the same result. The only way I can get the program to
> install is to make the user a power user or administrator
> of the local machine - which I would seriously like to
> avoid. I thought it could have been a problem with the
> application so I tried the same thing with Acrobat Reader
> (after repackaging) and VirusScan Enterprise and got the
> same results. Right now I'm at a loss - can anyone give me
> a clue as to what I may have missed?

 

[Mikey]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Hmmm - the developers told me they don't want me messing
around in their package file. Anything else I can try?

>-----Original Message-----
>Mikey-
>You typically see this when there is something hard-coded
into the MSI
>package that is requiring administrator rights--or the
package is setup as a
>"per-machine" deployment. That would be the first place I
would look--in the
>package. There is a property called ALLUSERS, which
should be set to 2 for a
>non-privileged per-user installation. If you look in the
Property table in
>the MSI package, double-check that property value.
>
>
>--
>Darren Mar-Elia
>MS-MVP-Windows Management
>http://www.gpoguy.com
>
>
>
>"Mikey" <anonymous@discussions.microsoft.com> wrote in
message
>news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
>> I'm trying to use software deployment via Group Policy
to
>> push down an in-house application but I am having
problems
>> and can't seem to figure it out. We are about to replace
>> about 90% of our office PCs over the next three months
>> with Windows XP Pro boxes (so long Windows 98). Since we
>> are doing this, we want to take advantage of being able
>> to "lock down" the machines - especially to keep users
>> from installing software on them. These workstations
have
>> no cd-rom or floppy drives in them.
>> So here's the deal - I have created an OU with a couple
of
>> users and created a Group Policy for the OU and assigned
>> the application to the users. On the workstations, they
>> are just normal domain users (I did not make them
>> administrators of their machines). I can log in as one
of
>> the users, and the icon for the application will be
there,
>> but when I go to install it I get an error message that
>> the user does not have access to write something into
the
>> Program Files directory. I went back into Group Policy
and
>> enabled the "Always install with elevated priviledges"
in
>> both the user and computer configurations, refreshed the
>> policy, allowed it replicate and tried it again - and
got
>> the same result. The only way I can get the program to
>> install is to make the user a power user or
administrator
>> of the local machine - which I would seriously like to
>> avoid. I thought it could have been a problem with the
>> application so I tried the same thing with Acrobat
Reader
>> (after repackaging) and VirusScan Enterprise and got the
>> same results. Right now I'm at a loss - can anyone give
me
>> a clue as to what I may have missed?
>
>
>.
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Well, since you've set the bit to always install elevated, you can try
overriding ALLUSERS from the command-line as a regular user. That will allow
you to prove to your developers that its a packaging issue. So, as a regular
user, open a command shell and type the following:

msiexec /i \\server\share\myapp.msi ALLUSERS=2

Note that ALLUSERS is case sensitive and must be in upper case.


--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com



"Mikey" <anonymous@discussions.microsoft.com> wrote in message
news:545d01c48a0c$b1584810$a301280a@phx.gbl...
> Hmmm - the developers told me they don't want me messing
> around in their package file. Anything else I can try?
>
>>-----Original Message-----
>>Mikey-
>>You typically see this when there is something hard-coded
> into the MSI
>>package that is requiring administrator rights--or the
> package is setup as a
>>"per-machine" deployment. That would be the first place I
> would look--in the
>>package. There is a property called ALLUSERS, which
> should be set to 2 for a
>>non-privileged per-user installation. If you look in the
> Property table in
>>the MSI package, double-check that property value.
>>
>>
>>--
>>Darren Mar-Elia
>>MS-MVP-Windows Management
>>http://www.gpoguy.com
>>
>>
>>
>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
> message
>>news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
>>> I'm trying to use software deployment via Group Policy
> to
>>> push down an in-house application but I am having
> problems
>>> and can't seem to figure it out. We are about to replace
>>> about 90% of our office PCs over the next three months
>>> with Windows XP Pro boxes (so long Windows 98). Since we
>>> are doing this, we want to take advantage of being able
>>> to "lock down" the machines - especially to keep users
>>> from installing software on them. These workstations
> have
>>> no cd-rom or floppy drives in them.
>>> So here's the deal - I have created an OU with a couple
> of
>>> users and created a Group Policy for the OU and assigned
>>> the application to the users. On the workstations, they
>>> are just normal domain users (I did not make them
>>> administrators of their machines). I can log in as one
> of
>>> the users, and the icon for the application will be
> there,
>>> but when I go to install it I get an error message that
>>> the user does not have access to write something into
> the
>>> Program Files directory. I went back into Group Policy
> and
>>> enabled the "Always install with elevated priviledges"
> in
>>> both the user and computer configurations, refreshed the
>>> policy, allowed it replicate and tried it again - and
> got
>>> the same result. The only way I can get the program to
>>> install is to make the user a power user or
> administrator
>>> of the local machine - which I would seriously like to
>>> avoid. I thought it could have been a problem with the
>>> application so I tried the same thing with Acrobat
> Reader
>>> (after repackaging) and VirusScan Enterprise and got the
>>> same results. Right now I'm at a loss - can anyone give
> me
>>> a clue as to what I may have missed?
>>
>>
>>.
>>

 

[Mikey]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

That seemed to go a little better - I got a different
error this time:

Cannot open Service Control Manager on computer "". The
operation might require other priviliges - Access is
denied.

and then the program just rolls back and says installation
incomplete.

>-----Original Message-----
>Well, since you've set the bit to always install
elevated, you can try
>overriding ALLUSERS from the command-line as a regular
user. That will allow
>you to prove to your developers that its a packaging
issue. So, as a regular
>user, open a command shell and type the following:
>
>msiexec /i \\server\share\myapp.msi ALLUSERS=2
>
>Note that ALLUSERS is case sensitive and must be in upper
case.
>
>
>--
>Darren Mar-Elia
>MS-MVP-Windows Management
>http://www.gpoguy.com
>
>
>
>"Mikey" <anonymous@discussions.microsoft.com> wrote in
message
>news:545d01c48a0c$b1584810$a301280a@phx.gbl...
>> Hmmm - the developers told me they don't want me messing
>> around in their package file. Anything else I can try?
>>
>>>-----Original Message-----
>>>Mikey-
>>>You typically see this when there is something hard-
coded
>> into the MSI
>>>package that is requiring administrator rights--or the
>> package is setup as a
>>>"per-machine" deployment. That would be the first place
I
>> would look--in the
>>>package. There is a property called ALLUSERS, which
>> should be set to 2 for a
>>>non-privileged per-user installation. If you look in the
>> Property table in
>>>the MSI package, double-check that property value.
>>>
>>>
>>>--
>>>Darren Mar-Elia
>>>MS-MVP-Windows Management
>>>http://www.gpoguy.com
>>>
>>>
>>>
>>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
>> message
>>>news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
>>>> I'm trying to use software deployment via Group Policy
>> to
>>>> push down an in-house application but I am having
>> problems
>>>> and can't seem to figure it out. We are about to
replace
>>>> about 90% of our office PCs over the next three months
>>>> with Windows XP Pro boxes (so long Windows 98). Since
we
>>>> are doing this, we want to take advantage of being
able
>>>> to "lock down" the machines - especially to keep users
>>>> from installing software on them. These workstations
>> have
>>>> no cd-rom or floppy drives in them.
>>>> So here's the deal - I have created an OU with a
couple
>> of
>>>> users and created a Group Policy for the OU and
assigned
>>>> the application to the users. On the workstations,
they
>>>> are just normal domain users (I did not make them
>>>> administrators of their machines). I can log in as one
>> of
>>>> the users, and the icon for the application will be
>> there,
>>>> but when I go to install it I get an error message
that
>>>> the user does not have access to write something into
>> the
>>>> Program Files directory. I went back into Group Policy
>> and
>>>> enabled the "Always install with elevated priviledges"
>> in
>>>> both the user and computer configurations, refreshed
the
>>>> policy, allowed it replicate and tried it again - and
>> got
>>>> the same result. The only way I can get the program to
>>>> install is to make the user a power user or
>> administrator
>>>> of the local machine - which I would seriously like to
>>>> avoid. I thought it could have been a problem with the
>>>> application so I tried the same thing with Acrobat
>> Reader
>>>> (after repackaging) and VirusScan Enterprise and got
the
>>>> same results. Right now I'm at a loss - can anyone
give
>> me
>>>> a clue as to what I may have missed?
>>>
>>>
>>>.
>>>
>
>
>.
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

So, this application is trying to install a service, which is probably why
it requires administrative access. That's going to be hard to get around. I
don't think that privilege escalation will help here, though I'm not 100%
sure. It might be worth posting this question on a Windows Installer
newsgroup to see what comes up. I don't think its specifically a GP issue at
this point.

--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com



"Mikey" <anonymous@discussions.microsoft.com> wrote in message
news:c7f001c48a11$b16bddd0$a401280a@phx.gbl...
> That seemed to go a little better - I got a different
> error this time:
>
> Cannot open Service Control Manager on computer "". The
> operation might require other priviliges - Access is
> denied.
>
> and then the program just rolls back and says installation
> incomplete.
>
>>-----Original Message-----
>>Well, since you've set the bit to always install
> elevated, you can try
>>overriding ALLUSERS from the command-line as a regular
> user. That will allow
>>you to prove to your developers that its a packaging
> issue. So, as a regular
>>user, open a command shell and type the following:
>>
>>msiexec /i \\server\share\myapp.msi ALLUSERS=2
>>
>>Note that ALLUSERS is case sensitive and must be in upper
> case.
>>
>>
>>--
>>Darren Mar-Elia
>>MS-MVP-Windows Management
>>http://www.gpoguy.com
>>
>>
>>
>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
> message
>>news:545d01c48a0c$b1584810$a301280a@phx.gbl...
>>> Hmmm - the developers told me they don't want me messing
>>> around in their package file. Anything else I can try?
>>>
>>>>-----Original Message-----
>>>>Mikey-
>>>>You typically see this when there is something hard-
> coded
>>> into the MSI
>>>>package that is requiring administrator rights--or the
>>> package is setup as a
>>>>"per-machine" deployment. That would be the first place
> I
>>> would look--in the
>>>>package. There is a property called ALLUSERS, which
>>> should be set to 2 for a
>>>>non-privileged per-user installation. If you look in the
>>> Property table in
>>>>the MSI package, double-check that property value.
>>>>
>>>>
>>>>--
>>>>Darren Mar-Elia
>>>>MS-MVP-Windows Management
>>>>http://www.gpoguy.com
>>>>
>>>>
>>>>
>>>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
>>> message
>>>>news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
>>>>> I'm trying to use software deployment via Group Policy
>>> to
>>>>> push down an in-house application but I am having
>>> problems
>>>>> and can't seem to figure it out. We are about to
> replace
>>>>> about 90% of our office PCs over the next three months
>>>>> with Windows XP Pro boxes (so long Windows 98). Since
> we
>>>>> are doing this, we want to take advantage of being
> able
>>>>> to "lock down" the machines - especially to keep users
>>>>> from installing software on them. These workstations
>>> have
>>>>> no cd-rom or floppy drives in them.
>>>>> So here's the deal - I have created an OU with a
> couple
>>> of
>>>>> users and created a Group Policy for the OU and
> assigned
>>>>> the application to the users. On the workstations,
> they
>>>>> are just normal domain users (I did not make them
>>>>> administrators of their machines). I can log in as one
>>> of
>>>>> the users, and the icon for the application will be
>>> there,
>>>>> but when I go to install it I get an error message
> that
>>>>> the user does not have access to write something into
>>> the
>>>>> Program Files directory. I went back into Group Policy
>>> and
>>>>> enabled the "Always install with elevated priviledges"
>>> in
>>>>> both the user and computer configurations, refreshed
> the
>>>>> policy, allowed it replicate and tried it again - and
>>> got
>>>>> the same result. The only way I can get the program to
>>>>> install is to make the user a power user or
>>> administrator
>>>>> of the local machine - which I would seriously like to
>>>>> avoid. I thought it could have been a problem with the
>>>>> application so I tried the same thing with Acrobat
>>> Reader
>>>>> (after repackaging) and VirusScan Enterprise and got
> the
>>>>> same results. Right now I'm at a loss - can anyone
> give
>>> me
>>>>> a clue as to what I may have missed?
>>>>
>>>>
>>>>.
>>>>
>>
>>
>>.
>>

 

[Mikey]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

I will try posting it there. I can get around it using
SMS - my only potential problem with that is what if the
guys upstairs say they don't want to spend the money.
Thanks for the help!

>-----Original Message-----
>So, this application is trying to install a service,
which is probably why
>it requires administrative access. That's going to be
hard to get around. I
>don't think that privilege escalation will help here,
though I'm not 100%
>sure. It might be worth posting this question on a
Windows Installer
>newsgroup to see what comes up. I don't think its
specifically a GP issue at
>this point.
>
>--
>Darren Mar-Elia
>MS-MVP-Windows Management
>http://www.gpoguy.com
>
>
>
>"Mikey" <anonymous@discussions.microsoft.com> wrote in
message
>news:c7f001c48a11$b16bddd0$a401280a@phx.gbl...
>> That seemed to go a little better - I got a different
>> error this time:
>>
>> Cannot open Service Control Manager on computer "". The
>> operation might require other priviliges - Access is
>> denied.
>>
>> and then the program just rolls back and says
installation
>> incomplete.
>>
>>>-----Original Message-----
>>>Well, since you've set the bit to always install
>> elevated, you can try
>>>overriding ALLUSERS from the command-line as a regular
>> user. That will allow
>>>you to prove to your developers that its a packaging
>> issue. So, as a regular
>>>user, open a command shell and type the following:
>>>
>>>msiexec /i \\server\share\myapp.msi ALLUSERS=2
>>>
>>>Note that ALLUSERS is case sensitive and must be in
upper
>> case.
>>>
>>>
>>>--
>>>Darren Mar-Elia
>>>MS-MVP-Windows Management
>>>http://www.gpoguy.com
>>>
>>>
>>>
>>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
>> message
>>>news:545d01c48a0c$b1584810$a301280a@phx.gbl...
>>>> Hmmm - the developers told me they don't want me
messing
>>>> around in their package file. Anything else I can try?
>>>>
>>>>>-----Original Message-----
>>>>>Mikey-
>>>>>You typically see this when there is something hard-
>> coded
>>>> into the MSI
>>>>>package that is requiring administrator rights--or the
>>>> package is setup as a
>>>>>"per-machine" deployment. That would be the first
place
>> I
>>>> would look--in the
>>>>>package. There is a property called ALLUSERS, which
>>>> should be set to 2 for a
>>>>>non-privileged per-user installation. If you look in
the
>>>> Property table in
>>>>>the MSI package, double-check that property value.
>>>>>
>>>>>
>>>>>--
>>>>>Darren Mar-Elia
>>>>>MS-MVP-Windows Management
>>>>>http://www.gpoguy.com
>>>>>
>>>>>
>>>>>
>>>>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
>>>> message
>>>>>news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
>>>>>> I'm trying to use software deployment via Group
Policy
>>>> to
>>>>>> push down an in-house application but I am having
>>>> problems
>>>>>> and can't seem to figure it out. We are about to
>> replace
>>>>>> about 90% of our office PCs over the next three
months
>>>>>> with Windows XP Pro boxes (so long Windows 98).
Since
>> we
>>>>>> are doing this, we want to take advantage of being
>> able
>>>>>> to "lock down" the machines - especially to keep
users
>>>>>> from installing software on them. These workstations
>>>> have
>>>>>> no cd-rom or floppy drives in them.
>>>>>> So here's the deal - I have created an OU with a
>> couple
>>>> of
>>>>>> users and created a Group Policy for the OU and
>> assigned
>>>>>> the application to the users. On the workstations,
>> they
>>>>>> are just normal domain users (I did not make them
>>>>>> administrators of their machines). I can log in as
one
>>>> of
>>>>>> the users, and the icon for the application will be
>>>> there,
>>>>>> but when I go to install it I get an error message
>> that
>>>>>> the user does not have access to write something
into
>>>> the
>>>>>> Program Files directory. I went back into Group
Policy
>>>> and
>>>>>> enabled the "Always install with elevated
priviledges"
>>>> in
>>>>>> both the user and computer configurations, refreshed
>> the
>>>>>> policy, allowed it replicate and tried it again -
and
>>>> got
>>>>>> the same result. The only way I can get the program
to
>>>>>> install is to make the user a power user or
>>>> administrator
>>>>>> of the local machine - which I would seriously like
to
>>>>>> avoid. I thought it could have been a problem with
the
>>>>>> application so I tried the same thing with Acrobat
>>>> Reader
>>>>>> (after repackaging) and VirusScan Enterprise and got
>> the
>>>>>> same results. Right now I'm at a loss - can anyone
>> give
>>>> me
>>>>>> a clue as to what I may have missed?
>>>>>
>>>>>
>>>>>.
>>>>>
>>>
>>>
>>>.
>>>
>
>
>.
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Have you run the security configuration thing?

Start an MMC, load Security Configuration and Analysis
and Security Templates snap-ins. Right-click the Security
Configuration and Analysis branch, click open Database.
Give your database a name, then select compatws.inf from
the list of inf files. Then right Click Security
Configuration and Analysis branch and select Configure
Computer Now.

Be warned, I believe this effictively gives users Power
User rights......




>-----Original Message-----
>I will try posting it there. I can get around it using
>SMS - my only potential problem with that is what if the
>guys upstairs say they don't want to spend the money.
>Thanks for the help!
>
>>-----Original Message-----
>>So, this application is trying to install a service,
>which is probably why
>>it requires administrative access. That's going to be
>hard to get around. I
>>don't think that privilege escalation will help here,
>though I'm not 100%
>>sure. It might be worth posting this question on a
>Windows Installer
>>newsgroup to see what comes up. I don't think its
>specifically a GP issue at
>>this point.
>>
>>--
>>Darren Mar-Elia
>>MS-MVP-Windows Management
>>http://www.gpoguy.com
>>
>>
>>
>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
>message
>>news:c7f001c48a11$b16bddd0$a401280a@phx.gbl...
>>> That seemed to go a little better - I got a different
>>> error this time:
>>>
>>> Cannot open Service Control Manager on computer "".
The
>>> operation might require other priviliges - Access is
>>> denied.
>>>
>>> and then the program just rolls back and says
>installation
>>> incomplete.
>>>
>>>>-----Original Message-----
>>>>Well, since you've set the bit to always install
>>> elevated, you can try
>>>>overriding ALLUSERS from the command-line as a regular
>>> user. That will allow
>>>>you to prove to your developers that its a packaging
>>> issue. So, as a regular
>>>>user, open a command shell and type the following:
>>>>
>>>>msiexec /i \\server\share\myapp.msi ALLUSERS=2
>>>>
>>>>Note that ALLUSERS is case sensitive and must be in
>upper
>>> case.
>>>>
>>>>
>>>>--
>>>>Darren Mar-Elia
>>>>MS-MVP-Windows Management
>>>>http://www.gpoguy.com
>>>>
>>>>
>>>>
>>>>"Mikey" <anonymous@discussions.microsoft.com> wrote in
>>> message
>>>>news:545d01c48a0c$b1584810$a301280a@phx.gbl...
>>>>> Hmmm - the developers told me they don't want me
>messing
>>>>> around in their package file. Anything else I can
try?
>>>>>
>>>>>>-----Original Message-----
>>>>>>Mikey-
>>>>>>You typically see this when there is something hard-
>>> coded
>>>>> into the MSI
>>>>>>package that is requiring administrator rights--or
the
>>>>> package is setup as a
>>>>>>"per-machine" deployment. That would be the first
>place
>>> I
>>>>> would look--in the
>>>>>>package. There is a property called ALLUSERS, which
>>>>> should be set to 2 for a
>>>>>>non-privileged per-user installation. If you look
in
>the
>>>>> Property table in
>>>>>>the MSI package, double-check that property value.
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Darren Mar-Elia
>>>>>>MS-MVP-Windows Management
>>>>>>http://www.gpoguy.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>"Mikey" <anonymous@discussions.microsoft.com> wrote
in
>>>>> message
>>>>>>news:c6ee01c48a02$99be4dd0$a401280a@phx.gbl...
>>>>>>> I'm trying to use software deployment via Group
>Policy
>>>>> to
>>>>>>> push down an in-house application but I am having
>>>>> problems
>>>>>>> and can't seem to figure it out. We are about to
>>> replace
>>>>>>> about 90% of our office PCs over the next three
>months
>>>>>>> with Windows XP Pro boxes (so long Windows 98).
>Since
>>> we
>>>>>>> are doing this, we want to take advantage of being
>>> able
>>>>>>> to "lock down" the machines - especially to keep
>users
>>>>>>> from installing software on them. These
workstations
>>>>> have
>>>>>>> no cd-rom or floppy drives in them.
>>>>>>> So here's the deal - I have created an OU with a
>>> couple
>>>>> of
>>>>>>> users and created a Group Policy for the OU and
>>> assigned
>>>>>>> the application to the users. On the workstations,
>>> they
>>>>>>> are just normal domain users (I did not make them
>>>>>>> administrators of their machines). I can log in
as
>one
>>>>> of
>>>>>>> the users, and the icon for the application will
be
>>>>> there,
>>>>>>> but when I go to install it I get an error message
>>> that
>>>>>>> the user does not have access to write something
>into
>>>>> the
>>>>>>> Program Files directory. I went back into Group
>Policy
>>>>> and
>>>>>>> enabled the "Always install with elevated
>priviledges"
>>>>> in
>>>>>>> both the user and computer configurations,
refreshed
>>> the
>>>>>>> policy, allowed it replicate and tried it again -
>and
>>>>> got
>>>>>>> the same result. The only way I can get the
program
>to
>>>>>>> install is to make the user a power user or
>>>>> administrator
>>>>>>> of the local machine - which I would seriously
like
>to
>>>>>>> avoid. I thought it could have been a problem
with
>the
>>>>>>> application so I tried the same thing with Acrobat
>>>>> Reader
>>>>>>> (after repackaging) and VirusScan Enterprise and
got
>>> the
>>>>>>> same results. Right now I'm at a loss - can anyone
>>> give
>>>>> me
>>>>>>> a clue as to what I may have missed?
>>>>>>
>>>>>>
>>>>>>.
>>>>>>
>>>>
>>>>
>>>>.
>>>>
>>
>>
>>.
>>
>.
>