# MDT 8443 / W10Ent 1703 auto login and Wsus issue

• ### Question

• Hi,

I have deployed many MDT installations, but today i'm facing 2 new "bugs" i think

- While deploying W10E1703x64 during mdt rollout suddently the shell isnt hidden anymore (not always happening , seems random)
- after first reboot the autologin is not working so i a have to enter manualy the administrator password (once), then MDT
continue's

- During the rollout when WSUS is contacted to search/install updates the machine "hangs" on a searching wsus. al i can do is cancel the rollout.

does somebody else has the same issues ?

(i have the 1703 ADK installed and created / published the new boot environment)

Monday, April 10, 2017 2:03 PM

• OK, so using a PowerShell in the task sequence to set the Auto Login registry keys seems to work.  They even get removed automatically at the end of the task sequence so that part still seems to be working.

I added a Run PowerShell script to run Set-AutoLogon.PS1 at the start of the State Restore in the task sequence with the following code:

$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" Set-ItemProperty$RegPath "AutoAdminLogon" -Value "1" -type String
Set-ItemProperty $RegPath "DefaultPassword" -Value "Password" -type String That let the task sequence complete and as I already mentioned I didn't have to add anything to clean it up at the end as that part still seems to work correctly. D Tuesday, April 11, 2017 12:13 PM ### All replies • Seeing the same autologin issue. MDT 8443 with ADK 1703 upgraded from 1607, updated the deployment share and forced a rebuild of the boot isos. It will stop logging in after the first windows update pass restart. After that I need to log in manually to continue the remaining task sequences. • This particular task sequence is not performing a domain join. It's just installing applications & updates and then capturing. • Windows updates are from MS Update not the internal WSUS server. • I verified that it still works fine with the 1607 OS wim. Monday, April 10, 2017 10:54 PM • Hi, i have exact the same issue. MDT 8443, ADK 1703. I have never tried it with ADK 1607. My 1607 Task Sequence works without any issue. As soon as I Change the install.wim from 1607 to 1703 the autologin issue appears. I had not found time to troubleshoot the issue further but from my Point of view, it is definitely related to the Current 1703 Version of Windows 10. Regards Stefan Tuesday, April 11, 2017 6:40 AM • Can confirm the AutoLogon Bug if you have a restart in the tasksequence. • MDT 8443 • ADK 1703 • Win10 1703 Same Setting with 1607 without any problems Tuesday, April 11, 2017 9:30 AM • Same AutoLogin issue looks like the Default password registry and autologin registry aren't being set (not 100% sure if that is how it works in the older ones as I have never looked). Setting the registry keys manually seems to work so going to look adding a PowerShell script to the task sequence to set the keys and see what happens. Using WSUS with no issues though. D • Edited by Tuesday, April 11, 2017 10:50 AM Tuesday, April 11, 2017 9:32 AM • Hi, Do you have WSUS on 2012R2?, with that we do NOT see the issue, we only see the issue on WSUS of server 2016, also after a manual install of W10E 1703 we have WSUS issues, wsus detects the needed updates, but keeps @ the "downloading 0%" state Tuesday, April 11, 2017 11:54 AM • The first/initial Auto Login is set with the unattend.xml and works as expected. Therefore, i think the keys are set correctly! However, at some Point it seems that the keys are "lost". I see two issues: • Sometimes I get the message "unknown username or bad Password" • and sometimes the Installation stops without a message on the Login Screen I'm not sure why I see different issues... Regards Stefan Tuesday, April 11, 2017 12:05 PM • Yes we are currently running WSUS on 2012R2. See no issues at all with that setup so far. D Tuesday, April 11, 2017 12:07 PM • OK, so using a PowerShell in the task sequence to set the Auto Login registry keys seems to work. They even get removed automatically at the end of the task sequence so that part still seems to be working. I added a Run PowerShell script to run Set-AutoLogon.PS1 at the start of the State Restore in the task sequence with the following code: $RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty $RegPath "AutoAdminLogon" -Value "1" -type String Set-ItemProperty$RegPath "DefaultPassword" -Value "Password" -type String

That let the task sequence complete and as I already mentioned I didn't have to add anything to clean it up at the end as that part still seems to work correctly.

D

Tuesday, April 11, 2017 12:13 PM
• alternative solution via cmd

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoAdminLogon" /t REG_SZ /d "1" /f /reg:64

• Edited by Tuesday, April 11, 2017 1:51 PM
• Proposed as answer by Wednesday, April 12, 2017 6:09 PM
Tuesday, April 11, 2017 1:51 PM
• alternative solution via cmd

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoAdminLogon" /t REG_SZ /d "1" /f /reg:64

but why would you use CMD when there is PowerShell? ;P

D

Tuesday, April 11, 2017 2:47 PM
• Thanks for the solution for the Autologon.

Now my deployments will go smoothly again.

This was the only thing that hold me back deploying the new version of Windows 10

Tuesday, April 11, 2017 8:59 PM
• The reg add resolved it for me, placing it after State Restore. Thank you.
Wednesday, April 12, 2017 6:10 PM
• - During the rollout when WSUS is contacted to search/install updates the machine "hangs" on a searching wsus. al i can do is cancel the rollout.

does somebody else has the same issues ?

(i have the 1703 ADK installed and created / published the new boot environment)

I am seeing the updates issue on Server 2012 R2 during auto build of image. I tried adding the 1703 cumulative update to packages to see if that would resolve the WSUS update issue, but it did not. The update task times out after 10 tries. It is working fine with the current 1607 version. Does anyone have a fix yet?
Friday, April 14, 2017 3:21 PM

we still have the issue, working already a couple of days on it to find a solution.
what i did see is that if i allow the test mdt rollout machine internet access while deploying.

it wil work, as soon as we remove the firewall rule that allows the machine internet access it fails again direcly

Saturday, April 15, 2017 1:58 PM
• Same problem here, see this post:

• Proposed as answer by Monday, June 19, 2017 9:00 AM
Saturday, April 15, 2017 6:02 PM

here also the same problem,,,,,

Saturday, April 15, 2017 8:09 PM
• alternative solution via cmd

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoAdminLogon" /t REG_SZ /d "1" /f /reg:64

I've tried this and it creates the required values, but before the next reboot the password is cleared again. I created a new image from the MSDN 1703 ISO. I can't be sure, but I have a feeling the problem is that the first logon is done automatically by Windows Setup, and then the completion of Setup clears the value.

My "workaround" has been to continue using my older 1607 image and updating to 1703 in the task sequence. Maybe it'll work better when the official ISO is released next week.

Monday, April 24, 2017 8:35 PM
• Dear all,

Just would like to confirm that I had the same problem and the PowerShell script seems to have solved the bug!

Many thanks,

Thursday, May 4, 2017 9:12 AM
• Is there going to be a better fix for autologon than adding plain text passwords to the registry? That doesn't really seem like a real solution for this issue.
Saturday, May 6, 2017 3:41 PM
• I can confirm this issue also.

• MDT 8443
• Win10 1703

Win10 1607 works without issue.

I use the Unatended.xml file to change the autologon account to a domain account and that does not work at all on 1703. It seems the file (or at least the autologon portion) is being ignored.

• Edited by Wednesday, May 10, 2017 3:45 PM Bullet list fix
Monday, May 8, 2017 7:08 PM
• I can confirm this one too. Anyone know if it blanks the password keys on every reboot? I use multiple reboots in my build and capture task sequences. Working to apply the suggested PowerShell script fix now...
Tuesday, May 9, 2017 1:40 PM
• Well this is just great, I got the script working but it looks like any reboot is enough to clear those auto-login keys. Wonderful.

Correction - I may be in error here. It so happens our Local admin password has a "$" in it and I think PowerShell is having a hard time interpreting that... Trying again. • Edited by Tuesday, May 9, 2017 3:14 PM Tuesday, May 9, 2017 3:10 PM • Final Correction - So that was my mistake. Just a quick note if you are using special characters in your passwords and you are using PowerShell may want to use single quotes in your variable definitions, like so: $MyPass = 'P@w0rd'

The aforementioned fix is working fine for me now as well.

• Edited by Tuesday, May 9, 2017 4:15 PM
Tuesday, May 9, 2017 4:15 PM
• hello i have the same problem, after first reboot the autologin is not working and i  enter manualy the administrator password (once), MDT did not continue's too.

i have try your powershell script but i did not know how to write the script in task sequence command and where the script save location, can your show me the photo. many thanks.

Wednesday, May 10, 2017 10:02 AM
• Can you please explain "State Restore" in the task sequence.  We are using Kace 2000 for imaging.  I have looked at all the built in tasks and custom tasks and nothing is called "State Restore".  How exactly did you do this?

thanks,

Daryl

Thursday, May 11, 2017 3:01 AM
• Regarding the update check/download hang problem with WSUS: in our case, the deployment network does not have internet access. Based on the new Delivery Optimization features in the update delivery (that's apparently enabled by default in 1703), Windows attempts to connect to internet sources for bigger updates (eg. cumulative updates), which leads to the update check seemingly hang, and the downloads to fail when internet connection is not present.

For normal computer deployments, if they are joined to domain, you can disable this feature in GPO. However for image refresh deployments, where you need to run sysprep/capture and therefore the computers are not joined to domain, you need to use other methods.

We were able to work around this problem by adding a "run commandline" task step before the windows update steps, that imports this setting into the registry

---<copypaste this into a .reg file>---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

---<end-of-file>---

And import this file in the commandline with

reg.exe import %deployroot%\path\to\file.reg

We also saw another reason for the check for updates step to hang: the WSUS server had accumulated a load of superseded but non-declined updates (over 10k), and the WU client's hardcoded response size limits were exceeded. The WSUS cleanup wizard has a step that is described as "decline superseded updates", but it does not actually do that. We googled for a powershell script that actually does decline those updates, and after that the computers suffering from this problem were able to update.

Thursday, May 18, 2017 10:40 AM
• Can you please explain "State Restore" in the task sequence.  We are using Kace 2000 for imaging.  I have looked at all the built in tasks and custom tasks and nothing is called "State Restore".  How exactly did you do this?

thanks,

Daryl

State Restore, is something in MDT in K2000 just make a post install task near the top of your sequence with either the bat file solution or the powershellscript as a new application.
Wednesday, May 24, 2017 6:55 PM
• I KNOW it has never been necessary to add to Customsettings.ini before but apparently it works. Just make sure the two lines below are present:

Thursday, June 1, 2017 8:49 AM
• I KNOW it has never been necessary to add to Customsettings.ini before but apparently it works.
Just make sure the two lines below are present:

Thursday, June 1, 2017 8:51 AM
• No Powershell needed..

I KNOW it has never been necessary to add to Customsettings.ini before but apparently it works. Just make sure the two lines below are present:

Thursday, June 1, 2017 8:53 AM
• Hi,

I have deployed many MDT installations, but today i'm facing 2 new "bugs" i think

- While deploying W10E1703x64 during mdt rollout suddently the shell isnt hidden anymore (not always happening , seems random)
- after first reboot the autologin is not working so i a have to enter manualy the administrator password (once), then MDT
continue's

- During the rollout when WSUS is contacted to search/install updates the machine "hangs" on a searching wsus. al i can do is cancel the rollout.

does somebody else has the same issues ?

(i have the 1703 ADK installed and created / published the new boot environment)

They definitely made some consumer and data collection friendly changes in 1703.  This Windows Update internet connection requirement may be a bug, or may be their attempt to force machines to collect some form of telemetry.

To fix the autologin issue, I had to either apply the Group Policy:
"Allow Microsoft accounts to be optional" - Enabled

Or apply via registry via MDT task:

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v MSAOptional /t REG_DWORD /d 1

AND... had to add the following to my CustomSettings.ini (Deployment Share properties --> Rules Tab)

SkipAdminPassword=YES


To fix the WSUS issues (Firewall blocking Windows Update internet locations) I had to do the same.

Group Policy:

(Previously set to "1-HTTP")

Computer Configuration\Administrative Templates\Windows Components\Windows Update "Do not connect..."
(Previously "Not Configured")

For MDT, the same was set via MDT task for the registry (before Windows Update is executed).

REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization /v DODownloadMode /t REG_DWORD /d 100

Do not connect...

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v DoNotConnectToWindowsUpdateInternetLocations /t REG_DWORD

There's no place like 127.0.0.1

• Edited by Friday, June 9, 2017 10:29 PM cs.ini
• Proposed as answer by Tuesday, June 13, 2017 7:31 PM
Friday, June 9, 2017 6:14 PM
• Has there been any official response from Microsoft on this? Is Autologon in the Unattended.xml file depreciated in MDT?
Monday, June 12, 2017 1:46 PM
• Hi,

I have deployed many MDT installations, but today i'm facing 2 new "bugs" i think

- While deploying W10E1703x64 during mdt rollout suddently the shell isnt hidden anymore (not always happening , seems random)
- after first reboot the autologin is not working so i a have to enter manualy the administrator password (once), then MDT
continue's

- During the rollout when WSUS is contacted to search/install updates the machine "hangs" on a searching wsus. al i can do is cancel the rollout.

does somebody else has the same issues ?

(i have the 1703 ADK installed and created / published the new boot environment)

Hi there.  I'm now facing this issue as well.  I did see the proposed answer with the PowerShell command and I think that will work for me but to be honest I'm not sure exactly how to get that in the task sequence.  I set all of my MDT stuff up a few years ago and aside from changing a few minor things here and there I haven't really had to reconfigure anything.  Would you be able to create me a quick walkthrough on exactly how to add this powershell command in? I would really appreciate it if so.  Thank you.
Monday, June 12, 2017 4:56 PM
• OK, so using a PowerShell in the task sequence to set the Auto Login registry keys seems to work.  They even get removed automatically at the end of the task sequence so that part still seems to be working.

I added a Run PowerShell script to run Set-AutoLogon.PS1 at the start of the State Restore in the task sequence with the following code:

$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" Set-ItemProperty$RegPath "AutoAdminLogon" -Value "1" -type String
Set-ItemProperty $RegPath "DefaultPassword" -Value "Password" -type String That let the task sequence complete and as I already mentioned I didn't have to add anything to clean it up at the end as that part still seems to work correctly. D Hi there. I'm now facing this issue as well. I did see the proposed answer with the PowerShell command and I think that will work for me but to be honest I'm not sure exactly how to get that in the task sequence. I set all of my MDT stuff up a few years ago and aside from changing a few minor things here and there I haven't really had to reconfigure anything. Would you be able to create me a quick walkthrough on exactly how to add this powershell command in? I would really appreciate it if so. Thank you. Wednesday, June 14, 2017 6:29 PM • I'm having this same problem with Windows Updates, only it's the opposite: I'm just having Win10 1703 download from Windows Updates over the internet because we don't have an internal WSUS server to point our reference builds to when creating them. In 1607, when I use netsh to set the proxy server it will work just fine downloading the updates when it hits the update step in the task sequence, but if I change to 1703 then WU just hangs on downloading and doesn't do anything. Wednesday, June 14, 2017 6:30 PM • Looks like an update is being released to address the autologon issue: https://support.microsoft.com/en-us/help/4022716/windows-10-update-kb4022716 Wednesday, June 28, 2017 1:27 AM • I noticed. Already making a new image at the moment. I'll let you know if it really works, since we all know Microsoft. :) Wednesday, June 28, 2017 9:05 AM • The autologon problem is solved. That is 1 step forward. I import a custom startmenu layout, and that is still not working like it should. When you press the windows key on the keyboard, nothing happens. And with nothing I mean nothing. Even when you click on the windows icon on your taskbar, nothing happens. Wednesday, June 28, 2017 11:40 AM • Well the update seemed to have fixed logging on with a local account. I still can't pass the domain via the unattended.xml, to autologon as a domain account. Anyone else use this? Friday, June 30, 2017 4:39 PM • set the following variable in customsettings.ini in mdt and the issue is fixed. I had the same anoying issue that the autologon was not working but fixt it with this line for Windows 10 1703 : Customsettings.ini AdminPassword=yourpasswordherewithoutquotes • Edited by Friday, July 21, 2017 11:17 AM • Proposed as answer by Friday, July 21, 2017 11:17 AM • Unproposed as answer by Friday, July 21, 2017 11:17 AM Friday, July 21, 2017 11:16 AM • set the following variable in customsettings.ini in mdt and the issue is fixed. I had the same anoying issue that the autologon was not working but fixt it with this line for Windows 10 1703 : Customsettings.ini AdminPassword=yourpasswordherewithoutquotes Anyone else noticing this BREAKS the x86 Windows 10 1703 MDT installs? There's no place like 127.0.0.1 Tuesday, July 25, 2017 5:45 PM • I just wanted to report that this issue has been fixed in the latest release of windows. You do not need to add this auto-login script (which worked ok, but is now redundant); You do NOT need to go get a new ISO, simply run windows updates on your base image. Please select as answer so others see this post. Monday, July 31, 2017 5:46 PM • I just wanted to report that this issue has been fixed in the latest release of windows. You do not need to add this auto-login script (which worked ok, but is now redundant); You do NOT need to go get a new ISO, simply run windows updates on your base image. Please select as answer so others see this post. Do you know which KB this was fixed in? Also, for the WSUS issues, my history and solutions: https://social.technet.microsoft.com/Forums/en-US/88771e56-8be0-4bc9-b674-648619eab2ac/windows-10-pro-1703-and-windows-update-with-wsus?forum=win10itprogeneral There's no place like 127.0.0.1 • Proposed as answer by Tuesday, August 8, 2017 4:08 PM Tuesday, August 8, 2017 4:08 PM • I tried to slipstream the latest MSU patch but it fail with DISM. Is there a new ISO available? Thursday, August 10, 2017 6:35 PM • Running this as a powershell script from your task sequence in StateRestore will handle the autologon issue, and doesn't require you to duplicate your AdminPassword in another place:$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty $RegPath "AutoAdminLogon" -Value "1" -type String$password = [System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($tsenv:AdminPassword)) Set-ItemProperty$RegPath "DefaultPassword" -Value "\$password" -type String

Monday, August 21, 2017 4:33 PM
• So I have to ask.....if you can't log on automatically as admin, and you add a script in the State Restore, whose desktop is running it? Aren't you logged on as a user to run the command allowing you to log on as a user?
Wednesday, September 6, 2017 1:44 PM