VBox doens't handle the user account correctly on Windows Hosts

[Romuald Tisserand]

Host : Windows 7 Pro 64 bits

Context : VBox is called by a PowerShell script. At development time, this script is run by me, manually. At production time, this script is run by a scheduled task or through an ASP.Net web interface.

I wrote a little PowerShell script to illustrate the defect:

"Windows 1: $([Environment]::UserDomainName)\$([Environment]::UserName)" | Out-File "out.txt"
"Windows 2: $([Security.Principal.WindowsIdentity]::GetCurrent().Name)" | Out-File "out.txt" -Append

$vBox = New-Object -ComObject VirtualBox.VirtualBox
"VirtualBox: $($vBox.HomeFolder)" | Out-File "out.txt" -Append

If the script is run manually by me, the result is:

Windows 1: <my domain>\robot
Windows 2: <my domain>\robot
VirtualBox: C:\Users\robot/.VirtualBox

To me, this is the CORRECT result.

If the script is called through the computer ASP.Net web interface, the result is:

Windows 1: <my domain>\robot
Windows 2: <my domain>\robot
VirtualBox: C:\Windows\system32\config\systemprofile/.VirtualBox

Here, the ASP.Net engine is setup with impersonation to enforce the user with the "robot", as shown with the 2 first lines, this works, so the VBox result is WRONG.

If the script is run through a scheduled task, the result is:

Windows 1: <my domain>\Robot
Windows 2: <my domain>\Robot
VirtualBox: 

Here again, the scheduled tasks enforces the user account to "robot", so here again, the VBox result is also WRONG.

I've found a tricky workaround to run from the web interface by backuping/copying VBox files from/to the robot/systemprofile accounts, so yes, really tricky.

For the scheduled task, as VBox returns nothing, I have no solution, until to hope to see this defect fixed.

Thanks.

[Romuald Tisserand]

Same defect on VBox 4.0.0

[Sam Kenny]

I have had the same problem with impersonation on Windows 7. It turns out that environment variables are not guaranteed to exist in scheduled tasks.

The problem lies in RTPathUserHome() in path-win.cpp which checks the HOME, USERPROFILE and HOMEDRIVE/HOMEPATH environment variables. All of these do not exist in this mode of running; apparently the preferred way to get the user directory is to use SHGetFolderPath(CSIDL_PROFILE) (a bit like RTPathUserDocuments() does I imagine). Interestingly, Microsoft seems to indicate that application folders should not be created there.

Alternatively, explicitly adding a VBOX_USER_HOME environment variable in system (not user) environment variables pointing to a known location or via a script before execution of VBox will work around this.