+ Reply to Thread
Results 1 to 4 of 4

Thread: Remote gpupdate /force

  1. #1
    deviant_pal is offline Getting Started on GPanswers.com
    Join Date
    Dec 1969
    Posts
    2

    Default

    Please forgive me if this is the wrong forum to ask this question, but my issue stems around being able to run gpudate /force remotely on a workstation as opposed to waiting the 60-90 minutes for the new policy to take effect. (I think that's the timeframe.)

    Here's the scenario: We have very high security settings in place (Least User Privilege) and can ONLY manage a workstation if we move the machine in Active Directory to a "Maintenance OU" and then run gpupdate /force. If we're sitting at the workstation, running gpupdate /force is trivial, but attempting to run gpupdate over the network is my issue. By moving the machine to the Maintenance OU, and subsequently running gpupdate /force, then we are allowed to manage the workstation and help troubleshoot technical issues.

    I have found gprefresh from GPO Guy, but am not sure if it will work for what I need to do. I have also found a utility that we could right click | Update GPO from within Active Directory which might do the trick, but here again I assume you'd have to be an administrator on the workstation to run this utility.

    I can't imagine we're the only company running a "very tight ship", but does anyone know if there's a way to run gpupdate /force on a system remotely? This update is what will give us rights to administer the workstation, so having those rights initially sorta defeats the purpose.

    Hope I've explained this well enough to understand and that someone can lend a hand with this seemingly trivial issue.

    Thanks so much!
    Janis

  2. #2
    pago is offline 10+ Helpful Posts 20+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    25

    Default

    Janis,
    if I understood your issue correctly then you do not have administrative permission on the workstation you have to manage until you move the client to the special OU and the first GPO refresh cycle is processed, right?
    Probably you have a GPO which utilizes Restricted Groups feature to grant the needed permissions?
    To make this faster, you want to manually trigger gpo refresh cycle.

    All solutions to remotely execute a task will request administrative permissions.
    And of course, this good for security reasons ;-)
    How to overcome this?
    Hm, I don't think there is a "built in" solution for that.
    My idea would be something like this:
    - don't run the task remotely
    - Create a share on each client that you can use as "maintenance enable switch"
    - Create a script/program that runs on each client and that polls that local directory for a certain trigger file
    - if the file is found by the process, gpupdate /force shall be executed
    You will also need a trigger for the script so that you can be sure it runs on every machine.
    A real serice would be perfect. Not as robust, but easier to implement: A scheduled task or even just a startup script.

    You think this could be a solution for you?

    ________
    Patrick

  3. #3
    deviant_pal is offline Getting Started on GPanswers.com
    Join Date
    Dec 1969
    Posts
    2

    Default

    Hi Patrick--
    Just back after a few days off and found your reply, so I thought I would respond.

    Yes, you are correct. We do NOT have admin rights on the workstation due to a GPO that is applied to all systems. Once we move the machines into the Maintenance OU, we either have to wait until the next policy is applied, or make some kind of attempt to run gpupdate /force remotely. I have only been working for this company a few months, so I'm not completely sure of the configuration but the bottom line is the same. We are not admins on the workstations, for security/audit purposes, until we move the machine into the Maintenance OU. Now, if we physically visited the machine, and the SCCM client was healthy, then within "Run Advertised Programs" a user can run a program that gives a domain group rights to their machine and then proceeds to run gpudate /force under the context of their account.

    I'm not quite sure I understand your solution, but have an idea of what you might be suggesting. Basically there's really no way to run gpupdate /force remotely on a system unless you're already an admin on that machine. Is that a correct statement? You're suggesting a "maint enabled switch" share. Create a script that runs on each system to be managed, looking for a specific file. If found, run gpupdate /force. I believe I have found that DSQuery will help me determine the machine's original location in AD while DSMove will allow me to move a list of machines to the Maintenance OU. During that move process, I place a file on the machines being administered so that when the local script runs and finds that file, gpupdate /force will be triggered. Dang. Almost as easy to move machine manually in AD and wait for the GPO policy to update iteself. But that's just me.

    Have you used the utility that allows you to Right Click | GPUpdate /Force on an OU in Active Directory? I haven't tried it, but assume you'd have to be an admin to run it remotely.

    I would think there are more people in the same high security boat as us who want to do something like this. Maybe that's a naive assumption.

    Thanks for the reply, Patrick. Back to the drawing board.

    Janis

  4. #4
    pago is offline 10+ Helpful Posts 20+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    25

    Default

    Yes, either you need local admin rights or a uitility that runs on the client which can be triggered witout admin rights.
    My understanding was that your main issue is you don't want to wait until automatic GPO refresh.
    So if you follow my advise, create a share on each client (where you have permissions without being admin)
    and a repeatingly polling script (which in addition does not need to run with admin privileges) you could achieve much shorter waiting times
    until have real admin permission on the clients.
    Using your standard software deployment tool just rollout out that stuff (share creation, script, scheduled task) an all machines are prepared.

    To answwer your question: No, I have not tried the "Right Click on OU" solution, but I am quite it also follows what I stated in my first sentence in this comment.

    So do you think that my idea is way for you to proceed?

+ Reply to Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Search Engine Friendly URLs by vBSEO