Autologin Still doesn't work.

Question

Autologin Still doesn't work.

Templvr21 opened this issue 6 years ago · 21 comments

I have been testing out a Boxstarter script on a local Hyper-V VM but no matter what I do I can't seem to get the machine to automatically log in after restarting. I've tried writing the switch as "-Credential Get-Credential userName", "-Credential (Get-Credential userName)" (as recommended by another user experiencing this issue) and passing the credentials to the switch through a variable, as "-Credential Get-Credential $creds" but I still have to enter my password each time it restarts. I also tried running the Enable-BoxstarterVM command, but it prompted me to install the Hyper-V Powershell module with the following command that failed:

Install-windowsfeature -name hyper-v -IncludeManagementTools

Any help is appreciated; thanks.

Answer 1 · 2018-07-18T21:17:18.000Z

try -Credential $creds. If you have already save creds to a variable there is no need to use Get-Credential which will prompt you.

Answer 2 · 2018-07-19T04:05:11.000Z

Thank you for the response. Sorry; that's what I meant—I'll enter Install-BoxstarterPackage -PackageName name -Credential $creds after already creating a PSCredential object and storing the memory ID in $creds. In all three instances I described in my initial comment, as soon as the package finishes downloading, the computer will either restart or begin installing the package, depending on whether or not I've attempted to run the script previously, usually restarting when I run the Install-BoxstarterPackage command the first time. When I run the command the first time, Boxstarter with download the package and restart; once the computer boots up, the login screen appears prompting me for a password. I've also checked that the VM I'm running the command on has the latest version of Boxstarter, and uses the latest version of Chocolatey contained with the Boxstarter software.

Answer 3 · 2018-08-05T18:56:10.000Z

Is this maybe related to #1 ?

Answer 4 · 2018-08-28T20:38:24.000Z

I'm having the same issue on Windows 10 where the reboot happens and then it sits on the login screen without logging in. When I manually log in I can see Boxstarter already running.

Answer 5 · 2018-08-28T20:51:36.000Z

@yodurr is this also on Hyper-V?

Answer 6 · 2018-08-28T21:51:30.000Z

Yes, on Hyper-V. The particular scripts I'm running are on aka.ms/devsetup
But I'm also seeing this in non Hyper-V scenarios.

We need to dig into this further to identify root cause.

Answer 7 · 2018-09-03T11:11:08.000Z

I have the same problem. Hyper-V on Windows 10 with a Windows 10 virtual machine. After first reboot it is stuck at the login screen.

Answer 8 · 2018-09-10T17:45:43.000Z

I have done demos with this functionality working with Windows 10 Pro 64bit VM. When did this change, as Autologin was working. Could this be something stemming from Windows 1803. Going to try 1703 and report back.

Answer 9 · 2018-09-10T21:17:15.000Z

In 1703, Boxstarter commits a reboot and on reboot I have to manually login. But script continues to run and also prompts me to provide a password, where in 1803 I dont get this prompt

regardless on the next run I still had to provide the password.

I initially started the script from 32bit powershell

Answer 10 · 2018-09-10T21:56:52.000Z

ok giving up for now I sent all the way back to Windows 10 1511 and still can not get the OS to autologin. Something must have changed in Boxstarter in 2.11 although I checked my at my recorded demo it I used 2.11 on 1803 and was working.

Answer 11 · 2018-09-10T23:51:03.000Z

So I kept digging further. I never checked the registry for this as the autologin process was working at some point.

Here is the local user account SID:

Here it the Autologin Registry key and points to the correct SID:

What I don't see are the following Registry keys:

DefaultUserName
DefaultPassword
AutoAdminLogon

Which I assume are for hard coded credentials only which is not the intention here for Boxstarter.

If the correct SID is being configured could the issue be stemming from the encrypted string for the password?

Answer 12 · 2018-09-11T02:17:46.000Z

ok this has to be a Windows 10 issue I haven't seen until now

I used this settings without even installing Boxstarter:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultUserName"="USERNAME"
"DefaultDomainName"="DOMAIN"
"DefaultPassword"="PASSWORD"
"AutoAdminLogon"="1"

The autologin mechanism seems broken in my machine. I may have to rebuild and try again.

Answer 13 · 2018-09-17T19:11:46.000Z

I've just tried this with a vagrant VB VM and it works fine.

Going to test the exact same setup on a Hyper-V VM and will see what that gives me.

Answer 14 · 2018-11-27T09:01:16.000Z

I've added the above registry entries to a fresh Windows Server 2016 hyper-v image:

I still have to login after rebooting the machine.

Answer 15 · 2018-11-28T08:21:04.000Z

Boxstarter can keep executing a script/package, even if the autologin is not working. Here's my experiment:

Create a new Boxstarter package based on this very simplistic file reboot.ps1:

Invoke-Reboot

Which can be turned into a package with a local copy of Boxstarter by running:

Import-Module 'C:\ProgramData\Boxstarter\Boxstarter.Chocolatey'
New-PackageFromScript .\reboot.ps1 my.reboot
Copy-Item $Boxstarter.BaseDir . -Recurse

Next I copied over the .\Boxstarter folder to my Windows Server 2016 Hyper-V image. If we now start the process by running:

.\Boxstarter\Boxstarter.bat my.reboot

The machine keeps rebooting, even if no autologin happens.

It seems to me that the user is logged in, but the machine is just locked (similar to how you lock a machine by pressing Win + L).

Answer 16 · 2019-04-26T02:54:56.000Z

I think, I know the issue with -Credential $creds not working for local installation (i.e., if you are specifying a different username and password in $creds).

Install-BoxStarterPackage invokes Invoke-Locally function for local installation of packages. Invoke-Locally only keeps password and gets rid of the Credentials from $PSBoundParameters, before passing it onto Invoke-ChocolateyBoxstarter. So, the username supplied via $creds is lost.

Then Cleanup-BoxStarter function queries the current user session for username and uses that for AutoLogon setup. So, if you try to execute Install-BoxStarterPackage under a different user by specifying -Credential $creds, its never going to work.

I am trying to run this as part of "userdata" on AWS and it doesn't work, because userdata is executed under SYSTEM account. And the $creds that I am passing are for local admin account.

See the code from Install-BoxStarterPackage below:

function Invoke-Locally {
    param(
        [string[]]$PackageName,
        [Management.Automation.PsCredential]$Credential,
        [switch]$Force,
        [switch]$DisableReboots,
        [switch]$KeepWindowOpen,
        [switch]$DisableRestart,
        [string]$LocalRepo
    )
    if($PSBoundParameters.ContainsKey("Credential")){
        if($Credential -ne $null) {
            $PSBoundParameters.Add("Password",$PSBoundParameters["Credential"].Password)
        }
        $PSBoundParameters.Remove("Credential") | Out-Null
    }
    else {
        $PSBoundParameters.Add("NoPassword",$True)
    }
    if($PSBoundParameters.ContainsKey("Force")){
        $PSBoundParameters.Remove("Force") | Out-Null
    }
    $PSBoundParameters.Add("BootstrapPackage", $PSBoundParameters.PackageName)
    $PSBoundParameters.Remove("PackageName") | Out-Null

    $record = Start-Record 'localhost'
    try {
        Invoke-ChocolateyBoxstarter @PSBoundParameters
    }

Answer 17 · 2019-07-10T12:25:07.000Z

I thought I had this problem too, but then realized I was using an "Enhanced Session" with my Hyper-V guest. I use this by default (clipboard redirection FTW), and didn't even think to disable this.
As soon as I disabled it, the autologin functionality worked when the Install-Boxstarterpackage was passed with a correct -Credential parameter.
This makes sense, as the Enhanced Session in Hyper-V is basically an RDP session, and autologin would only be an interactive login.

Answer 18 · 2019-07-21T18:41:20.000Z

I've been trying to look at this for some time now and finally got to put some time into it and thought I'd pass on what I found. I've been using Hyper-V Vagrant environments to test this out. Before I started I made sure:

The box did not autologin on bootup;
I was using the Basic Session (note the comments from @lukebal above;
The box only had Chocolatey and Boxstarter installed (I used Chocolatey to install Boxstarter);
I was logged in as the Vagrant user (which is the same user I give Boxstarter the creds for);

I used a very simple script below to kick it off the reboots on each machine (I am also logged in

Remove-Item -Path 'c:\vagrant\reboot.flag' -ErrorAction SilentylContinue
$secpasswd = ConvertTo-SecureString "vagrant" -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential ("vagrant", $secpasswd)
Install-BoxstarterPackage -PackageName c:\vagrant\tests\boxstarter-test.ps1 -Credential $mycreds

c:\vagrant\tests\boxstarter-test.ps1 is just something that forces a reboot (once):

if (-not (test-path 'c:\vagrant\reboot.flag')) {
    New-item 'c:\vagrant\reboot.flag' -ItemType file
    Invoke-Reboot
}

choco install putty

I went all the way back to Server 2008R2 (PowerShell 3) just for belts and braces. Here are the results:

Windows Server 2008 R2 - Autologin?: Yes
Windows Server 2012 R2 - Autologin?: Yes
Windows Server 2016 - Autologin?: Yes
Windows Server 2019 (Version 1809 Build 17763.503) - Autologin?: Yes
Windows 10 Enterprise (Version 1709 Build 16299.125) - Autologin? : Yes
Windows 10 Enterprise (Version 1803 Build 17134.1) - Autologin?: Yes
Windows 10 Enterprise (Version 1809 Build 17763.1) - Autlogin?: Yes
Windows 10 Enterprise (Version 1903 Build 18362.239) - Autologin?: Yes

So from the point of view of giving Boxstarter the credentials of the currently logged in user and getting it to reboot into and auto login, I can't reproduce the issue.

One thing to note is that Hyper-V will default to opening an Enhanced Session on OS's that have Integration Services installed (from memory that is Server 2012 R2 onwards) and this is like an RDP session so is not auto logged in. What you need to do is make sure you are checking the Basic Sessions (which is effectively the console session). Some people above have mentioned when they log in Boxstarter is already running and this sounds like this is what is happening? I don't want to teach people to suck eggs but I just wanted to make sure it was clear.

Answer 19 · 2019-07-21T20:03:02.000Z

@9denis Invoke-Locally does only provide the option to specify a password. It then calls Invoke-ChocolateyBoxstarter and the parameters for that only accept a password. Invoke-Boxstarter is then called and again there is no username parameter, only password. So from all of that it looks like Boxstarter, by design, only uses the currently logged on account for autologin.

I am happy to br proven wrong as I'm only looking at the code. Is there anything that says otherwise?

Answer 20 · 2019-10-07T05:27:42.000Z

I've run a few of the scripts from https://github.com/microsoft/windows-dev-box-setup-scripts onto a Server 2016 a Windows 10 1903 Hyper-V Vagrant box and cannot duplicate this issue. When logged in as a Basic Session the boxes reboot when they should and log back in again (over multiple reboots depending on the script).

To reiterate what has been said in previous comments, when connecting to Hyper-V you must connect as a Basic Session for the box to autologin and you to see it. If you use an Enhanced Session you are basically using RDP to the box so it will autologin and run the script but you won't see it until you login yourself.

So I cannot reproduce this issue. As there has been no update from anybody else on this issue after my last comment I'm going to go ahead and close this. If there is anymore info on this in future I'm happy to open it again.

Answer 21 · 2019-10-22T08:57:52.000Z

Thank you @lukebal after i changed Hyper-V settings to "Basic Session" and starting the virtual machine with the administrator account, the autologin with the given Credentials worked. I'm happy too! This problem costed me really lots of time.

Actually I had the problem only with VM. On a real machine boxstarter worked with no problem.