How to give a user local administrator permission on all client pc in AD?
I just want to give a user local administrator permission on all client pc, but not any domain permission. I know I can just add the user manually in local admin group on each pc. How can I do this in AD?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you Mike!! the article is excellent!
And I also read the link that Akhater provides:
>>When you configure the members of a group, it will overwrite the existing membership of the group and replace the members with those specified within the GPO. If you were to configure this setting and leave the members blank, then the group would not have any members after the GPO applied to the computer.
I think this paragraph is wrong, even I leave the member field empty, it still have its original member.
Lastly, I sucefully made it work by following the link mike provided. However, after I applied the GPO and then reboot the client pc, it didn't take effect for the first time...... then I had to run gpupdate/ force on both, then log back in the client, it works.... why?
And I also read the link that Akhater provides:
>>When you configure the members of a group, it will overwrite the existing membership of the group and replace the members with those specified within the GPO. If you were to configure this setting and leave the members blank, then the group would not have any members after the GPO applied to the computer.
I think this paragraph is wrong, even I leave the member field empty, it still have its original member.
Lastly, I sucefully made it work by following the link mike provided. However, after I applied the GPO and then reboot the client pc, it didn't take effect for the first time...... then I had to run gpupdate/ force on both, then log back in the client, it works.... why?
I'm going to test the paragraph about leaving it blank (never tried that one). I'll put the results on my blog (just started the blog) http://adisfun.blogspot.co
Thanks
Mike
Thanks
Mike
There is a chance that you reboot and logged on too quickly before all the IP and everthing get assigned and be applied. Of course this depending on your network enviornments as well as what gets loaded on your workstation etc. If you wait a bit, it will eventually be applied, which is normal.
After changing a group policy or changing the OU of a computer you will often find it needed to reboot twce for the new policies to be applied and take effect.
At the first boot the computer will know it has new policies to apply and the second boot it will actually apply them.
Of course leaving the computer running long enough for it to refresh its policies or run gpupdate will eliminate the need of one or both reboots (depending on the policies)
At the first boot the computer will know it has new policies to apply and the second boot it will actually apply them.
Of course leaving the computer running long enough for it to refresh its policies or run gpupdate will eliminate the need of one or both reboots (depending on the policies)
ASKER
>>At the first boot the computer will know it has new policies to apply and the second boot it will actually apply them.
Sounds very inefficient.... If I enable "Always waits for the network at computer startup and logon".... will this fix the problem?
Sounds very inefficient.... If I enable "Always waits for the network at computer startup and logon".... will this fix the problem?
>>Sounds very inefficient....<<
actually it is to make the computer boot faster
You are facing this problem only because you are testing, creating a policy (or changing a computer from OU to another) and directly rebooting.
In a day to day operation GPO will get refresh by the computer periodically (as if you had gpupdate run) and the computer will have its new policies applied
>>If I enable "Always waits for the network at computer startup and logon".... will this fix the problem?<<
I am not sure but I really doubt
actually it is to make the computer boot faster
You are facing this problem only because you are testing, creating a policy (or changing a computer from OU to another) and directly rebooting.
In a day to day operation GPO will get refresh by the computer periodically (as if you had gpupdate run) and the computer will have its new policies applied
>>If I enable "Always waits for the network at computer startup and logon".... will this fix the problem?<<
I am not sure but I really doubt
BTW, the suggestion "Always wait for the netowork..." is not an good idea in my experience. It will take too long due to many reaons that has nothing to do with your active directory, it may even be the configuration of the switch where the machine are plugged in, DHCP is down and cannot assign an IP, etc. It is not necessary to force all users to have this policy set as enabled.
By default, Windows XP logs a user on in asynchronous mode. Group Policy is then applied in the background after the user is logged on. This results in faster logons.
In situations where you need for users to receive software, implement folder redirection, or run new scripts in a single logon, then you may apply a GPO with the setting Always wait for the network at computer startup and logon to the computer. For this setting to take effect, Group Policy must be refreshed or the computer restarted. This decision also depending on how you want your users to react to the logon time....
By default, Windows XP logs a user on in asynchronous mode. Group Policy is then applied in the background after the user is logged on. This results in faster logons.
In situations where you need for users to receive software, implement folder redirection, or run new scripts in a single logon, then you may apply a GPO with the setting Always wait for the network at computer startup and logon to the computer. For this setting to take effect, Group Policy must be refreshed or the computer restarted. This decision also depending on how you want your users to react to the logon time....
To clarify, it really depending on how your network enviornment structured and configured that could have an impact on user logon time. Expecially on enviornment that has an internal network, guest network, port authentication, usually the more secure the more dependencies there is..
Need more clarification
<<BTW, the suggestion "Always wait for the netowork..." is not an good idea in my experience. It will take too long due to many reaons that has nothing to do with your active directory, it may even be the configuration of the switch where the machine are plugged in, DHCP is down and cannot assign an IP, etc. It is not necessary to force all users to have this policy set as enabled.>>
Let me rephase this--"Always wait for the network" is not an bad idea if it's needed. But it should be used.
This means in your case for restriced group, it's not a must have in the first reboot so it won't be necessary.
Also, in a complex environment, there may be network configuration that required a computer account authentication and later a user authentication before the users gets put in a dedicated subnet to have certain things fully functional. Sometime for wireless is even more restricted could also slow down the process...but keep in mind that computer GPO gets refresh every 90 minutes and your restricted group GPO should not be a concern.
<<BTW, the suggestion "Always wait for the netowork..." is not an good idea in my experience. It will take too long due to many reaons that has nothing to do with your active directory, it may even be the configuration of the switch where the machine are plugged in, DHCP is down and cannot assign an IP, etc. It is not necessary to force all users to have this policy set as enabled.>>
Let me rephase this--"Always wait for the network" is not an bad idea if it's needed. But it should be used.
This means in your case for restriced group, it's not a must have in the first reboot so it won't be necessary.
Also, in a complex environment, there may be network configuration that required a computer account authentication and later a user authentication before the users gets put in a dedicated subnet to have certain things fully functional. Sometime for wireless is even more restricted could also slow down the process...but keep in mind that computer GPO gets refresh every 90 minutes and your restricted group GPO should not be a concern.
ASKER
do you guys know answers to this 2 questions? Thank you.
https://www.experts-exchange.com/questions/24325387/question-about-deploying-software-in-AD-environment.html
https://www.experts-exchange.com/questions/24326354/winodws-2003-GPO-Folder-redirection-offline-file.html?anchorAnswerId=24153663#a24153663
https://www.experts-exchange.com/questions/24325387/question-about-deploying-software-in-AD-environment.html
https://www.experts-exchange.com/questions/24326354/winodws-2003-GPO-Folder-redirection-offline-file.html?anchorAnswerId=24153663#a24153663
Create a Global Group in AD, Called Local PC Administrators. Add this Group Local PC Administrators to the Local Administrator account on the PCs. Then add users that you would like to be Local Administrators only to this AD group Local PC Administrators..