Windows 10 Creators AutoLogin Count

I sysprepped a Window 10 Creators virtual machine with an unattend.xml file created using Sysprep Creator  I captured the WIM image in my K2000 (v3.7.120345), added the necessary tasks and deployed the image to a machine.  No errors in the deployment but it doesn't seem to recognize the AutoLogon LogonCount from the unattend file.  The machine reboots after copying drivers but doesn't autologin.  If I login manually, the deployment continues to completion. I thought maybe the Creators update needed a greater number of reboots than older versions of Windows 10 so I added the "Set Autologin Count" script (found in ITNinja) as a post install task and set it to a much greater number than was in my unattend.  I can see in the debug file that it's finding my original count and changing it to my new count.  That didn't help (still needed to login manually to complete deployment) so I went back to my virtual machine and sysprepped again with a greater autologin count.  The revised image still won't autologin to complete deployment.  Autologin has always worked OK in previous versions of Windows.  Did something change between 10.0.14393 and 10.0.15063?

1 Comment   [ + ] Show comment
  • Same issue here. Created new unattend.xml file and it will still not autologon and finish imaging. It does not work x86 or x64 with the new Windows 10 Creator edition. I been using this same unattend.xml for Windows 7, Windows 8, Windows 8.1, and every previous version of Windows 10. It will not work with this latest version even after recreating it with the latest MS ADK. Has anyone been able to figure this out? - daryl_forman@scps.k12.fl.us 4 years ago

Answers (3)

Posted by: Mr. Andersen 3 years ago
White Belt


It seems Microsoft has addressed this issue with KB4022716 (OS Build 15063.447).


-Addressed issue where, if you specify an auto-logon configuration in Unattend.xml, auto-logon only works on the first logon, but will not work again when the device is restarted.  

I installed Windows 10 Enterprise 1703, updated to KB4025342 (OS Build 15063.483) via. windows update. Did a sysprep, captured the image to k2000 and tried out the deployment.

Autologon now works again with the specified amount of autologon set in the unattend.xml file, so basically the fix is just to update to at least Build 15063.447 before doing the sysprep.

Hope this helps someone.

Best regards

Posted by: chucksteel 4 years ago
Red Belt
This feature seems to have been disabled with 1703. See the following:
That refers to provisioning packages and not unattended installations, but it appears to be the case for both.

Technet thread:

Reddit thread:

I created two post-install tasks to get around the problem. The first sets the autologin registry keys, I run this as the first task. The second removes them, I run this last.

  • Thanks, chucksteel, for the tips. I created a post-install task to edit the registry with the items from the Technet thread. That didn't work because the machine reboots (and doesn't autologon) before it gets to that step. I created another mid-level task but that didn't work either. Can you give me example of the first task you created? - LHYardi 4 years ago
    • I used the batch file method since there isn't native support for Powershell in the K2000:
      reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoAdminLogon" /t REG_SZ /d "1" /f /reg:64
      reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "DefaultPassword" /t REG_SZ /d "passwordhere" /f /reg:64

      I still have the unattend answer file set to auto login and it does login the first time. This is my first post-install task that runs. - chucksteel 4 years ago
      • I tried this method, but my batch file doesn't change the registry. - ITsaurusRex 4 years ago
      • What does your script look like? - chucksteel 4 years ago
      • I did this as a post task install and it worked great. I configured it as a Batch Script and added both lines (ensuring the password matched the one that I had in the unattend.xml files used to install windows. - DaveMT 4 years ago
      • My batch file is exactly like the one posted by chucksteel (also with password matching unattend). No errors in deployment but also no registry entries after initial reboot after copying drivers. It gets as far as the step called "Run DPInst" but will go no further without manual login. - LHYardi 4 years ago
      • It's exactly as what you have listed. I tried to run this on a Win10 machine as an admin user, and it still does not change the value for AutoAdminLogon. But when right clicked and run as admin, it did it. I might have to use runas or point it to a reg file to make this work. - ITsaurusRex 4 years ago
      • We are using a Scripted install and I have this set as a Post-Installation Task and the first one to run. LIke Chucksteel, we run running a Batch Script and with the exception of the password, here is ours as well (matches Chucksteel's):

        reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoAdminLogon" /t REG_SZ /d "1" /f /reg:64
        reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "DefaultPassword" /t REG_SZ /d "SECRETPASSWORD" /f /reg:64 - DaveMT 4 years ago
      • Chuck,

        I used your method and what happened for me was after deploying the image, the computer restarted, I had to login once, and then the rest of my tasks completed without further input.

        I also made it my first post-install task, but it's continuing to autologin, instead of cleaning out on it's own.

        Any ideas? - phillybits 3 years ago
      • @phillybits Does your unattend file still include the autologin settings? That setting still needs to be present in order for the user to login the first time, the issue is that the count no longer works, so it only happens once.

        If you set the autologin then it won't clear out when finished. You need to add a post-install task at the end to delete those registry keys. - chucksteel 3 years ago
      • Chuck,

        I'm getting caught off-guard by several changes very recently, but my method has always been basically the same.

        I build my image and create my local admin account on it. Then I use sysprep creator, plug in the credentials, and set my autologin value.

        It was only after I tried this on a new 1703 install that I realized autologin was no longer working. - phillybits 3 years ago
    • It's possible that there is a difference between using a sysprepped image and a scripted install. I'm using a scripted install. Also, are you using 64bit Windows 10? - chucksteel 4 years ago
      • Could be. I'm using sysprepped, Windows 10 x64. - LHYardi 4 years ago
      • Same here - ITsaurusRex 4 years ago
      • We are using a sysprepped image, Win 10 x64, system image in Kace. Tried it as the first post install task and it still required me to logon once. Where in the task sequence does this need to go? - daryl_forman@scps.k12.fl.us 4 years ago
      • I've managed a workaround by changing the tasks.xml to disable reboot on the step "DPInst". After this step I've got a post-task that adds autologon info to registry and then reboots.

        I changed the tasks.xml with a mid-level task using powershell script:

        $content = get-content x:\KACE\engine\Tasks.xml
        Foreach ($_ in $content) {
        if ($_ -eq '<Name>Run DPInst</Name>'){
        $val = 1
        if ($val -eq 1 -And $_ -eq '<PostTaskAction>Reboot</PostTaskAction>'){
        $_ = '<PostTaskAction>None</PostTaskAction>'
        $val = $val + 1
        Add-content C:\temp\Tasks_custom.xml "$_"
        copy-item C:\temp\Tasks_custom.xml x:\KACE\engine\Tasks.xml -force
        #--------------------------------------------------------------- - p3rss0n 4 years ago
      • @P3rss0n how are you running powershell mid-level? - samueld4 4 years ago
      • @samueld4 First I added powershell to the KBE with KBE manipulator. Then to run the powershell script I created a mid-level application task with a zip of the powershell script and a bat script. Then I use the bat to start the powershell script. bat script:

        powershell.exe -executionpolicy bypass -file somefile.ps1 - p3rss0n 4 years ago
  • I found a fix. It turns out 1703 logs in by itself to finish something. So even if you set the registry to autologin it will fail at that part. The only way was to modify the unattend.xml to edit the registry on that first logon. Once I do that it works fine. Just make sure you disable the registry entry at the end as a post install task.

    <SynchronousCommand wcm:action="add">
    <CommandLine>REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 1 /f</CommandLine>
    <SynchronousCommand wcm:action="add">
    <CommandLine>REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /t REG_SZ /d .\localUser /f</CommandLine>
    <SynchronousCommand wcm:action="add">
    <CommandLine>REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d thisisapassword</CommandLine>
    </FirstLogonCommands> - robert_everland 4 years ago
    • I'm doing something similar to @p3rss0n and @robert_everland.

      First, I disable the DPinst reboot with the mid-level task found here: http://www.itninja.com/blog/view/disable-the-dpinst-reboot-in-k2000-3-6

      Then I run the following in a batch file as a post-installation task:

      @echo off

      REM Replace USERNAME with a local account
      REM Replace PASSWORD with the password for your local account
      REM The value of AutoLogonCount can be changed if necessary

      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 DefaultUserName /t REG_SZ /d USERNAME /f
      reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d PASSWORD /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 AutoLogonCount /t REG_DWORD /d 1 /f - jsnye 4 years ago
      • I tried using the DPinst task you mentioned but it failed, so I dropped it.

        The problem I have now is as follows:
        1. Image applies, drivers install, machine reboots.
        2. I must log in 1x. Then the script above kicks in.
        3. However, I get a username or password error.

        My script would basically look like this:

        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 DefaultUserName /t REG_SZ /d MyLocalAdminAccount /f
        reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d MyAdminPassword /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 AutoLogonCount /t REG_DWORD /d 1 /f

        I'm guessing the DefaultDomain part is putting the .\ in for me?

        Did I miss something? I know the credentials are absolutely correct. - phillybits 3 years ago
      • I'm pretty sure the defaultdomainname is just . not .\ - chucksteel 3 years ago
      • That's strange. Firstly, I don't understand why the disable DPinst reboot task is failing. Without that won't your machines just reboot after the first autologon, not allowing your script to run in the first place?

        As far as the username or password error, what have you included in your unattend.xml file for autologon? If you login manually with the same username and password, it works? - jsnye 3 years ago
      • @chucksteel I just looked at my script and confirmed that DefaultDomainName is working in my environment with .\ - jsnye 3 years ago
      • Part of my problem is that Windows is interpreting my password incorrectly and I'm not sure why.

        I ran into this area when I was first learning how to sysprep using the sysprep creator. Password with certain characters have those characters interpreted as XML. This will create a wrong password when applied. In my case, it was the ampersand (&).

        Ex: fruit&apple's vs fruit&amp;apple's

        I have tried both version and after the image is applied and the machine first reboots, I have to login. It continues tasks and starts the second reboot and gives a bad username/password message. It's definitely trying to pass it, but it's not passing it correctly. - phillybits 3 years ago
    • @robert_everland This approach worked for me on my sysprepped x64 image. Thank you. - LHYardi 4 years ago
Posted by: jgarcia29 3 years ago
Orange Senior Belt
adding monthly roll-up updates as a post install task in a scripted install, disable autologin again.
Is there a better more reliable method to achieve this?
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ