MDT installs are failing for windows platforms hanging at "Login" screen during install process.

After the last root password change on 2014-07-11 from Bug 1036980 windows re-images may have failed due to a race condition. This is due to the fact that MDT OS creation steps rely on a hard coded password to auto login as administrator for application installation and configuration finalization. Since the new passwords from Bug 1036980 were being reset via GPO they are set when ever a gpupdate is run. A gpupdate step was added to the MDT process in prep for puppet use. This step caused the auto login to be set to the password but not changed on the local system. This should not have been the case as there was a safe guard setup in the "Auto_login" GPO via item level targeting to look for a registry entry on the path of HLKM\Software\Mozilla\GPOStartkey with a value of start. This key gets set in MDT at the END of the MDT process to let GPO do updates. When the new passwords were pushed the item level targeting on the "auto_login" gpo was cleared which allowed this condition to occur. The item level targeting was restored and installs that were previously hanging started working.

Does this mean that all reimages since July 11'th need to be rekicked? or does this mean that all reimages since July 11'th were broken and are now fine? or is this something else? I'm trying to evaluate a set of next steps here.

If a re-image was done and it did not start taking jobs during this time period it should be re-imaged via the touch-less method. Q

Added clean install step to deal with potential "dirty environment" error the Scripts\ZTICleanSetupInprogress.vbs script will now be automatically built into and mdt PE environment on update.

Currently there still seems to be some oddness with the auto login. The production task sequence has had the forced group policy update removed, and the administrator account is being renamed, but the password does not change. This is not happening on every machine, but i would estimate from what I have seem today is around 20%. This is not a blocker but it does slow down the new roll out.

I tried re-imaging these slaves today, but it didn't help any of them (still burned lots of jobs): t-w864-ix-0[04,33,51,76,77]

The above were affected by graphics driver issues that are corrected now all machines are verified and back in.