Multiple Boxstarter runs on a W2k16 operating system

[kirannhegde]

I recently ran into an issue using Boxstarter on a W2k16 operating system.
I logged into the console session of the system and initiated a Boxstarter run. Boxstarter started installing my choco packages and rebooted in between. This was expected. I had even opted for Autologon.
After some time, i RDP to this system. And i see that Boxstarter again starts executing in this new session as well. My expectation was that, Boxstarter should always execute only in the session where it was executed and not start executing in any session that's created on the system. So essentially, what happened was, i had 2 simulatenous BoxStarter sessions running on the system i.e one in the Console session that Boxstarter had used autologin to resume and one in the RDP session that i used to log into the system.
I think this causes some issues where a certain package was being reported as locked by another process. I am thinking that this particular package was being installed in the other console session, hence was being reported as locked in the current RDP session that i was connected to.

This in my opinion is a serious issue as users of the system might not really expect to connect to a console session most of the time.
Is this a known issue? if so, what is the suggested workaround here?

This is very easy to reproduce. I can reproduce it at will.

Kindly advice.

Regards,
Kiran Hegde

[mwrock]

Unfortunately there is no session isolation. Upon reboot, Boxstarter sets itself up to restart on login regardless of session.

[kirannhegde]

@mwrock Are there any suggested workarounds that i could use in my Boxstarter script? From your experience, do you know how this has been overcome?
This can be a real issue when developers set up their dev. environments on a server operating system.

I can implement this myself. However, i wanted some ideas on how i could do this.
Does windows keep track of what Powershell script is being executed across all sessions?
Other way could be to figure out the login times of the all the sessions on the system. If an existing session has a logon time earlier to the present session where you are logged in, abort the execution of the BoxStarter script.

What do you think of the above suggestions?
Do you foresee any issues with them?

Kindly advice.

[mwrock]

If you are trying to run boxstarter remotely or targeting a VM, the best way to do that is to use the -ComputerName and -Credentials args of Install-BoxstarterPackage. See Remote Installations on http://boxstarter.org/InstallingPackages. That will use a different technique to manage the boxstarter rerun. It basically drives the install from your local console and isolates it to that session.

[kirannhegde]

Hello @mwrock Is there a way to know that the script is running post a reboot? In our case, the powershell script is hosted on a server and is invoked by Install-BoxstarterPackage cmdlet. I want to know if this script is being run after a reboot or if it's running the first time. Do you have any ideas here?

[kirannhegde]

Hello @mwrock So the way i overcome this was by deleting the boxstarter-post-restart.bat file from my powershell script. If there are multiple sessions with the same user login, upon a reboot, the first session which executes my script would delete this file. This would mean that the file will be not accessible to any further user sessions with the same login. So far i have found this working. Do you foresee a problem with this approach?

[pauby]

There has been no update to this in quite some time and the initial issue is known behaviour of Boxstarter.