locked
Run GPupdate as TS Step RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    Need to run a GPUpdate/Force at end of task sequence to try to get machine policies updated prior to first user logging in. Have added simple run command line step " cmd.exe /c  gpupdate /force". Task sequence seems to hang and timeout after 10 minutes. I've seen another thread saying its not happy running in system contect. Anyone else hit this?
    Ian Burnell, London (UK)
    Friday, March 11, 2011 2:22 PM

Answers

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello - Have you seen this ?
    http://social.technet.microsoft.com/Forums/en/configmgrosd/thread/939f507a-7167-42e2-9d8f-082de378d16d

    c:\windows\system32\reg.exe add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce" /v GPupdate /d "C:\windows\system32\gpupdate.exe" /f

    This adds a runonce key which executes a gpupdate the first time a user logs on the machine.

     

    Anoop C Nair
    Friday, March 11, 2011 3:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I hadn't seen that article - thanks

    Sadly the policy issue at this site needs to be applied before logging in as there is some rogue policy preventing logon. Somehting about IE8 Branding policy. If a standard user tries to login after build it comes up with "could not connect to the system event notification service". This is fixed by policies but only when they are applied. I'm interested that the article says that setup Windows and Configmgr step says it should do a policy refresh because it doesn't appear to have added the computer policy (win 7 deployment)

    After logging in locally and doing a gpupdate /force then a normal user can logon

    Ian Burnell, London (UK)
    Friday, March 11, 2011 3:36 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Here's the statement for Technet (http://technet.microsoft.com/en-us/library/bb693951.aspx):

    "The Setup Windows and ConfigMgr task sequence action is responsible for running Group Policy on the newly installed computer. The time at which Group Policy is applied during the task sequence action depends on the operating system being deployed. For Windows XP and Windows Server 2003, Group Policy is applied after the Setup Windows and ConfigMgr task sequence action is completed. On Windows Vista and Windows Server 2008, Group Policy is applied after the task sequence is finished."

    Are you saying you are not seeing this behavior?

    Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
    Friday, March 11, 2011 4:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Certainly doesn't appear to Jason. I haven't tested it exhaustively but you certainly cannot logon to a newly built PC at this client until after the computer policy has been applied. I would assume that Windows 7 follows Vista in that policies should be applied at the end of the Task Sequence

    Given that it looks like you can't do a simple gpupdate within the TS the only way I was thinking would be to write reg keys to execute a file as a startup script (which runs GPUpdate) and then at the end of the TS search and delete the reg keys and file related to it - Thats the only way I can think.

    Ian Burnell, London (UK)
    Friday, March 11, 2011 8:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Jason is correct. 

    The further explain, GP cannot be applied during a task sequence, it is essentially blocked.  When a task sequence finishes, it does not force any kind of refresh, but the machine is in a state where GP can now be applied.  If it is critical to apply GP immediately, using a reg key and script is generally a good way

    John Vintzel Microsoft Corporation| Program Manager | System Center Configuration Manager | twitter: jvintzel http://blogs.technet.com/b/inside_osd
    Friday, March 11, 2011 10:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Jason is correct. 

    The further explain, GP cannot be applied during a task sequence, it is essentially blocked.  When a task sequence finishes, it does not force any kind of refresh, but the machine is in a state where GP can now be applied.  If it is critical to apply GP immediately, using a reg key and script is generally a good way

    John Vintzel Microsoft Corporation| Program Manager | System Center Configuration Manager | twitter: jvintzel http://blogs.technet.com/b/inside_osd


    Thanks John - so we're all agreed you can't run any sort of gpupdate during the TS that's fine BUT if the Setup Windows and Configmgr task is supposed to run a GPO update why wouldn't the computer policies applicable to the AD container the machine is added to not already be in force when the Task Sequence is finished i.e. the machine is sitting at the logon screen ?

    Ian Burnell, London (UK)
    Sunday, March 13, 2011 8:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    if the client is win7, the GP refresh will be deferred until the TS is completed. once the TS is complete, normal GP processing applies. this is then subject to your GP configuration, and the GP CSE behaviours of win7.
    are you using background refresh, what is the refresh cycle you have in place (or do you have that disabled)?
    are the settings you're looking for computer-settings or user-settings?
    are the settings applied, but require a client restart to become effective?
    typically, GP is processed at machine startup and again at user logon.

    maybe a client restart, as the last step in the TS, might be enough to process & apply your GP?

    Don
    Monday, March 14, 2011 12:55 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We had the same problem.

    Even if the SCCM docs says it should update GPO:s on the first boot it doesn't always.

    As stated above MS has blocked GPUpdate therefore creating a lot of problems for many of their customers.

    If you do 802.1X you will have a major problem for example.

    The next best way to solve this (in my eyes) is to create a script that will enable the administrator account, copy a configscript localy and add a shortcut in autostart to the script. I prefer to use autostart over runonce since my configscript now can reboot if it needs to.

    The configscript will then have to do the GPUpdate/force and finish the configuration of the machine. It also will have to remove itself from autostart, dissable autologon and optionally dissable the admin account again

    The best soloution would naturally be for MS to fix this broken behaviour so that we could have a Gpupdate step in TS. I tried to report this but got the usual "Works as designed". Yes it works as designed, It is the desing that is flawed and I want it fixed.

    Monday, March 14, 2011 8:41 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Not to say this isn't a potential issue, but this isn't broken behavior. It's by design behavior because GPOs during a task sequence could/would wreak havoc on the TS. The broken behavior in this thread was the rogue policy as described by the thread's initator. In general, 802.1X is not very common and for Microsoft to code to a small minority case would not be very smart.

    If you have problems with this behavior though, I suggest you file a DCR. Beta of CM2012 is open and you can file a DCR there or if you "must" have this fixed in CM07, then you'll have to work with your TAm and justify your business and cost.

    John is watching this thread (he's the PM for OSD) and may have more to say also.

    Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
    Monday, March 14, 2011 1:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Your right it's not a broken behavior in MS perspective since they designed it that way. In a customeer perspective it is broken since it doesn't allow the functionality that is needed to be able to install the machines. But let's call it a design flaw since it's designed that way, it's the problem that is important not what we call it.

    The main problem as I see it is that you cant ensure that your machines does have the machine GPO then you need it. The number of threads about this problem seems to be rising. I used 802.1X a an example on there this causes a problem since I worked on such a case. Wireless configurations is another one there you can have the same thing if you wan't to do machine based auth. However the use of 802.1X seems to be rising and it was important enough for MS to even backport 802.1X support to PE. I think that is a clear indication on that it's getting bigger.

    The risk for GPO:s creating havoc is in my eyes small to very small. MDT does not blok GPO:s and MDT based installations works fine all over the globe. It's when you starts to use the premium product SCCM that you run into these problems. To further ensure a safe as possible fix I did suggested above that it should be made as at TS step. With that approach you can make a TS without that step and get the same behaviour as today, IE no risk at all. For us that needs GPUpdate we would have the possbility to add this step and since it is a TS step we can put it exactly there we need it.  Therefore we can run al steps that doesnt need GPO:s first in the current way and then read the GPO:s before the steps that needs them.

    To summon up, this change would give the follwing benefits:

    • No need for extra scripts that is run after SCCM
    • No exposure of username/PW:s. To use autorun or runonce you have to put a user and PW in cleartext in the registry
    • SCCM can now do the same thing as MDT already does.
    • By making it a TS step that you can include when you need it you remove the GPO havoc risk by simply not include it in your TS
    • All steps can be run from a TS. That gives logging and status reporting

    Johns words on this would be good.

     

    Tuesday, March 15, 2011 8:00 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    In terms of the timeout, "gpupdate.exe /force /wait:0" gets around that, in my experience.
    Tuesday, March 15, 2011 3:09 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yeah but this is still no good if know one physically logs in.. This a problem with our build team, for now we have them performing a GPupdate manually and rebooting the machine before going out. Kind of Cheezy!

    Tuesday, March 15, 2011 3:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    One dirty way to do an extra reboot is to do a shutdown -r -t120 as a final step in your TS. The TS will exit and the reboot wil run then the timer expires.

    Not a nice one but it has helped for at least one custom scenario

    Wednesday, March 16, 2011 7:15 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Ran into another example of this problem now.

    Target environment XPSP3.

    An this net uses 802.1X too.

    Now to the problem. XP does not fall back to MAB if X auth fails. XP will loose it's network connection.

    That means that we must have the certificate in place first. When thats is done the wired zero config service must be started and as a final step the configuration for X must be loaded.

    Since the config must be in place to get a network connection and the config cannot be loaded before the service is started it cant be done by GPO.

    If SCCM had been fixed as I sugested this one would have been easy.

    Does anyone have a suggestion how it can be done with todays SCCM soloution?

     

    Tuesday, March 22, 2011 7:40 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    And another one.

    This time it was a Direct access implementation. Same basic problem. The machines does not get theri machine certificates in time so no infrastructure tunnel for the machines meaning that users couldn't work but had to return the machines to IT.

    That also proves that it isn't a 802.1X only problem either

     

    Tuesday, March 29, 2011 7:16 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Try this:

    At the end of TS, create 2 steps:

    1. run command line script -> cmd /c "echo n | gpupdate /force" (this initiate updating of gps, but don`t reboot pc, TS will break because of unexpected reboot)

    2. run system restart to initiate restart for updating gps.

    Sunday, September 25, 2011 9:39 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    has anyone figured this out?
    Thursday, April 4, 2013 4:13 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Yes and no. 

    MS has not changed their broken design so it can't be done in native SCCM but I have deployed 25 maybe 30' boxes now using the method i described above. 


    One dirty way to do an extra reboot is to do a shutdown -r -t120 as a final step in your TS. The TS will exit and the reboot wil run then the timer expires.

    Not a nice one but it has helped for at least one custom scenario

    I have also posted a Blogpost att Johans site about how you can do 802.1X without the use of GPO:s to get the certificate down. 

    http://www.deploymentresearch.com/Research/tabid/62/EntryId/79/Using-802-1X-with-ConfigMgr-2007-2012-Contributed-by-Mats-Olsson.aspx

    • Proposed as answer by DJITS Monday, February 1, 2016 12:35 PM
    • Marked as answer by Garth JonesMVP Saturday, July 23, 2016 2:19 PM
    Thursday, April 11, 2013 7:41 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have experienced issues building machines in the past with GPO actually blocking the build completely, it gets to the Setup Windows and ConfigMgr phase then hangs on a black screen. This did not take long at all to realise that GPO was the cause and we moved the build machines to a clean OU as timelines were tight - effectively performing exactly what mats42 explains.. If you have an issue with GPO, remove it from the TS or move it further down the Task Sequence. Later on we made some adjustments and builds continued without an issue with GPO running at Setup Windows step.

    I would like to see the GPO feature available to the TS.

    Tuesday, September 17, 2013 12:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Mats,

    Problem was that my installation is Dutch instead of English so the script did not detect the certificate and failed. Now it is working.

    Thanx for the Script.

    Regards,

    DJITS


    • Edited by DJITS Monday, February 1, 2016 12:34 PM Problem Solved
    Monday, February 1, 2016 8:15 AM