none
Administrator autologon fails in some cases Win 7 MDT 2012

    Question

  • Ok, so now I have tried "everything". My Windows 7 deployment process is almost perfect, but I still have one small obstacle to overcome before I'm content.

    The problem is this:

    When I deploy Windows 7 through MDT/WDS to a new "unknown" PC; one that never has been joined to the domain, the first admin login always fails. However, when I redeploy a machine that has been joined to the domain before, the login works. I should add that this is true even though I delete the computer account from AD and (of course) repartition and format the disks. If I, on the other hand, prestage the computer account in AD the login still fails when it's a brand new PC.

    In our domain we have a GPO that changes the name of the local admin account, and my first thoughts were that this policy isn't always applied in time for the first login occurance. This seems to be true when it comes to new PCs; the admin account is sometimes still called "Administrator". But it is not true when it comes to a computer that has been part of the domain before, again EVEN THOUGH I delete the account from Active Directory. In my unattend.xml file I tell the deployment process to use the new administrator name and the correct password as set by the GPO. Is there anyway I can force this account name and password to be set earlier in the process to ensure that the login is successful? I tried the ApplyGPOPack string in customsettings.ini, but that GPO is applied too late (after login) to be useful. Can I apply the GPOs earlier? What am I missing here?

    Cheers for your help!

    /JSWB 

    Friday, March 22, 2013 9:09 PM

Answers

  • This is a very common problem. There are no shortage of solutions.

    1. delay domain join until the very end.

    2. have the PC's join an OU with the loopback policy that blocks the rename of the admin account, then move the account at the end.

    3 apply group policy filtering to deny the GPO if it detects te MININT folder or _SMSTasksequence folder.

    There are other suggestions, you have to Google them.


    Blog: http://scriptimus.wordpress.com

    • Marked as answer by JoSvWiBr Monday, March 25, 2013 12:38 PM
    Friday, March 22, 2013 10:20 PM

All replies

  • This is a very common problem. There are no shortage of solutions.

    1. delay domain join until the very end.

    2. have the PC's join an OU with the loopback policy that blocks the rename of the admin account, then move the account at the end.

    3 apply group policy filtering to deny the GPO if it detects te MININT folder or _SMSTasksequence folder.

    There are other suggestions, you have to Google them.


    Blog: http://scriptimus.wordpress.com

    • Marked as answer by JoSvWiBr Monday, March 25, 2013 12:38 PM
    Friday, March 22, 2013 10:20 PM
  • You're the man, Andrew! Not the first time your solutions have helped me get past obstacles. Big kudos to you!

    By the way, I tried the 3rd solution with filtering the GPO and it worked like charm. Simple but genius. 

    What I can't understand though, is why does it differ between computers joined for the very first time vs. computers rejoining with the same name but a new computer object (deleted the old one)? Is there a policy "cache" which enables the policy faster if AD "recognizes" the object?

    Cheers!

    /JSWB 

    Monday, March 25, 2013 12:45 PM
  • Jo, deploy Logonexpert autologon tool with pre-configured .ini file with new Windowses it will logon it in any cases.
    Tuesday, April 23, 2013 8:25 PM