none
Windows Update Interrupts MDT Task Sequence RRS feed

  • Question

  • Hi,

    I'm using MDT 2013 to roll-out a small Windows 7 image. The imaging process goes fine except for the post-install phase. There, Windows Update decides to install about a dozen or so updates and reboot the computer, during the part where the task is installing software, which really screws it up afterward. I am left with a dirty environment that needs about an hour or so, per machine to fix. The machines are being deployed into an OU that has a GPO configured to use a WSUS server. The GPO's settings are to not allow the immediate installation of updates, and to only install at 11:00 p.m. every night. Why are updates being installed during the task sequence. Those two steps are disabled in the sequence I am using. The image has no local GPO's set.

    Anyone seen this before?

    Thanks


    Jason

    Friday, May 8, 2015 6:28 PM

All replies

  • Usually for things like this, you need to rule out different parts of the process, since there's so many places where the issue could lie.

    For instance, why don't you try deploying to an OU that doesn't get any GPOs configuring Windows Update?  Then if you still have the issue, then you can definitely rule this piece out.  Or you could try running a batch script within the task sequence to turn off and disable the Windows Update service, at least temporarily.  Something like net stop wuauserv and then using the cmd sc config wuauserv start= disabled.  See if that helps!

    Friday, May 8, 2015 6:47 PM
  • If I had to guess, I'd say MDT is not the culprit here. When MDT initiates windows update it does it in Passes and if it requests a reboot because of a particular update, it will not cause a dirty environment because it's expecting the reboot.

    When a reboot is made by another process (Not MDT) then you'll see that dirty error. It might be one of your policies. A workaround could be joining your machine to the domain later in the sequence.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, May 8, 2015 7:34 PM
  • I have two steps in the task sequence that run a reg add command to turn off Windows updating, but it doesn't seem to do anything. I can guess that is because the registry changes might need a reboot to take effect. I'll try the net stop wuauserv command in place of the registry command.

    I also thought of deploying to an OU with block policy inheritance enabled so the GPOs don't apply.


    Jason

    Saturday, May 9, 2015 1:45 PM
  • Hi,

    How would you modify the task sequence to have it join the domain later without completely breaking the task sequence? Thanks


    Jason

    Saturday, May 9, 2015 1:46 PM
  • Look for "Recover from Domain" and move it further down in the sequence. Also look at the MDT help file for "Delaying Domain Join to Avoid Application of Group Policy Objects"

    If this post is helpful please vote it as Helpful or click Mark for answer.

    • Proposed as answer by Dan_Vega Monday, May 11, 2015 3:29 PM
    Saturday, May 9, 2015 3:59 PM
  • I tried moving the "Recover from domain" step until after the applications are installed. I'm leary about removing the domain join credentials from the Unattend.xml file. I don't see a place in the documentation where they are re-added.

    Jason

    Saturday, May 9, 2015 4:09 PM
  • From your customsettings.ini

    SkipDomainMembership=YES
    JoinDomain=domain.com
    DomainAdmin=Adminaccount
    DomainAdminDomain=DomainName
    DomainAdminPassword=Password
    
    Optional, you can specify the OU to add the computer to.
    MachineObjectOU=

    This is from the documentation:

    To join the target computer to the domain, the ZTIDomainJoin.wsf
    script uses the DomainAdmin, DomainAdminDomain, DomainAdminPassword, JoinDomain, and
    MachineObjectOU properties. You can declare these
    properties using the Windows Deployment Wizard, deployment share rules, the
    MDT DB, and Configuration Manager 2007 R3 computer and collection rules. The
    account used must have the rights required to create and delete computer objects
    in the domain.

    Typically, the ZTIConfigure.wsf script updates the Unattend.xml or
    Unattend.txt file with the values that these properties specify. These settings
    are then parsed by the Windows Setup program, and the system attempts to join to
    the domain early in the deployment process. Doing so subjects the target
    computer to settings specified in domain GPOs and can possibly cause the
    deployment process to fail.

    To intentionally delay joining the target computer to the domain
    during the deployment process, you can remove certain elements from the
    Unattend.xml file. The ZTIConfigure.wsf script will skip over writing properties
    to the Unattend.xml file if the associated property element is missing from the
    file.

    Prepare the unattend.xml file so the target computer does not attempt to join the domain during Windows Setup

    1.    Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench.
    2.    In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares/deployment_share/Task Sequences/task_sequence (where deployment_share is the name of the deployment share and task_sequence is the name of the task sequence to be configured).
    3.    In the Actions pane, click Properties.
    4.    On the OS Info tab, click Edit Unattend.xml.

    The Windows System Image Manager (Windows SIM) starts.

    1.    In the Answer File pane, go to 4 specialize/Identification/Credentials. Right-click Credentials, and then click Delete.
    2.    Click Yes.
    3.    Save the answer file, and then exit Windows SIM.
    4.    Click OK on the task sequence Properties dialog box.

    With the Credentials elements missing from the unattend.xml file, the ZTIConfigure.wsf script is not able to populate the domain join information in the Unattend.xml file, which will prevent Windows Setup from attempting to join the domain.

    To add a task sequence step that joins the target computer to the domain

    1.    Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench.
    2.    In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares/deployment_share/Task Sequences/task_sequence (where deployment_share is the name of the deployment share and task_sequence is the name of the task sequence to be configured).
    3.    In the Actions pane, click Properties.
    4.    On the Task Sequence tab, go to and expand the State Restore node.
    5.    Verify that the Recover From Domain task sequence step is present. If yes, proceed to step 9.
    6.    In the task sequence Properties dialog box, click Add, go to Settings, and click Recover From Domain.
    7.    Add the Recover From Domain task sequence step to the task sequence editor. Verify that the step is in the desired location in the task sequence.
    8.    Verify that the settings for the Recover From Domain task sequence step are configured to meet your needs.
    9.    Click OK on the task sequence Properties dialog box to save the task sequence.

    If this post is helpful please vote it as Helpful or click Mark for answer.


    • Proposed as answer by Dan_Vega Monday, May 11, 2015 3:29 PM
    • Edited by Dan_Vega Monday, May 11, 2015 3:31 PM
    Monday, May 11, 2015 3:28 PM
  • I tried adding steps in the task sequence to stop/disable the wuauserv service but it didn't happen. When I re-ran the task today, Windows Update broke the sequence with an unstoppable update.

    Jason

    Monday, May 11, 2015 3:34 PM
  • I moved the recover domain step down as far as it would go (just before the imaging step at the end). It didn't make a difference. I think the source image has Windows updates set to auto download and install, and it does this right after the image is deployed.

    Jason

    Monday, May 11, 2015 3:36 PM
  • I am not allowed to place an administrative account's login credentials in a plain-text file. That is probably a bad idea overall. I am not allowed to do that for any account in our domain. I'll give your suggested steps a try.

    Many thanks!


    Jason

    Monday, May 11, 2015 3:39 PM
  • Sysprep will set Windows update in an unconfigured state, so even if your image had updating configured it would be off when deployed.

    Did you removed the credentials element from the unattend file to keep it from joining early on?


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, May 11, 2015 3:43 PM
  • It doesn't have to be a true "Admin" account, really just an account that has the rights to add machines to the domain. Also set the permissions on your deployment share so that it's only accessible by the account(s) you use to deploy with.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, May 11, 2015 3:47 PM
  • I'll try the automation with a standard user account. We have the computers in all different OUs, so there is no way to really automate that, though a drop-down list of pre-entered OUs would be cool. I'll try the steps with regard to removing the domain join step when I re-run the task sequence tomorrow. Thanks for the great suggestions!

    Jason

    Monday, May 11, 2015 6:58 PM
  • A drop down would be cool. This will get you a drop down

    SkipDomainMembership=NO
    MachineObjectOU=OU=Blah,OU=Blah,DC=Blah
    DomainOUs1=OU=Blah,OU=Blah,DC=Blah
    DomainOUs2=OU=Blah,OU=Blah,DC=Blah

    By specifying the MachineObjectOU, you'll have a "default" OU selected but you can choose another from the dropdown list.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    • Proposed as answer by Dan_Vega Tuesday, May 12, 2015 1:22 PM
    Monday, May 11, 2015 7:04 PM
  • You could set ProtectYourPC to 3. See this for further Info (https://technet.microsoft.com/en-us/library/cc749278.aspx).

    Monday, May 11, 2015 7:25 PM
  • That is awesome! Thanks! I am certainly going to give that a try.

    Jason

    Monday, May 11, 2015 7:38 PM
  • The drop-down worked like a charm. Thanks!

    Jason

    Tuesday, May 12, 2015 12:51 PM
  • I modified the GPO setting "Delay restart for scheduled installations" to its maximum value of thirty seconds. Removing the username and password from the unattend file, and moving the recover from the domain step as far down as I can didn't stop it from joining the domain and throwing an update prompt. The thirty minutes gave the applications time to finish installing before the reboot was required. The applications take so long to install because of SEP.

    Jason

    Wednesday, May 13, 2015 6:00 PM