none
MDT 2013 8443 Autologon issue RRS feed

  • Question

  • Just recently I noticed on my Dell Latitude E5470's, that I will PXE boot UEFI, choose my TS, it starts the deployment, lays down the OS, reboots, when it comes up to the login screen (Windows 10 v1607), it does not autologon.  

    I have left it run over night.

    I have verified, updated and changed the password in the unattend.xml

    I have ran the same TS on another Dell PC (Optiplex 760) and it executes 100% without fail.

    I have created a brand new TS from scratch.

    I have 2 different versions of Windows 10 WIM files, older and just recently updated and neither of them work.

    If I simply put in the local administrator password that was specified during the creation of the TS, I get to login and the TS automatically starts and continues to finish the entire TS.

    Here is a link to the log files:  https://www.dropbox.com/sh/22qroj27vcphqqc/AAB0Hkfu5vZMCw-fYt-IXDDua?dl=0

    Thank you.

    Wednesday, February 15, 2017 12:32 AM

Answers

  • Well, my thinking is to eliminate any possible issue. Delaying the domain join takes that out of the picture. I agree that is should not cause an issue but, say someone is running a script to change the local admin password as a GPO. At this point in troubleshooting it might be a good idea to eliminate all that could cause the issue. at some point you will have the answer: This is me paraphrasing Sherlock Homes....

    I delay the domain join since I have a Legal Message at login

    See below

    https://deploymentpros.wordpress.com/2015/07/20/moving-mdt-domain-join-to-the-end-of-the-task-sequence/

     
    • Marked as answer by Jdubbs2 Friday, March 10, 2017 11:13 PM
    Wednesday, February 15, 2017 5:15 PM

All replies

  • Did you configure the Autologin user ID / Password under 7 OOBE System in the unattend.xml? Also did you leave it unencrypted?

    Wednesday, February 15, 2017 12:34 PM
  • Is that computer being placed in another OU with GPO's that block the local admin account? I want to make sure we are comparing apples to apples here.
    Wednesday, February 15, 2017 1:59 PM
  • Yes, the Autologin user ID and Password have been set in the unattend.xml.  It is encypted as this was set in the creation of the task sequence.  The computer is being placed in a dedicated OU but there are no GPO's that block the local admin account.  When I run the same TS on any other machine, it runs 100% without fail and any manual intervention. 

    Thank you guys.

    Wednesday, February 15, 2017 3:43 PM
  • OK I am doing this from memory (never a good thing) and it might have been fixed by now, but is there not an issue with encrypting the passwords in the unattend.xml?

    Again, that is from memory. Not sure if that would be a difficult thing to test....

    Wednesday, February 15, 2017 3:49 PM
  • I have edited the unattend.xml to reflect <PlainText>true</PlainText> and typed in the password in plain text.  Ran the TS and get the same result.
    Wednesday, February 15, 2017 4:42 PM
  • Does your unattend.xml look like this?

    <AutoLogon>

                    <Enabled>true</Enabled>
                    <Username>Administrator</Username>
                    <Domain>.</Domain>
                    <Password>
                        <Value>egBhAHEAMQBwAGwAbQAhAFAAYQBzAHMAdwBvAHIAZAA=</Value>
                        <PlainText>false</PlainText>
                    </Password>
                    <LogonCount>999</LogonCount>
                </AutoLogon>

    Wednesday, February 15, 2017 4:51 PM
  • Are you joining the domain before the machine boots for the first time? Also, does the registry reflect that the auto login is set?

    I am wondering if delaying the domain join might help...

    Wednesday, February 15, 2017 4:52 PM
  • Here is mine

    <AutoLogon>
     <Enabled>true</Enabled>
     <Username>########</Username>
     <Domain>.</Domain>
     <Password>
      <Value>##########</Value>
      <PlainText>true</PlainText>
     </Password>
     <LogonCount>999</LogonCount>
    </AutoLogon>

    I am using plain text for my admin password in the unattend.xml.

    Wednesday, February 15, 2017 4:56 PM
  • What is error message you get? Wrong password? Does it fail altogether? It lays the OS down and then upon first start of windows what message comes up?
    Wednesday, February 15, 2017 4:59 PM
  • The machine is joined to the domain by this time and the registry does in fact have the auto login set with 998.  I do not understand how delaying joining the domain could help but I am willing to try.  How can this be accomplished?  Also, keep in mind this TS works on any other Dell model I have, so joining domain, usernames, passwords are all working fine if we use a different model PC.

    Thanks!

    Wednesday, February 15, 2017 5:04 PM
  • I have tried both with PlainText and without.  


                <AutoLogon>
                    <Enabled>true</Enabled>
                    <Username>###########</Username>
                    <Domain>.</Domain>
                    <Password>
                        <Value>##########################</Value>
                        <PlainText>false</PlainText>
                    </Password>
                    <LogonCount>999</LogonCount>
                </AutoLogon>


    Thanks.

    Wednesday, February 15, 2017 5:09 PM
  • Well, my thinking is to eliminate any possible issue. Delaying the domain join takes that out of the picture. I agree that is should not cause an issue but, say someone is running a script to change the local admin password as a GPO. At this point in troubleshooting it might be a good idea to eliminate all that could cause the issue. at some point you will have the answer: This is me paraphrasing Sherlock Homes....

    I delay the domain join since I have a Legal Message at login

    See below

    https://deploymentpros.wordpress.com/2015/07/20/moving-mdt-domain-join-to-the-end-of-the-task-sequence/

     
    • Marked as answer by Jdubbs2 Friday, March 10, 2017 11:13 PM
    Wednesday, February 15, 2017 5:15 PM
  • It lays down the OS and upon first boot of Windows it gets to the login screen and every so often the screen blinks as if it's trying to login.  There is no error message on the screen.  It will sit like this overnight with no change.  Now if I manually type in the credentials to login to the computer and using the same credentials that is stored in the unattend.xml, it will login.  Then, moments later the TS continues without error.

    Here is the link to my logs when it arrives at the login page. notice the two spaces and correct accordingly. https://www. dropbox.com /sh/22qroj27vcphqqc/AAB0Hkfu5vZMCw-fYt-IXDDua?dl=0

    Wednesday, February 15, 2017 7:14 PM
  • Is the WIM file the same for all your machines?
    Wednesday, February 15, 2017 7:15 PM
  • Yes, same WIM file.  WIM file was deployed by MDT with a set of source files for Windows 10 x64 v1607 Enterprise to a Hyper-V VM, then syspreped and captured.
    Wednesday, February 15, 2017 9:10 PM
  • Maybe try updating the BIOS and try the deployment again, or maybe try using diskpart to delete all partition and clean the drive and try your deployment again.
    Wednesday, February 15, 2017 9:16 PM
  • Ok, so after further investigation I found that the issue started happening to all machines, all machines except Hyper-V VM.  I have gone and created an entirely new deployment share.  Created a new task sequence with the same WIM file, added drivers to the share and added driver injection with: Windows 10 x64\Dell Inc.\%Model%.  I am still having the same issue.  

    Then I changed the WIM to an older WIM file previously used in our environment and the issue remains.  Not sure what to try next.

    side note, I also tried "Why do I torture myself like this" idea of moving the join to domain option towards the end of the task sequence.

    Tuesday, February 21, 2017 6:20 AM
  • When you created your new share did you bring anything over from the old? In a case like yours I would start fresh with nothing from the old. I would also start with a basic build, the base WIM from the Microsoft Win 10 ISO., install no apps and even eliminate the domain join. Make the Task Sequence as simple as possible. See if the most simple build is causing an issue.

    My idea is ALOT of work. Not sure how else to troubleshoot this...

    If that works, start adding in things to see when the TS fails....

    But wow, what a problem. That has to be annoying.

    Tuesday, February 21, 2017 9:59 AM
  • Did you by any chance copy the task sequence from the old share to the new share, or configure it from scratch? One the new task sequence, did you manually change the unattend.xml file at all, same with your capture sequence, was the unattend.xml file modified by you manually at all?

    Did you try my suggestions as well that I posted earlier? Deleting the partition and running a clean on the disk using diskpart? I'm seeing a lot of Dirty Environment errors in your logs.

    Tuesday, February 21, 2017 2:06 PM
  • Sorry, I'm late to the discussion.

    Please be aware that unattend.xml files do *NOT* store passwords as encrypted. They are instead encoded, and recoverable.

    Therefore we do NOT recommend putting the password in the unattend.xml file directly, instead just enter at deploy time with the wizards, that ensures that the password only remains local and is removed at the end of setup.

    JDubbs2 - please contact me offline if you have any questions. kg at KeithGa dot com


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, February 23, 2017 11:44 PM
    Moderator
  • I have the same issue with different Dell Models though.

    Please tell me you figured this out?

    Works on older Latitude Models like E6530, E6440, but does not work on New E7470 or Precision 3510.

    So I created a new TS and started my testing like this:

    • Reference image, no app installs, no windows updates, no domain join, installed all drivers, didn't edit TS for total control- Imaged fine.
    • Reference image, no app installs, no windows updates, domain join, installed all drivers, didn't edit TS for total control- Imaged fine.
    • Reference image, no app installs, windows updates, domain join, installed all drivers, didn't edit TS for total control- Imaged fine.
    • Reference image, app installs, windows updates, domain join, installed all drivers, didn't edit TS for total control- Imaged fine.
    • Reference image, app installs, windows updates, domain join, installed only dell model precision 3510 drivers, Edit TS for total control- Image did not auto log on, had to log in once as local administrator and it finished.

    Something within the drivers is changing something about autologon.

    Monday, February 27, 2017 4:03 PM
  • Theitguy69: What version driver CAB are you using for your E7470, I see the newest available is A05 (02/14/2017). These look newly updated within two weeks, are you using this CAB or a older one?
    Monday, February 27, 2017 8:03 PM
  • So I found something interesting today. I removed this driver from the Dell Precision 3510 driver folder in MDT ,

    GKUPRO2D.inf which is the Dell Smart Card Reader

    Ran my Test Task Sequence since the last failure test  and it Auto logged on and finished the deployment without issue.

    At least for the precision model. Also tested on the Latitude and it worked.

    It seems there is something going on with the Smart Card log on with Windows 10 and MDT during the TS that is causing it not to Auto logon.

    We do nothing specifically with the local admin account or Smart Card reader via GPO.

    Tuesday, February 28, 2017 5:03 PM
  • I am using the latest CAB that you reference.
    Tuesday, February 28, 2017 5:04 PM
  • I am also looking into disabling this group policy.

    petri.com/use-group-policy-to-stop-linking-microsoft-accounts-to-local-domain-logins

    It is possible that after Domain join, if your domain has the latest group policies imported for Windows 10 1607, that it looks for this policy and tries to log in with that account.

    The only reason I am looking into this is because I noticed that when my Task Sequences would fail to auto logon the user would say Administrator but in the password field it would say input email address or phone number. and I would have to click on another user option to type in Administrator and the password to keep the Task sequence running. My 1st test of setting this policy disable on the local GPO in the reference imaged work.

    Will report back tomorrow when I have more time.

    Tuesday, February 28, 2017 10:08 PM
  • So It seems I have resolved my issue.

    Our environment is the following:

    AD Level 2008

    MDT 8443 on Windows Server 2012 R2

    Windows 10 1607 Ent. .iso (with Nov. update) from Microsoft VLCS

    I had imported the Windows 10 1607 Group Policy Templates but the below referenced GPO was undefined.

    petri.com/use-group-policy-to-stop-linking-microsoft-accounts-to-local-domain-logins

    I manually set this GPO locally when creating a new ref image , I added back the Smart Card driver, and imported the ref image into our production mdt and tested from my original Production Task sequence and now it Auto logs on through out the whole image without fail.

    I am assuming that during the TS when the computer gets joined to the Domain and in our instance automatically is put in a specifically defined OU that has GPO's configured for it, it somehow wants the Windows 10 OS to log in like its the 1st time you are booting and asking you if you want to log in with your Microsoft account since that GPO was not defined. Once I defined it, it never asks to do that again.

    Or I am doing something wrong during my Syspreping.

    • Proposed as answer by Theitguy69 Wednesday, March 1, 2017 3:46 PM
    Wednesday, March 1, 2017 3:46 PM
  • I had the same issue, logging into Windows after domain join and being prompted for an email address. I found it to be Windows trying to login into your Microsoft account

    I added the to my unattend.xml (Stops access to MS Acct)

    cmd /c reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v NoConnectedUser/t REG_DWORD /d 00000003 /f  

    Last step in TS is to give back access (if needed)

    cmd /c reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v NoConnectedUser/t REG_DWORD /d 00000000 /f 

    Wednesday, March 1, 2017 4:08 PM
  • Thanks for the input guys.  I just created a new image with disabling the Microsoft Account option.  Setup the TS and get the same results.  I can in fact see that the microsoft account option is not enabled as it solely prompts for a UN/PW and not email address, but the auto logon issue remains

    The only way I have been able to get the auto logon process to work is removing total control in the TS as well as removing all drivers from being injected during deployment.  At this time it is successful with auto logon but is missing the drivers obviously.  If I have total control in place but no drivers in the folder, I still have the issue.

    Very frustrating.

    Wednesday, March 1, 2017 11:09 PM
  • I'd say try running your deployment joined to a workgroup instead of the domain, but it sounds like it could be a driver issue.

    I disable automatic driver updating so that it doesn't interfere during deployment, then enable it again at the end. See my comments on this thread - https://social.technet.microsoft.com/Forums/en-US/d5fb8d40-9667-49ef-8607-0fe2499f89a4/microsoft-automatic-intel-driver-updates-messing-up-our-windows-10-hp-systems-during-and-post?forum=mdt


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, March 2, 2017 6:02 PM
  • It has to be a driver issue.  This TS works 100% on other models.  I already have that disable automatic driver updating incorporated into my TS:

    I can try without joining to the domain but other models are joining the domain with the same ts just fine.

    Thank you all for the input and suggestions so far. :)

    Thursday, March 2, 2017 6:26 PM
  • Have you tried removing the driver mentioned earlier?

    GKUPRO2D.inf which is the Dell Smart Card Reader

    Thursday, March 2, 2017 6:28 PM
  • I have not tried to remove just that driver.  I have tried leaving total control in place and it's pointing to the Latitude E5470 folder, and deleted all drivers (didn't work) and even only adding network and storage drivers thus eliminating all other drivers and that didn't work either.
    Thursday, March 2, 2017 6:49 PM
  • Why do I torture myself like this, I was able to push the domain join process to the end of all my custom tasks and it seems to be working now.  Not sure what the source of the issue is, but at least this is a workaround!

    Thanks!

    Friday, March 10, 2017 11:15 PM
  • Why do I torture myself like this, I was able to push the domain join process to the end of all my custom tasks and it seems to be working now.  Not sure what the source of the issue is, but at least this is a workaround!

    Thanks!

    Probably a domain group policy that was screwing it up.
    Monday, March 13, 2017 12:51 PM
  • I am having a similar issue with some GPO with auto-logon. The admin account can auto-logon to one OU which is policy-free. We are doing that now. However, I want to enable Bitlockler during MDT which requires the pc to auto-logon to a different OU for that to happen. If the pc is placed in the Bitlocker OU before starting LTI, the admin will not auto-logon....it requires manual entry of the admin name and p/w.

    Are you aware of what GPO prevents/allows the admin to auto-logon to one OU and not another? My AD group just informs me that it works now because there is no GPO blocking it...but they won't look into why it's blocked from another OU. If I know what that GPO is, I can have them change it to allow auto-logon for administrator and then have Bitlocker run via LTI.

    Thanks

    Friday, November 17, 2017 3:24 PM
  • We face the same issue : 

    • GPO on Site Computers OUs with vbs script that change the local administrator default password (multiple sites, different passwords)
    • MDT that put the Computer into the corresponding selected Computers Site OU

    > During the MDT process after the Postinstall sequence, the computer is joined to the AD domain, the GPO is applied and the computer autologon is broken due to difference between passwords

    We solve this by editing our vbs script password changing password by adding a OS install date-time detection, if the OS is installed by less than 60minutes for exemple, we don't change the password.

    With something like that..

    On Error Resume Next
    
    Set objArgs = WScript.Arguments
    If WScript.Arguments.Count = 0 then WScript.Quit(1)
    
    For Each strArg in objArgs
        NewPass = strArg
    Next 
    
    Set objNetwork = CreateObject("WScript.Network")
    strComputer = objNetwork.ComputerName
    
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
    
    '------------------------------------------------------------------------
    'Getting OS Install Date/Time
    Set colItems = objWMIService.ExecQuery ("Select * from Win32_OperatingSystem")
    For Each objItem in colItems
    	InstallFDate = objItem.InstallDate
    	InstallYear = Left(InstallFDate,4)
    	InstallMonth= Mid(InstallFDate,5,2)
    	InstallDay  = Mid(InstallFDate,7,2)
    	InstallHour = Mid(InstallFDate,9,2)
    	InstallMin  = Mid(InstallFDate,11,2)
    	InstallSec	= Mid(InstallFDate,13,2)
    	InstallDate = InstallDay & "/" & InstallMonth & "/" & InstallYear
    	InstallTime = InstallHour & ":" & InstallMin & ":" & InstallSec
    	InstallDateTime = InstallDate & " " & InstallTime
    Next
    
    DeltaHours = DateDiff("h",InstallDateTime,Now)
    DeltaMinutes = DateDiff("n",InstallDateTime,Now)
    
    '------------------------------------------------------------------------
    'If OS is now installed from more than 1 hours, change its password
    If DeltaMinutes < 60 Then
    	'------------------------------------------------------------------------
    	WScript.Quit
    Else
    	'------------------------------------------------------------------------
    	' Handle Account Administrator
    	Set colAccounts = objWMIService.ExecQuery _
    		("Select * From Win32_UserAccount Where Domain = '" & strComputer & "'")
    
    	For Each objAccount in colAccounts
    		If Left (objAccount.SID, 6) = "S-1-5-" and Right(objAccount.SID, 4) = "-500" Then
    			StrAdminUser = objAccount.Name
    		End If
    	Next
    
    	Set usr = GetObject("WinNT://" & strComputer & "/" & StrAdminUser & ",user")
    	usr.SetPassword NewPass
    	'------------------------------------------------------------------------
    End If

    Friday, June 8, 2018 2:50 PM