locked
OOBE Autologon does sometimes not work RRS feed

  • Question

  • when we add the server to the domain, the GPO kicks in and instantly the administrator account is renamed.
    this causes problems with the autologon option in phase 7 OOBE, so in phase 4, I create a new local user and then add that user to the administrators group

    net user /add autologon "password"  
    net localgroup administrators autologon /add

    so far so good - this always works fine.

    in phase 7 OOBE System, I configure the autologon account.
    (at the end of the build process, this account is deleted)

    my problem is, somehow, some people end up that the server build just ends at the login screen, and it does not seem to log in automatically. I have never encountered it myself during my tests, but a very experienced member of the server team has experienced it - but it is inconsistent - I would say 9 out of 10 times, the autologon works OK, only occasionally, it does not automatically log in.... and when they manually log in with the autologon credentials, the imaging automatically continues.
    and this seems to occur during our windows 2012 R2 and 2016 server builds (nearly the same build process)

    has someone ever encountered something like this ? or suggestions how to figure out where I might find an answer/reason why it did not automatically log on ?

    Friday, June 28, 2019 8:39 AM

All replies

  • I saw this, well, something similar on my server in the past. We use LanDesk and there is a job that runs which renames the local admin password. Since that p/w is embedded everywhere in the MDT server, things failed with bad passwords.

    Is there a job that renames the accounts? If so, can you omit computers by name from getting hit with that job?
    Eventually, I ended up removing LanDesk completely so there was no change of it happening again.

    Friday, June 28, 2019 12:48 PM
  • Yes, a couple MDT versions ago there was a bug that would lead to autologon info getting lost after the first reboot during State Restore. So I just wrote a script that would add it back at the very beginning of State Restore and that fixed that.

    Daniel Vega

    Friday, June 28, 2019 1:49 PM
  • I am at ADK 1809 and MDT 8456 so those are the latest versions (well ADK 1903 is out)

    the real annoying thing is, it is a not consistent- most of the times it works OK...
    and like stated, the administrator account is renamed, so because of that, I create the local user, and log in as that local user, which is not renamed. (we can always log on with the credentials)

    but I must say, what Daniel Vega is stating, seems to come most close to what we experience.

    do you have more details - i.e. how did you find out - where can I see if that might be the case ??
    (and can you share that script - that may also point me in the right direction ?)

    Friday, June 28, 2019 3:42 PM
  • I used a simple powershell script saved in the Scripts folder

    $RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
    $AdminPass = 'PASSWORDHERE'
    Set-ItemProperty $RegPath "AutoAdminLogon" -Value "1" -type String
    Set-ItemProperty $RegPath "AutoLogonCount" -Value "999" -type String
    Set-ItemProperty $RegPath "DefaultPassword" -Value $AdminPass -type String
    Set-ItemProperty $RegPath "DefaultUsername" -Value "Administrator" -type String
    Set-ItemProperty $RegPath "DefaultDomainName" -Value "." -type String
    Replace any of the values you need to such as the username


    Daniel Vega


    • Edited by Dan_Vega Friday, June 28, 2019 4:09 PM
    Friday, June 28, 2019 4:08 PM