none
Group policy breaking MDT build process RRS feed

  • Question

  • Good Afternoon,

    I wondered if someone could help me. If a Group Policy has been put in place to reset the local administrator password on all machines on our domain could this have a knock on effect on the deployment of new machines using WDS/MDT? We are finding that after the first reboot once the OS is installed during the build process instead of going straight into Windows with the local administrator account to complete all the task sequences it now stops at the login page and states that the login username or password is incorrect for  the .\Administrator account. I have read that its possible this can happen if a policy was introduced that would rename the local builtiin Administrator account but would a password change also have the same effect?

    Any advice/help would be much appreciated

    Kind regards

    Jonsey

    Wednesday, July 17, 2013 4:52 PM

All replies

  • Yes, a password change for the local administrator account would "break" MDT in the same way.

    You have a few options here. A lot of people have the device join the domain and apply itself to an OU that does not have the GPO applied, and then move the device to an OU with the GPOs after the fact. The other option, that I use in my environment, is to delay the domain join until after the first login, the process described here: http://blogs.msdn.com/b/alex_semi/archive/2009/08/28/avoiding-legan-notice-that-breaks-mdt-autologon.aspx .

    -Nick O.

    Wednesday, July 17, 2013 5:07 PM
  • Just to add the Policy that's been enabled that changes the built-in administrator password also includes an update which adds a new group we have created to the local built-in administrator group. Would this have any effect on our build process/task sequences?
    Wednesday, July 17, 2013 5:11 PM
  • If a group is added to the local administrators group per the GPO, that shouldn't matter in a deployment scenario. It shouldn't cause an issue.

    Changing the password or name of the local admin account certainly will cause issues during a deployment. 

    -Nick O.

    Wednesday, July 17, 2013 5:58 PM
  • Hi Trevor,

    In general it's a good idea when deploying computers in a domain, to either use one of the two options:

    1. Deploy the machine to a staging OU, which is excluded from GPO's. After the deployment is finished, move the computer object to the correct OU (can be automated within the task sequence as well).
    2. Do not join the computer to the domain right away, first let it complete the task sequence's regular tasks, and then use the "Recover from domain" task in the task sequence to join the machine to the domain at the very end of the task sequence.



    Kind regards,

    Stephan Schwarz.


    If one of these posts answered your question or issue, please click on "Mark as answer".

    My Blog | Twitter: @Schwarz_Stephan | MCTS, MCITP, MCSA, MCSE (Charter Member), MCC-2011.
    Automatically determine target OU from ComputerName with PS for MDT2012 U1/ConfigMgr
    How to configure Windows RE/OEM Recovery Partition with MDT 2012 Update 1

    Wednesday, July 17, 2013 7:05 PM
  • Thanks for your quick reply. This isn't really my area but do you know what would need to be changed to get this working again apart from removing the group policy?

    I was thinking perhaps the policy has made a section of the unattend.xml answerfile redundant. Maybe the password value under 'Autologon' or 'UserAccounts' settings in the OobeSystem component? Deployment of the image is almost complete its just at the phase of final login using the local built-in administrator account before it displays the completed deployment summary screen.

    Kind regards

    Jonsey

    Wednesday, July 17, 2013 9:48 PM
  • The built in Administrator is used by the MDT scripts, it has nothing to do with the unattend.xml. It actually happens when liettouch.wsf runs and pulls the admin name then, which is usually administrator.

    Like Stephen said, you could either:

    1. Create an OU that does not have these GPOs enforced, move the machine to this OU during domain join and redirecting it to the correct OU later in the task sequence
    2. Moving the domain join to the end of the task sequence
    3. Or you can try setting the registry key value "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName" to your new Admin name before the domain join reboot and GPOs kick in

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Thursday, July 18, 2013 12:23 PM
  • Can you not update your build sequence to use whatever the new admin password will be?
    Thursday, July 18, 2013 7:14 PM
  • I actually found a much easier and better method to deal with the problem of domain policies interfering with the final stages of MDT deployments. Basically, all we need to do is suppress the scripted reboot that happens right after MDT joins the domain. This allows for MDT to fly through the rest of the task sequence and perform software installs and any other tasks you've created after joining the domain without reboots, therefore, preventing any group policies from the domain to interfere since you haven't rebooted yet. Then, when the task sequence finishes, you can automatically reboot the machine by adding FinishAction=RESTART to your CustomSettings.ini.

    All you have to do is edit the ZTIDomainJoin.wsf script by "commenting out" the two lines that end with "true". Just type an apostrophe in front of each of the lines as illustrated below:

    oEnvironment.Item(“LTISuspend”) = “” 

         ‘oEnvironment.Item(“SMSTSRetryRequested”) = “true” 
         ‘oEnvironment.Item(“SMSTSRebootRequested”) = “true”

    iRetVal = SUCCESS

    This method is much cleaner because it does not require messing with Unattend.xml or altering the task sequence order or removing MDT's built-in method to join the domain or using any 3rd party vbs scripts to join the domain, or even changing your workflow since it is not necessary to put your computer accounts in some other OU in AD. It is also a more secure method since it does not require to hard code your passwords anywhere. 
    Friday, June 28, 2019 2:54 PM
  • A couple of issues with that.

    • If you modify MDT scripts and then a new version of MDT comes out, those edit will be overwritten when upgraded.
    • Also this workaround doesn't work for those that have tasks in their sequence that need a reboot or if the sequence is configured to have Windows update run and some patch needs a reboot.

    otherwise that could work for some


    Daniel Vega

    Friday, June 28, 2019 3:57 PM