|
|
|
Can't install software on W2k
|
Original Message
|
Name: Chug
Date: December 20, 2004 at 15:45:19 Pacific
Subject: Can't install software on W2kOS: Windows 2000CPU/Ram: Pentium 4 |
Comment: This is Windows 2000 workstations in a 2000 AD domain. Logging into the PC with a domain user ID. The domain user ID IS a member of the local Administrators group on the PC. I can install other software but I have one particular piece of software that still says "You must have the administrator right to install this software on this computer" when I try to install it. If I log in with a local user ID that's also a member of the local Administrators group, the software installs. But it's tied to the user profile so I HAVE to be able to install as the user that's going to use it. I've talked to the software vendor's tech support and they claim there shouldn't be an issue, they install using domain user ID's as local Administrators all the time. They say it has to be something with our Windows 2000 setup. But this is also the ONLY piece of software we have trouble with. Is there anything besides having a domain user ID a member of the local administrators group that can prevent software from installing? A registry setting, or local policy setting or something? Thanks!
Report Offensive Message For Removal
|
|
Response Number 2
|
Name: Chug
Date: December 21, 2004 at 07:26:35 Pacific
|
Reply: (edit)Yes. That does at least allow the software to install, but as I said in my original note, this software is tied to the user's profile and when installing with RunAs, it doesn't install right into the currently logged on profile. Also, when this goes to production, we need the users to be able to install it themselves and don't want to complicate things for them by having them have to use RunAs, or by having to type in a password for a local account.
Report Offensive Follow Up For Removal
|
|
Response Number 4
|
Name: deej
Date: December 23, 2004 at 08:32:28 Pacific
|
Reply: (edit)I've ran into this a time or two in the past try raising the users privileges to admin then complete the install and drop them back to their original security level. However if you do not have domain level admin rights your not going to be able to change the user level rights on the domain.
Report Offensive Follow Up For Removal
|
|
Response Number 5
|
Name: Chug
Date: December 23, 2004 at 12:33:12 Pacific
|
Reply: (edit)Yes, I've verified many times that the domain ID is a member of the local Administrators group. darell, what do you mean by raising the user privaleges to admin? How is that different than making the user ID a member of the local Administrators group? You are correct that I do not have domain level admin rights and if this something to do in the domain itself vs. the local PC, that won't be an option for me.
Report Offensive Follow Up For Removal
|
|
Response Number 6
|
Name: Chug
Date: December 28, 2004 at 08:06:27 Pacific
|
Reply: (edit)Update. I've set up an isolated dummy AD environment in a lab with 2 PC's, one acting as the domain controller, the other acting as a standard workstation. The software DOES install okay in that environment under a domain user ID that is part of the local Administrator's group on the workstation PC. The DC is a Widnows 2003 standard server. The workstation PC is a Windows 2000 workstation. The workstation PC is actually the exact same one I used when testing in our production environment, I just joined it to my dummy domain. So the problem can't be on the PC, it's got to be something with AD. A permission perhaps? Unfortunately, I'm no AD expert, but I didn't do anything special when creating the domain user ID in AD so it shouldn't have any special permissions. The only group in AD that the user ID is a member of is the built-in Domain Users group. But can anybody think of a custom AD permission that our Corporate AD people may have taken away from our AD rights that could cause this software not to install? Thanks again!
Report Offensive Follow Up For Removal
|
|
Response Number 7
|
|
Reply: (edit)AD will apply most restrictive rights. Check to make sure that user is not in any other group. It may also be a corrupt profile, if this is the case, delete the profile on the local machine...also delete their name from AD and copy a known working profile. Log in again and send me a check.
Report Offensive Follow Up For Removal
|
|
Response Number 8
|
Name: amcell
Date: January 18, 2005 at 06:30:10 Pacific
|
Reply: (edit)Had same problem and likewise was thinking too much about it rather than the simple approach. User on domain will be a member of "domain users" group. On Local machine make domain user a member of Administrive group and voila. Only problem is that teh domain user now has install access to that local machine but domain restrictions still apply. Hope it helps.
Report Offensive Follow Up For Removal
|
Use following form to reply to current message:
|
|

|