locked
Deploying two different captured images : on one deployment the local administrator is disabled and tasksequence cannot continue RRS feed

  • Question

  • Hi,

    I used MDT 2013 to create a sysprep & capture tasksequence. I'm using this TS to sysprep & capture some disks (W7). These disks were delivered to me and belong to different clients. Now I sysprepped and captured the first disk with no errors at all. I deployed it using a new - default - tasksequence and everything worked well. Next I took the second disk and captured this as well using exactly the same TS. Again no errors in the Final Summary. I created a brand new second task sequence, again just the default TS, to deploy this image. So I deploy this image and everything seems alright, creating partitions and installing the image etc, until at some point when the pc boots: it gets "stuck" at the logon-screen. When I try to login with the local administrator I get the message that the user is disabled. What is happening here? Why does this administrator got disabled on the second disk and not on the other??? I didn't change the task sequence, I didn't change the autounattend, on both pc's I used the local administrator to launch the capture which ended with no errors. I searched Google and this forum but couldn't find an explication. I recaptured the disk and recreated the deploying TS and even tried to deploy to another pc but without success. For info : I'm not joining any domain, I'm deploying into a workgroup.

    I'm still looking for a solution. The unattend.xml does have these settings by default:

    amd-64_Microsoft-Windows-Deployment_Neutral RunSynchronous RunSynchronousCommoand[Order="1"] cmd /c net user Administrator /active:yes"

    Under the OOBE AutoLogon
    Enabled true
    Logoncount 999
    Username Administrator 
    And I do have the impression that this really works, at least on one captured image...
    • Edited by KZen Muug Monday, February 2, 2015 11:48 AM
    Friday, January 30, 2015 1:34 PM

Answers

  • Found it.

    In the end it was the HDD that was delivered to me that contained the error, if you can call it an error. The "Remaining Windows Rearm Count" on it was ZERO ! Therefore the sysprep couldn't run and that's why SystemSetupInProgress (see LTIsysprep.log) remained zero too. So I added SkipReArm=1 to the unattend.xml (in the captureshare) and reran the sysprep and for sure the SystemSetupInProgress parameter equalled 1! I deployed the thus obtained image and yes indeed all went well this time: the pc did reboot and did logon and continued and finalized the deployment like it should.

    Paul

    • Marked as answer by KZen Muug Tuesday, February 3, 2015 1:31 PM
    Tuesday, February 3, 2015 1:31 PM

All replies

  • Added a new LocalAccount in the OOBE phase, put it in the Administrators Group, gave it a password, redid the deployment. (see : http://community.spiceworks.com/topic/161643-win7-unattended-enable-local-administrator). The result is the same : the local administrator was disabled. Moreover, when I logged on in safe mode I could see that the new administrator-user I configured in the unattend.xml had never been created !

    I've compared two BDD.logs files : one BDD.log contains the full log, because the deployment was OK, the other bdd.log stops at a certain point, because the local admin can't log in and continue. These are the last lines in the failed deployment bdd.log

    Event 41001 sent: ZTIWinRE processing completed successfully.	ZTIWinRE	02/02/2015 08:32:17	0 (0x0000)
    Property PHASE is now = STATERESTORE	ZTINextPhase	02/02/2015 08:32:17	0 (0x0000)
    ZTINextPhase COMPLETED.  Return Value = 0	ZTINextPhase	02/02/2015 08:32:17	0 (0x0000)
    ZTINextPhase processing completed successfully.	ZTINextPhase	02/02/2015 08:32:17	0 (0x0000)
    Event 41001 sent: ZTINextPhase processing completed successfully.	ZTINextPhase	02/02/2015 08:32:17	0 (0x0000)

    The other BDD.log contains more information, because it just continues after the reboot.
    • Edited by KZen Muug Monday, February 2, 2015 2:10 PM
    Monday, February 2, 2015 11:52 AM
  • Can you check if an GPO Package is applied, if so disable the "Apply Local GPO Package" step, or add the following property to your customsettings.ini: ApplyGPOPack=NO

    Perhaps this causes your machine to receive an initial GPO configuration that disables the account.

    To get around the problem you may want to do the following, add a Run Command Line in the State Restore section of your Task Sequence, preferably at the end that executes the following command: cmd /c net user administrator /active:yes

    And see this article for reference, on how to enable or disable the account in unattended.xml

    Cheers! Rens


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Monday, February 2, 2015 3:12 PM
  • I'm comparing the BDD.logs which were generated during the capture process. The pc whose image I can deploy faultless, has SystemSetupInProgress set to 1, but the other pc with the faulty deployment has SystemSetupInProgress set to 0. According to https://technet.microsoft.com/en-us/library/cc754137%28v=ws.10%29.aspx this parameter should be set to 1 if the sysprep went OK. So now I can conclude that something went wrong with the sysprep. Just need to find out what.
    Monday, February 2, 2015 3:14 PM
  • Can you check if an GPO Package is applied, if so disable the "Apply Local GPO Package" step, or add the following property to your customsettings.ini: ApplyGPOPack=NO

    Perhaps this causes your machine to receive an initial GPO configuration that disables the account.

    Are you talking about a GPO Package that should pehaps be applied at the end of the deployment? If yes, well, both deployments are running in the same environment, so according to that theory they should receive the same GPO Package.

    About editing the unattended.xml, been there done that, it didn't help. I did not try the extra task for the task sequence.

    But as you probably saw, I've added some extra info I found in the bdd logfiles that were created during the capture process.


    • Edited by KZen Muug Monday, February 2, 2015 3:19 PM
    Monday, February 2, 2015 3:18 PM
  • Check your deploymentshare\templates folder if GPO packages exist, if so this could be your problem.

    Up till MDT 2012update1 GPO templates for Windows 7 are supplied with the installation of Windows 7. If you have migrated MDT to 2013, it means they are still there, easily forgotten and overlooked at. And by default GPO packs will be applied.

    Cheers! Rens


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Monday, February 2, 2015 3:23 PM
  • If you have migrated MDT to 2013,

    No, we've installed MDT 2013, we didn't do an upgrade. The Templates folder therefore is empty.

    Could it be because the "faulty" pc has a french os ? My MDT only has an english Windows 7 in the "Operating Systems" section.

    • Edited by KZen Muug Monday, February 2, 2015 3:30 PM
    Monday, February 2, 2015 3:28 PM
  • So now you know that's it's not a GPO template that's messing with your deployment. Two things remaing, your task sequence or your unattended.xml

    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Monday, February 2, 2015 3:43 PM
  • So now you know that's it's not a GPO template that's messing with your deployment. Two things remaing, your task sequence or your unattended.xml

    I do not agree, for the moment. Because both TS and unattend.xml are completely default. And capture and deployment function perfectly as they should,  like activating the local administrator and renaming the newly deployed image. I've tried it several times and it just works.

    But now I've been given an HDD with a French OS on it and though the capture seems to have succeeded with zero errors, I've got problems when deploying its image : the local admin is desactivated, login is not possible and thus the last steps in the TS cannot be run, like renaming the pc.

    Personally I'm thinking something goes wrong in the generalize-step of the sysprep-process.

    Monday, February 2, 2015 3:51 PM
  • Found it.

    In the end it was the HDD that was delivered to me that contained the error, if you can call it an error. The "Remaining Windows Rearm Count" on it was ZERO ! Therefore the sysprep couldn't run and that's why SystemSetupInProgress (see LTIsysprep.log) remained zero too. So I added SkipReArm=1 to the unattend.xml (in the captureshare) and reran the sysprep and for sure the SystemSetupInProgress parameter equalled 1! I deployed the thus obtained image and yes indeed all went well this time: the pc did reboot and did logon and continued and finalized the deployment like it should.

    Paul

    • Marked as answer by KZen Muug Tuesday, February 3, 2015 1:31 PM
    Tuesday, February 3, 2015 1:31 PM