*Not recommended in Prod, this creates a local account with password, password is in plain text in the TS, Scheduled Task & Registry.
Update 2018/11/09 - After the discovery yesterday of how OOBE removes those AutoLogon Keys, I've created a Scheduled task that I add during OSD that adds the keys post OOBE. It's pretty ugly, but it works. Basic idea: Scheduled Task adds the keys, removes the task, and reboots the machine after 5 minutes. Trigger: Machine Turns on. See more below.. All in all, it adds about 20 minutes onto the process, but you can tweak the reboot delay and shave off a few minutes.
Update: 2018/11/08 - This no longer works with new versions of Windows 10. During OOBE stage (Post Task Sequence, Pre First Logon), the OOBE process deletes two keys: "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" Values: DefaultUserName & AutoAdminLogon If you have it skip OOBE in your unattend.xml, it works, however that setting is deprecated.
I added a local admin account (Non-Domain) that autologon’s on to the computer after OSD purely to speed up my testing. This way I don’t have to wait for First Logon, after OSD, it will reboot, then autologon as the account I’ve Created.
Make sure you add the SMSTSPostAction to reboot, so you don’t get that Group Policy Error the first time you try to logon. (As explained by Niall)
I’ve created a Task Sequence Variable at the start of the TS, that allows you to trigger the AutoLogon Group. Simple Enable or Disable this step to have the Group run.
I then have a group which runs all of the commands individually. You could easily put this into one batch file, I just like to do it this way, self documenting, and requires no content. The group is set to run if the Task Sequence Variable “AutoLogon” = True
I then have 7 “Run Command line” Steps, creating the User and registry keys.
- Tweak – AutoLogon - Create Tony Stark Account
- Tweak – AutoLogon - Tony's Password Never Expire
- Tweak – AutoLogon - Make Tony Admin
- Tweak - AutoLogon - Key DefaultUserName
- Tweak - AutoLogon - Key DefaultPassword
- Tweak - AutoLogon - Key AutoAdminLogon
- Tweak - AutoLogon - Key DefaultDomainName
- Optional: Add two Steps to remove the Legal Notice Prompt (If you have it in your lab, GPO will probably put it back)
- REG DELETE "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v legalnoticecaption /f
- REG DELETE "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v legalnoticetext /f
After TS finishes, it will reboot and start the logon process automatically. Now you can start your testing.
You can change this to fit your needs, use a domain account in your Lab, just change the steps, as you won’t need 1-3 to create the account, and change step 7 to the Domain Name (Contoso, ViaMonstra, etc) instead of %computername%
UPDATE: 2018.11.09 - Update to add Scheduled Task. Adds the registry keys, tells the computer to reboot in 5 minutes, and sets a runonce that deletes itself (the scheduled task). I've tested this a few times, after OSD, it runs OOBE, machine reboots to the logon screen, in the background the script is running, the machine will reboot, and once it as loaded all of the keys it needs, it will auto logon after the next reboot (5 minutes), delete itself, and reboot again (5 minutes). It's not pretty, but it works.
Scheduled Task: Autologon.xml
<?xml version="1.0" encoding="UTF-16"?> <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Date>2018-11-08T22:50:09.07576</Date> <Author>VIAMONSTRA\garytown</Author> <URI>\Test</URI> </RegistrationInfo> <Triggers> <BootTrigger> <Enabled>true</Enabled> </BootTrigger> </Triggers> <Principals> <Principal id="Author"> <UserId>S-1-5-18</UserId> <RunLevel>HighestAvailable</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>PT72H</ExecutionTimeLimit> <Priority>7</Priority> </Settings> <Actions Context="Author"> <Exec> <Command>cmd.exe</Command> <Arguments>/c REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /V DefaultUserName /T REG_SZ /D TonyStark /F</Arguments> </Exec> <Exec> <Command>cmd.exe</Command> <Arguments>/c REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /V DefaultPassword /T REG_SZ /D CapAmericaSt1nks! /F</Arguments> </Exec> <Exec> <Command>cmd.exe</Command> <Arguments>/c REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /V AutoAdminLogon /T REG_SZ /D 1 /F</Arguments> </Exec> <Exec> <Command>cmd.exe</Command> <Arguments>/c REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /V DefaultDomainName /T REG_SZ /D %COMPUTERNAME% /F</Arguments> </Exec> <Exec> <Command>REG.EXE</Command> <Arguments>ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /V LockScreenCleanUp /T REG_SZ /D "SCHTASKS.EXE /DELETE /TN test /F" /F</Arguments> </Exec> </Actions> </Task>
Add as step that imports the Scheduled Task.
schtasks.exe /ru "SYSTEM" /Create /XML AutoLogon.xml /TN "AutoLogon" /F
Please Note, this is sending the information in Clear Text, and will be available in logs, etc. Probably fine for your lab, not a good idea for production. Please don’t say “Hey Boss, don’t worry about it, it’s totally cool, Gary does it!”
12 thoughts on “ConfigMgr OSD Lab–Add AutoLogon Account”
Hello, I'm trying to get this working but my TS is not applying the Password registry step and not changing autoadminlogon to 1. I've validated in the SMSTS.log file that the steps are running as expected but they are missing when I login to the computer and check after it completes the TS. I've moved this step in the TS to almost the end, but still no luck. Any advice?
Place a pause in your TS right after those steps and confirm they are added to the registry. If they are, then I'd guess GPO is changing it after OSD. If they aren't being added, it would seem like syntax. If you run the commands in elevated command prompt POST OSD, and reboot, does it work, or do the keys get wiped out again? Seems environmental.
During a baremetal OSD task sequence, is it possible to ask the engineer deploying the machine in fix AD OU to place the machine and then also actually placing the AD computer object into the OU?, or another way, to add the provisioned machine into an AD OU during the OSD
Yes, this can be done via a powershell or HTA front end for the TS.
I'm having the same issue as Eric however I'm using Windows 10 1803. I've just started using MDT integrated with Config Manager (CB 1802) but have been doing the autologon steps for several years now in other scripts.
I think there must be something in the TS that removes the password and autologon registry entries.
Is this feature still working for you? If so, what OS and CM builds are you using?
And a little more info on this issue:
Gary, does OOBE still deletes those two keys for you in 1809? I read that it was a bug that is supposed to be fixed in 1809, but still didn't work when I tried it. I could be doing something wrong though.
Seems that ofter deprecation of being able to disable OOBE windows is wiping these registry entries unless you follow the workaround to add it via a delayed runonce entry with multiple restarts needed. not pretty and not recommended in production from the latest research and testing I have done.
Also, this is Windows Setup OOBE that is deleting the keys this started with build 1709 and later of Windows 10 as far as I can tell.
I would agree, it's not something you should do in production. I like having autorun setup in my lab to help deal with the first logon times on my test machines. But yes, I'd avoid this on test systems, or any system in my production domain.