MDT 2013 Update 1, In-Place Upgrade to Windows 10. Blank screen and autologin not working RRS feed

  • Question



    I have domain joined clients running Windows 7 and 8.1 Professional, and I am trying to upgrade them to Windows 10 Professional.

    I am doing the majority of the testing on a Hyper-V Virtual Machine running Windows 7 Professional, Retail product key activated. However the issues I am facing are also occurring on a couple of Dell test machines which have either Windows 7 or 8.1 OEM license. I must state, that performing a manual upgrade using the setup.exe (from the MDT Share\Operating Systems folder) does not cause the problems I am about to describe, this is MDT 2013 specific. I am using the standard upgrade client task sequence

    1.        Firstly, the upgrade seems to go fine up until the last stages. It goes through the “Upgrade Windows” phase but gets stuck on this. I get the big circle which shows the upgrade percentage, then the screen which states something along the lines of “It’s taking a bit longer than usual, but it should be ready soon” and then suddenly a black screen – this happens on a VM and on physical machines, so I doubt it’s anything to do with graphics problems. I had left the VM like this for probably around 3 hours yesterday and it was still the same so I was kind of forced to reboot it but it didn’t make any difference, it continues with the “it’s taking longer than usual” message then black screen. The only way I can get into the system is by using RDP, after that I can then reboot it fine and it will give me the login screen like it should without the blank screen
    2.        Once I can RDP into it, the task sequence continues but I have two scenarios:
      1.        If I login using a local admin account (this is the most ideal one to use rather than a domain admin as we try to keep our clients as clean as possible by having a local admin (not called administrator we rename it) and just the domain users who use the PC), I get the error message “You must be logged in using an administrator account. The deployment cannot proceed”. I am assuming this is because it needs access to the MDT UNC share which a local admin account doesn’t have (though I have no idea why it isn’t using cached credentials since the execution of the vbs script is run using the domain admin credentials but initiated from the local admin windows login). This also leaves the MININT and _SMSTaskSequence folders on the local machine
      2.       If I log in as a domain administrator then the task sequence continues and finishes successfully, however this login is not automatic even if I put the credentials into the unattend.xml file OOBE Phase (I notice that my credentials I put in here just seem to get overridden by a random password, I assume MDT is doing that at some point), I have to manually login to finalise the deployment

    These are the only two issues I have remaining now, the black screen and automatic login to finish the process. I doubt I could put anything in the task sequence to help this as the monitoring of the deployment indicates that it is still on the “Upgrade Windows” phase.

    I’d appreciate any help with this, anyone had similar issues?



    Tuesday, September 15, 2015 11:04 AM


  • 1. I am guessing HideShell=YES is set.  And you aren't getting the summary screen.  Set your FinishAction=SHUTDOWN or REBOOT.  You could also HideSummary

    2-1. Log in as .\Administrator

    2-2. Unattend means nothing for Upgrade (so any autologon stuff will be ignored).  You could create a step in the TS to add autologon to the registry.  That would work around this issue.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference

    • Marked as answer by Milkientia Thursday, September 17, 2015 5:52 PM
    Tuesday, September 15, 2015 7:54 PM

All replies

  • 1. I am guessing HideShell=YES is set.  And you aren't getting the summary screen.  Set your FinishAction=SHUTDOWN or REBOOT.  You could also HideSummary

    2-1. Log in as .\Administrator

    2-2. Unattend means nothing for Upgrade (so any autologon stuff will be ignored).  You could create a step in the TS to add autologon to the registry.  That would work around this issue.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference

    • Marked as answer by Milkientia Thursday, September 17, 2015 5:52 PM
    Tuesday, September 15, 2015 7:54 PM
  • Hi,

    I updated to the re-release of MDT 2013 Update 1 but it hasnt made any difference with these issues.

    my HideShell=NO, and SkipFinalSummary=YES. my FinishAction=SHUTDOWN.

    I will mess around with adding the registry keys to autologin using the administrator account and see if that helps, but im suspecting it wont because of the blank screen, i'm pretty sure that is causing a block somewhere....



    Thursday, September 17, 2015 8:56 AM
  • Hi,

    It turns out that the blank screen issue was addressed by setting the autologon keys BEFORE the upgrade phase in the TS (i made a short vbs for this), and then i removed the autologon keys near the end of the TS (another vbs). still baffled as to why this actually happens though.

    Also, your point about the unattend.xml is interesting - if i perform a manual upgrade of the OS i get the OOBE phases to select whether i own the PC or it belongs to the organisation and use express settings and so on, but in the MDT process this is automated - i assumed and thought that such phases are "answered" by using the unattend.xml, is this not the case? how does it get through OOBE in that case?


    Thursday, September 17, 2015 11:35 AM
  • I could be wrong.  I didn't think that the it took the unattend as a parameter to setup.exe.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference

    Thursday, September 17, 2015 5:49 PM
  • Hi, it is my impression too that unattend.xml is not processed during in-place upgrade task sequence execution. I do not find a ZTIConfigure.log.

    I do have the missing autologin behavior that blocks me from full automation of the upgrade procedure. I also wrote a vbs that enables .\Administrator but without success. Keys are removed when I login the upgraded system. Any help?

    Tuesday, January 19, 2016 5:15 PM
  • what I did to get round this was run a batch file just before the Upgrade Windows phase which puts the autologon details for the domain administrator into the registry (it has to be the domain administrator, not just any DA but "THE" DA), also this is a little hit and miss and can sometimes lose the registry settings after the upgrade phase (before it moves onto the next) so I also ran the same thing straight after upgrade. I have found that the first time the autologon gets configured it can still lose it's settings in the registry, I have two domains it affects the one almost all the time, but my domain it doesn't - probably some other domain problems, I didn't configure it all.

    also something else you might want to bear in mind. run a batch file before the windows upgrade phase that writes the LastLoggedOnUser details to a text file on the C drive, then set autologon, then upgrade, autologon again, run some other stuff, and at the end of the process read that txt file back and put the value in the registry, and then delete the text file to clean it up, delete the autologon settings from the registry. this way after the upgrade is complete it will just be sitting at the welcome screen showing the previous user's name ready to sign in, causes less confusion

    hope that helps


    Tuesday, January 19, 2016 5:39 PM
  • I thought this was explicitly fixed in Update 2.
    Tuesday, January 19, 2016 10:29 PM
  • No it didn't seem to be fixed, I heard it was but this issue still happens. the system doesn't login using the local admin or any other domain admin and resume the deployment process, no other account will work except the domain administrator. I have Update 2 for MDT in two completely separate forests/domains and it doesn't do it, I have to implement the stuff above to get round it, it's a little disappointing but I have almost finished my upgrade process of the entire companies now just doing a few each week. we'll get through the pain barrier on it and then it's done, all windows 10 for new purchases.

    My next challenge is configuring WSUS to continue to upgrade from earlier windows 10 builds to later builds, another thing I can't seem to get to work but that's another story for another time.


    Wednesday, January 20, 2016 7:25 PM
  • Hi Steve,

    can you please share with me what are the steps you did to work around it?

    I run a batch that enables autologon just before to launch the upgrade command, but at the end of the upgrade process (so after the black screen with progress percentage and last reboot) the autologon has been reset and machines waits for login. I can not assume that every machine is in a domain when running the upgrade: I do not have these issues when running with MDT the task sequences related to deploymentType=NEWCOMPUTER and deploymentType=REFRESH

    This is the step added in ts before and after the upgrade step (but I checked that the step after is not executed, due to reboot). Is Microsoft willing to fix it?

    Thanks in advance for your help

    <step type="Enable_autologon" name="Enable Autologon" description="" disable="false" continueOnError="false" runIn="FullOS" successCodeList="0 3010">
        <variable name="PackageID" property="PackageID"></variable>
              <variable name="RunAsUser" property="RunAsUser">false</variable>
              <variable name="SMSTSRunCommandLineUserName" property="SMSTSRunCommandLineUserName"></variable>
              <variable name="SMSTSRunCommandLineUserPassword" property="SMSTSRunCommandLineUserPassword"></variable>
              <variable name="LoadProfile" property="LoadProfile">false</variable>
          <action>cscript.exe "%SCRIPTROOT%\SetAutologon.wsf"</action>

    This is the last batch file I tried (simulating domain with .):

    REM enable built-in administrator account
    net user administrator /active:yes

    REM enable auto-logon for built-in administrator account
    REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 1 /f
    REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoLogonCount /t REG_DWORD /d 0 /f
    REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName /t REG_SZ /d . /f
    REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /t REG_SZ /d Administrator /f
    REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d <password> /f

    Thursday, January 21, 2016 2:57 PM
  • Hi,

    I have shown below an image of the task sequence i use, and the scripts i have as well. i have a mix of batch files and powershell script.


    HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI LastLoggedOnUser
    $User = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI
    $UserList = $user.LastLoggedOnSAMUser,$user.LastLoggedOnUser,$user.LastLoggedOnDisplayName
    $UserList | Set-Content C:\LastLoggedOnUser.txt


    Set wshShell = CreateObject("WScript.Shell")
    wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\AutoAdminLogon", "1" , "REG_SZ"
    wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\DefaultDomainName", "mydomain" , "REG_SZ"
    wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\DefaultPassword","Password1" ,"REG_SZ"
    wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\DefaultUserName", "administrator" , "REG_SZ"


    Set wshShell = CreateObject( "WScript.Shell" )
    wshShell.RegDelete "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\AutoAdminLogon"
    wshShell.RegDelete "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\DefaultDomainName"
    wshShell.RegDelete "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\DefaultPassword"
    wshShell.RegDelete "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\DefaultUserName"


    $newuser = Get-Content c:\LastLoggedOnUser.txt
    Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\ -Name LastLoggedOnSAMUser -Value $newuser[0]
    Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\ -Name LastLoggedOnUser -Value $newuser[1]
    Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\ -Name LastLoggedOnDisplayName -Value $newuser[2]


    $computer = $env:computername
    $computer += "*"
    Remove-Item c:\LastLoggedOnUser.txt -Force
    Get-ChildItem c:\ -Force -Filter $computer | Where-Object {!$_.PSIsContainer} | Remove-Item -Force

    As for the local administrator account it does seem that the upgrade process itself actually disables the account, i tried and tried this and i simply couldn't get it to work which is why i had no choice but to use the domain administrator account. unfortunately i dont have any workgroup machines for this, you could try using another local admin account details but not sure if that would work. all my machines are domain joined so it makes it a little easier, if you have a DC you could add extra stuff at the start of the TS to join the machine to the domain (to an OU that does not get any GPO's assigned to avoid any software installs or any other policies), reboot, perform the upgrade, and then perhaps disjoin at the end, though this is not something i have tried myself

    • Edited by Milkientia Thursday, January 21, 2016 9:35 PM
    Thursday, January 21, 2016 3:45 PM
  • Thanks for sharing your stuff Steve! I'll look at it.

    I have one doubt about all this tough situation: is in place upgrade working as expected when disabling local administrator account, or is it a bug? This behavior sounds different from clean install.


    Thursday, January 21, 2016 5:30 PM
  • the local admin is disabled by default since Vista I believe, it should be as well. the upgrade process (I reckon even if you manually run it from the ISO) will disable the local admin after the upgrade phase, it seems to get disabled in around 90+% (black screen percentage circle). enabling the local admin in the hopes you can automate logon just didn't seem to work for me because it gets disabled during the upgrade. if you open a command prompt pre 30% and check if it's enabled you will see it is, but this is the WinPE admin not the main windows, to see the main local admin I think it gets into the OS structure around 60% or something (type hostname) will tell you if it's the MININT or the name of your computer) and eventually you will see that it is indeed enabled and active if you enabled it before upgrade, but once it gets somewhere above 90% it then gets disabled again which is why you can't login using the local admin. the only way I managed to do it was using the domain administrator account.
    Thursday, January 21, 2016 7:54 PM
  • Hi Steve, I tried my TS with MDT 2013 U2 (my previous posts were related to tests done with MDT 2013 U1) and local administrator account was not disabled after the upgrade, while autologon continues being reset even if set before the upgrade.

     It still does not work for me, but it is a little step forward.
    • Edited by Michele.T Thursday, January 21, 2016 8:40 PM
    Thursday, January 21, 2016 8:39 PM
  • it was several months ago when I tested this route, maybe I came across the same thing and found that the autologon for domain administrator was still the only workaround.

    so, you have run the batch file before the upgrade phase and you know the registry keys are definitely being written right? you can see them in regedit before the OS reboots?

    are you only trying this with the local administrator or have you tried this with the domain administrator as well? I could only get this process working with THE domain administrator account, no other local admin or any other domain admin would work for me, it was the only way it would work.

    are all the registry keys being reverted or is it only some of them, you have things like defaultpassword and defaultusername, and defaultdomain name?

    bear in mind if you are logging in with the local admin your default domainname will be .\

    if you login using the domain admin you need to specify your domain, such as mydomain.local

    Thursday, January 21, 2016 8:57 PM