I have a single Windows 2000 server setup as Active Domain Controller,
about 10 user. A few PC run XP pro, the rest run win98. Having
problems with one XP Pro PC and user getting rights to install
programs on this PC.

I have made this XP Pro system a member of the domina, can login in
correctly, but I am having a heck of a time getting rights to flow
through to the machine. I would perfer the user to have Admin
privelages when they login in to local machine, will help elminate
Application install issue.

What is the best and least painless way around this.

The user is having problems installing software on this machine because
he/she does not have the proper privileges / access to specific registry
keys.

One way to get around this is to add the user's Domain User Account object
to the local computer's Administrators group. This might not be such a
great idea, though. The user now has total access to that machine and can
do a lot of damage if he/she is the 'curious' type or the 'knows just enough
to get in trouble' type. You know your environment better than anyone,
though, so that is your call.

Another idea is for you to install all of the software that they are going
to need either logged onto the machine as a Domain Admin ( as the Domain
Admins group is - by default - a member of the local Administrators group on
all WIN2000 and WIN XP systems in the domain ) or when logged on locally as
the local Administrator. This possibly creates more work for you, though.

Another thought is that you make use of Group Policy to deploy software.
This may or may not be entirely feasible as I am not aware of the software
that you are trying to install. In order to make use of Group Policy the
application needs to have an .msi file ( 'replaces' the old acme setup.exe
method ). If the application does not have an .msi file then it is possible
to create one using a variety of third-party applications. There is a free
utility call WinInstall Lite ( or something like this ) on the WIN2000
Server CD. I am not really a fan of this method but could help you.

I would really suggest strongly that you do not make the users a member of
the Domain Admins group.

Please be aware that GPO applies to WIN2000 Pro and WINXP Pro systems only.
You should have no problems installing software on a WIN98 system ( which
can be a problem in and of itself! ).

HTH,

Cary

"fubarsnafu2004" wrote in message
news:624f5166.0403020612.3f6aa662@posting.google.com...
> I have a single Windows 2000 server setup as Active Domain Controller,
> about 10 user. A few PC run XP pro, the rest run win98. Having
> problems with one XP Pro PC and user getting rights to install
> programs on this PC.
>
> I have made this XP Pro system a member of the domina, can login in
> correctly, but I am having a heck of a time getting rights to flow
> through to the machine. I would perfer the user to have Admin
> privelages when they login in to local machine, will help elminate
> Application install issue.
>
> What is the best and least painless way around this.

I have tried the Login in and install as admin but it gets to be a
hassle, last time the user couldn't use the software until I logged
back in as admin and specifically give him rights to the new folder,
which is weird because from what I read in some MS knowledge base or
manuals/books he should have had the rights becuase of the everyone
group. I have seen this on stand alone Win2000 systems when user is
only member of User Group, I had to manually give rights to run
applications.

I though I tried to make his domain account a member of the Local
systems Admin group and couldn't do it, I will try again tomorrow.

"Cary Shultz [A.D. MVP]" wrote in message news:<#6EUSPGAEHA.3400@tk2msftngp13.phx.gbl>...
> The user is having problems installing software on this machine because
> he/she does not have the proper privileges / access to specific registry
> keys.
>
> One way to get around this is to add the user's Domain User Account object
> to the local computer's Administrators group. This might not be such a
> great idea, though. The user now has total access to that machine and can
> do a lot of damage if he/she is the 'curious' type or the 'knows just enough
> to get in trouble' type. You know your environment better than anyone,
> though, so that is your call.
>
> Another idea is for you to install all of the software that they are going
> to need either logged onto the machine as a Domain Admin ( as the Domain
> Admins group is - by default - a member of the local Administrators group on
> all WIN2000 and WIN XP systems in the domain ) or when logged on locally as
> the local Administrator. This possibly creates more work for you, though.
>
> Another thought is that you make use of Group Policy to deploy software.
> This may or may not be entirely feasible as I am not aware of the software
> that you are trying to install. In order to make use of Group Policy the
> application needs to have an .msi file ( 'replaces' the old acme setup.exe
> method ). If the application does not have an .msi file then it is possible
> to create one using a variety of third-party applications. There is a free
> utility call WinInstall Lite ( or something like this ) on the WIN2000
> Server CD. I am not really a fan of this method but could help you.
>
> I would really suggest strongly that you do not make the users a member of
> the Domain Admins group.
>
> Please be aware that GPO applies to WIN2000 Pro and WINXP Pro systems only.
> You should have no problems installing software on a WIN98 system ( which
> can be a problem in and of itself! ).
>
> HTH,
>
> Cary
>
> "fubarsnafu2004" wrote in message
> news:624f5166.0403020612.3f6aa662@posting.google.com...
> > I have a single Windows 2000 server setup as Active Domain Controller,
> > about 10 user. A few PC run XP pro, the rest run win98. Having
> > problems with one XP Pro PC and user getting rights to install
> > programs on this PC.
> >
> > I have made this XP Pro system a member of the domina, can login in
> > correctly, but I am having a heck of a time getting rights to flow
> > through to the machine. I would perfer the user to have Admin
> > privelages when they login in to local machine, will help elminate
> > Application install issue.
> >
> > What is the best and least painless way around this.

The only time I have seen this problem was a good time back when a select
few users could not run MS Access 2000 unless they were a member of the
local Administrators group. Did not really spend too much time on it as
there were other reasons to do this for them anyway ( although I never like
doing that! ).

If you have any problems please feel free to post again...

Cary

"fubarsnafu2004" wrote in message
news:624f5166.0403021448.19733494@posting.google.com...
> I have tried the Login in and install as admin but it gets to be a
> hassle, last time the user couldn't use the software until I logged
> back in as admin and specifically give him rights to the new folder,
> which is weird because from what I read in some MS knowledge base or
> manuals/books he should have had the rights becuase of the everyone
> group. I have seen this on stand alone Win2000 systems when user is
> only member of User Group, I had to manually give rights to run
> applications.
>
> I though I tried to make his domain account a member of the Local
> systems Admin group and couldn't do it, I will try again tomorrow.
>
> "Cary Shultz [A.D. MVP]" wrote in message
news:<#6EUSPGAEHA.3400@tk2msftngp13.phx.gbl>...
> > The user is having problems installing software on this machine because
> > he/she does not have the proper privileges / access to specific registry
> > keys.
> >
> > One way to get around this is to add the user's Domain User Account
object
> > to the local computer's Administrators group. This might not be such a
> > great idea, though. The user now has total access to that machine and
can
> > do a lot of damage if he/she is the 'curious' type or the 'knows just
enough
> > to get in trouble' type. You know your environment better than anyone,
> > though, so that is your call.
> >
> > Another idea is for you to install all of the software that they are
going
> > to need either logged onto the machine as a Domain Admin ( as the Domain
> > Admins group is - by default - a member of the local Administrators
group on
> > all WIN2000 and WIN XP systems in the domain ) or when logged on locally
as
> > the local Administrator. This possibly creates more work for you,
though.
> >
> > Another thought is that you make use of Group Policy to deploy software.
> > This may or may not be entirely feasible as I am not aware of the
software
> > that you are trying to install. In order to make use of Group Policy
the
> > application needs to have an .msi file ( 'replaces' the old acme
setup.exe
> > method ). If the application does not have an .msi file then it is
possible
> > to create one using a variety of third-party applications. There is a
free
> > utility call WinInstall Lite ( or something like this ) on the WIN2000
> > Server CD. I am not really a fan of this method but could help you.
> >
> > I would really suggest strongly that you do not make the users a member
of
> > the Domain Admins group.
> >
> > Please be aware that GPO applies to WIN2000 Pro and WINXP Pro systems
only.
> > You should have no problems installing software on a WIN98 system (
which
> > can be a problem in and of itself! ).
> >
> > HTH,
> >
> > Cary
> >
> > "fubarsnafu2004" wrote in message
> > news:624f5166.0403020612.3f6aa662@posting.google.com...
> > > I have a single Windows 2000 server setup as Active Domain Controller,
> > > about 10 user. A few PC run XP pro, the rest run win98. Having
> > > problems with one XP Pro PC and user getting rights to install
> > > programs on this PC.
> > >
> > > I have made this XP Pro system a member of the domina, can login in
> > > correctly, but I am having a heck of a time getting rights to flow
> > > through to the machine. I would perfer the user to have Admin
> > > privelages when they login in to local machine, will help elminate
> > > Application install issue.
> > >
> > > What is the best and least painless way around this.