| Author |
secedit/refesh---where?
|
|
| rpike 2002-09-03, 10:07 pm |
| Hi all:
When invoking secedit refresh (either machine or user) after editing a GPO, does one invoke it from the DC the gpo originates on or the workstation it's applying to?
thanks
rp | |
| kevinvasoft 2002-09-04, 4:04 pm |
| secedit refreshpolicy shd be carried out on the machine the policy applies to. | |
| Deja-vue 2002-09-04, 7:16 pm |
| secedit refreshpolicy should be carried out on the Domain controller.
what if you have a GPO that affects 1000's of Machines, all a few hundred miles away?
just my 2 | |
| Tech Ranger 2002-09-04, 7:59 pm |
| I agree with Deja-vue 1000%. The DC pushes the procesing. The WS can't pull a refresh. | |
| rpike 2002-09-04, 11:06 pm |
| Thanks all:
That was my problem. I was getting conflicting information.
Believe it or not I tried refreshing on the DC AND the target workstation and both updated the new GPO setting.
I think MS is looking for the DC answer.
Any more comments would be most appreciated.
Thanks again.
rp | |
| Tech Ranger 2002-09-05, 6:02 am |
| When you do a secedit refresh on the ws, you are updating local policy. | |
| Slinky 2002-09-05, 9:41 am |
| quote:
Originally posted by Tech Ranger
I agree with Deja-vue 1000%. The DC pushes the procesing. The WS can't pull a refresh.
Sure it can, thats why you can run secedit on a Windows 2000 Professional based machine. It is true that client computers do periodically poll the domain controller for policy changes, but to refresh the settings immediately you will need to run secedit.
http://support.microsoft.com/defaul...;EN-US;Q227302& | |
| Deja-vue 2002-09-05, 11:01 am |
| Good link, slinky. ( as always )
I still think, to use good practice, to do the secedit refreshpolicy at a DC.
This is where you create the Group policies, and there is where it should be done.
This is how i learned it anyways.
Some User machines may not even have the "run" tab...
(could not resist,  ) | |
| Tech Ranger 2002-09-05, 6:52 pm |
| Can you tell me where in the link it says that a ws can pull a refresh from a DC? | |
| Slinky 2002-09-05, 7:41 pm |
| Whats the difference between a workstation pulling a refresh or the domain controller pushing one? I understand the difference in WINS, but as far as group policies are concerned I am a little unclear. This is new terminology to me. The workstation queries the domain controler as defined by the 'Group Policy Refresh Interval' for updates, and the domain controller then updates the client. I can see how this would be considered as pushing. Please explain. | |
| Tech Ranger 2002-09-05, 7:46 pm |
| Please excuse the terminology if it is inappropriate to the topic. My situation is that I have always been under the impression that a refresh using secedit is a command to the dc to download policy updates to machines governed by GPO's. I never knew that secedit refresh policy can be executed at the client, and that as a consequence the dc would respond with a premature update. I admit to being stupid, but I may be right or I may be wrong. I would just like a little documentation to back up the assertion that secedit can be run from the AD client to request an immediate refresh. | |
|
|
| Tech Ranger 2002-09-05, 8:18 pm |
| Does this mean that ALL refreshes are done by virtue of the clients requesting the refreshes? The dc's do not initiate the process? | |
| Slinky 2002-09-05, 8:43 pm |
| Ok, I've got more information. The default period is every 5 minutes for domain controllers, and every 90 minutes with a randomized offset of up to 30 minutes for client computers. This random offset is so that every client doesn't request a refresh at the same time. This would create a lot of traffic. If you need to change this setting you will find it in the 'Default Domain Controllers Group Policy' object. The setting is located under Computer Configuration/Administrative Templates/System/Group Policy/Group Policy Refresh Interval for Computers. There is also a 'Group Policy Refresh Interval for Domain Controllers'.
I know thats a lot of extra stuff that doesn't even pertain to the orginal question, so thats just FYI. FYI for me too since I forgot most of this since 70-217. | |
| Deja-vue 2002-09-05, 8:49 pm |
| OK, so Slinky is right. (not the first time, darn).
But let me ask you Gentlemen a "common sense" Question:
Shouldn't it be practice to do it on a DC instead of a Workstation?
Because on the DC is where you create all those Changes in the first place and then replicate it over the Domain.Why do it on a workstation? ( i know now, it is possible, but why?).
Any thoughts, friends?
| |
| Slinky 2002-09-05, 8:56 pm |
| The biggest reason is troubleshooting. Lets say that you have a member server that you need someone to login to interactively. Lets say that he/she is is a domain user, which by default cannot login interactively. So you go in and modify group policy and allow that person to login. After you think you did it right, the person still can't login. So you go in and discover that you accidently added Bob instead of Joe, so you change it. So are you going to wait 90 minutes for Joe to try and login again? I hope not, unless you are getting paid by the hour, when you can run secedit to make it happen immediately.
Make sense? | |
| Slinky 2002-09-05, 8:58 pm |
| quote:
Originally posted by Deja-vue
OK, so Slinky is right. (not the first time, darn).
I've been wrong too. Remember the 6-pack. | |
|
|
| rpike 2002-09-08, 10:36 am |
| Thanks to all (again).
So what I'm getting is that the client does the requesting which would explain the reason the refresh worked on both DC and WS.
I was under the assumption that only the DC (not the workstation/client) was responsible for getting the policy to the client.
Thanks for clearing it up!
rp | |
|
|
| Deja-vue 2002-09-08, 11:48 pm |
| would be fine,Slinky.
PM me your address....
|
|
|
|