Still doing autologin after Boxstarter has finished

Apr 14, 2014 at 1:39 PM
Hi there!

I'm running a Boxstarter package and everything works fine except autologin is still active after Boxstarter is finished.

The end of boxstarter.log:
[2014-04-03T15:31:55.8030002+02:00:::PID 3696] Finished installing 'MyPackage' and dependencies - if errors not shown in console, none detected. Check log for errors if unsure.
[2014-04-03T15:31:55.8480002+02:00:::PID 3696] Boxstarter: Exit Code: 0
[2014-04-03T15:31:55.8570002+02:00:::PID 3696] ++ Boxstarter finished Calling Chocolatey to install MyPackage. This may take several minutes to complete... 00:15:25.8705794
[2014-04-03T15:31:55.9060002+02:00:::PID 3696] Boxstarter: Enabling Automatic Updates from Windows Update
[2014-04-03T15:31:55.9720002+02:00:::PID 3696] Boxstarter: Starting Configuration Manager Service
[2014-04-03T15:31:57.4390002+02:00:::PID 3696] Boxstarter: Enabling UAC
[2014-04-03T15:32:06.8670002+02:00:::PID 3696] + Boxstarter finished Installation session. 00:16:42.2013221

Any idea what may be causing this?

Using Boxstarter 2.3.24

Apr 14, 2014 at 3:12 PM
Hmm. That not good.

Did Boxstarter restart the computer at all? After the boxstarter run, could yoy enter:
And reply with the output?

Apr 16, 2014 at 9:16 AM
Edited Apr 16, 2014 at 12:00 PM
Sorry for the delay. Boxstarter did restart the computer but unfortunately I can't type "$boxstarter" because the command window is closed when the scripts are finished ("Hit ENTER to exit")

I think the problem has to do with how I've written the script. I'm doing a couple of installations using just powershell, not Chocolatey. Could encapsulating these installations into Chocolatey packages solve the issue?

Update I could reproduce the problem when installing a much simpler Boxstarter package which only does:
try {
    Update-ExecutionPolicy Unrestricted
    Set-ExplorerOptions -showHidenFilesFoldersDrives -showProtectedOSFiles -showFileExtensions
    Set-ItemProperty -path 'HKCU:\Console' -name QuickEdit -value 1
    cinstm Firefox
    cinstm fiddler
    cinstm TortoiseSVN -version 1.7.12
    cinst svn -version 1.7.9
    cinstm git
    cinstm psget
    cinstm greenshot
    cinstm notepadplusplus.install
    cinstm nuget.commandline
    cinstm 7zip
    cinstm VirtualCloneDrive
    cinstm windirstat
    cinstm putty
    cinstm curl
    cinstm filezilla
    cinstm GoogleChrome
    Write-ChocolateySuccess 'MyPackage'
} catch {
  Write-ChocolateyFailure 'MyPackage' $($_.Exception.Message)
Apr 16, 2014 at 9:23 AM
Edited Apr 16, 2014 at 9:38 AM
I was able to run the scritp again and this time I could do:
PS C:\WINDOWS\system32> $boxstarter
Name                Value
----                -----
Log                 C:\Users\darol\AppData\Local\Boxstarter\boxstarter.log
ChocolateyBin       C:\chocolatey\bin
SuppressLogging     False
NoPassword          False
Package             {MyPackage}
RebootOk            True
ProgramFiles86      C:\Program Files (x86)
LocalRepo           \\secc108\it\SwDevelopmentApps\ToolKits\DotNet\Boxstarter\BuildPackages
AutologedOn         False
IsRebooting         False
BaseDir             \\secc108\it\SwDevelopmentApps\ToolKits\DotNet\Boxstarter
Apr 19, 2014 at 1:10 AM
I just pushed a new release with some small bug fixes and included some extra logging to help troubleshoot this. If you have a chance to reproduce with the latest version 2.4.12, please provide the log. Thanks!
May 16, 2014 at 11:35 AM
Hi Matt!

As I'm in the same org as @welinder I just want to mention that the team has worked around the problem by disabling Auto reboot in the package and they have moved on to higher prioritize tasks...

However, we have an enterprise packaging solution intended more for business end users rather than developers and I think that this packaging solution based on Microsoft SSCM might create a reboot conflict with boxstarter.

So my theory is that when a machine is recently reinstalled with the SSCM solution it has a number of pending reboots before the machine is "reboot-stable". If our script is executed during this period it gets stuck in this autologin state.

However, I don't have the time atm to test this theory but I wanted to let you know. I know there is a way to detect a pending system reboot in boxstarter but I'm not sure how we should include that into our script. Any ideas?

Regards, Daniel
May 16, 2014 at 12:10 PM

If I have understood you correctly, I think what you are looking for is this:
if (Test-PendingReboot) { Invoke-Reboot }
You could use this approach, similar to what is shown here:

To do an explicit Test for a Pending Reboot at different points in your script, in addition to the checks that Boxstarter does.

May 16, 2014 at 3:36 PM
Just wanted to chime in, as I have encountered this same problem. I'm setting up developer machines with VS 2012, 2013, SQL 2008 etc. and the install needs multiple restarts so there is no way around having Auto Reboot.

Gep13: According to my experience the problem happens also when Invoke-Reboot is used manually. The BoxStarter package finishes but next time someone reboots the machine, the user that ran the install is auto logged on automatically. I will have to check with the very latest version of Boxstarter to see if this isn't still the case.

8DH: I'm also in an environment where bot SSCM and other solutions are used to maintain the PCs and had a similar theory, that the environment was in a dirty state. I was also been experiencing problems with policy scripts that created faulty entries on each logon in the PendingFileRenameOperations registry key that Boxstarter detects as a pending reboot, so I created a clean testing environment outside of the domain but still got this same behavior.

Regards, Kristinn
Jun 22, 2014 at 6:47 AM
Sorry for chiming in so late. SCCM doe indeed introduce additional reboot vecotors but I doubt it is to blame for a machine being placed in a perpetual auto login state. One of the things Boxstarter checks for when detecting a pending reboot is the state of the SCCM client if installed.

From what I can tell, the only scenario to cause a state where the machine continues to auto login even after the boxstarter run is if something cause boxstarter to prematurely terminate and therefore fail to cleanup the auto login reg keys. This is in a finally block but it could certainly be missed if a user "ctrl+C"'s out of the boxstarter process, the machine is restarted from something other than Boxstarter (maybe SCCM???) or if the console window is closed.

One way Boxstarter could get around this is to keep auto login turned off and only turn it on just before it actually performs the reboot. This is trickier than it seems. This means I need to stash the login password somewhere until the reboot. The login password and treated like a hot potato by boxstarter for security purposes. I dont want to keep it in memory so I stash it in LSA Private data and null boxsarter's ref asap.

Of course it is questionable which is the worse security issue, the fact that auto login remains on or a malicious package author hijacking the password. I think an approach is possible that avoids both and will make this a high priority for the next feature release.
Sep 3, 2014 at 10:43 AM
Just released 2.4.88 which should address autologin not being turned off after a boxstarter run. Note that Boxstarter saves the autologin state of the machine before making changes and then reverts back to that state wen finished. Therefore if a machine is purposely set to auto login it will remain in that state after boxstarter is done but for the vast majority of machines that do not autologin, boxstarter should disable autologin upon completion.