• I followed the procedure for provisioning a worker with Administrator privs

• net localgroup Administrators does list my username

• If I attempt to use PowerShell to elevate, or if I right-click on the command prompt in the taskbar and click Run as Administrator, a new cmd window is opened, but I am never presented with an elevation prompt.

• If I try to install this file from that supposedly elevated prompt, I am presented with a dialog box that says:

You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator and then retry this installation.

• I am also not prompted for elevation if I try to launch the MSI from File Explorer.

Is UAC disabled or something?

(I could do this on a gecko-t-win10-64 worker without difficulty)

any ideas pete?

(In reply to Aaron Klotz [:aklotz] from comment #0)

• I followed the procedure for provisioning a worker with Administrator privs

• net localgroup Administrators does list my username

• If I attempt to use PowerShell to elevate, or if I right-click on the command prompt in the taskbar and click Run as Administrator, a new cmd window is opened, but I am never presented with an elevation prompt.

• If I try to install this file from that supposedly elevated prompt, I am presented with a dialog box that says:

You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator and then retry this installation.

That is strange since like you say, you are already a member of the Administrators group.

• I am also not prompted for elevation if I try to launch the MSI from File Explorer.

Is UAC disabled or something?

I'm not sure. You should be able to tell with this:
https://superuser.com/questions/192216/uac-status-from-command-line

(I could do this on a gecko-t-win10-64 worker without difficulty)

If you are still stuck, can you link to the task?

EnableLUA is 0, so UAC is off. When I go into the Control Panel, examine my user, and go to Change Your Account Type, it shows my account as a Standard user. I do not have permission to change the account type to Administrator.

This is my task

Hi Aaron,

I see what the problem is, I think we'll need to update the instructions.

When UAC is disabled, the command shell needs to be launched by the worker so that the login session has an auth token with the required permissions. The worker creates a task user, logs in as that user, and then waits for a task to come in. When it receives the interactive task you've created, it adds the task user to the Administrators group and then creates a new auth token which reflects this new group membership. However, the interactive desktop session was created prior to the group membership being applied, and therefore when you RDP into the interactive desktop session, it still has the auth token from the original login, which didn't have the permission. This explains why the commands you run to test membership of the Administrators group suggest your user is in the Administrators group, however, when using the auth token for the desktop session, that membership is not present (since group memebership is statically assigned in the auth token).

The way to overcome this (which admittedly was not included in the guide) is to launch a command shell from the interactive task, which will then use the new auth token which has the group membership. I tested this just now, by modifying the interactive task command to just start cmd.exe. That opens a command shell using a suitable auth token. From there I could launch powershell, download the .msi file from comment 0 and install it without problems. I could reproduce your issue when launching my own command shell.

Therefore I think the only change you need is change your task command to start cmd.exe, and install the msi from there.

Good luck, let us know if you get stuck! I'll attach a screenshot of what I did.

This works, but once I have installed that MSI, I still want to be able to manually run the original command that ran the tests. I tried changing the command: section to a list of both commands like so:

payload:
  command:
    - start cmd.exe
    - >-
      C:/mozilla-build/python3/python3.exe run-task --
      c:\mozilla-build\python\python.exe -u
      mozharness\scripts\desktop_unittest.py --cfg
      mozharness\configs\unittests\win_unittest.py --xpcshell-suite=xpcshell
      --setpref=media.peerconnection.mtransport_process=false
      --setpref=network.process.enabled=false --download-symbols true
      --total-chunk=2 --this-chunk=2

But it only ran the first command and did not provide anything that would give me the ability to run the second command. Thoughts (keeping in mind that I am not a TaskCluster expert)?

I got this running by taking the original command and running it manually. Still, this seems to me that it should be something that is auto-generated, no?

(In reply to Aaron Klotz [:aklotz] from comment #7)

I got this running by taking the original command and running it manually. Still, this seems to me that it should be something that is auto-generated, no?

The user experience for loaners on windows is suboptimal at the moment. We have work to do on the tools site to make it simpler/consistent with the linux user experience (bug 1368961), and we probably have some work to do in the gecko codebase (/taskcluster subdirectory) to make it easier to step through tasks, like we also have with linux (I'm not sure if we have a bug for that yet).

I'm glad you got it working, despite the difficulties on the way, and hopefully these things will be easier in future.

Note, the task commands exist as batch scripts in Z:\ folder:

Z:\task_........\command_000000_wrapper.bat
Z:\task_........\command_000001_wrapper.bat
Z:\task_........\command_000002_wrapper.bat
....

Therefore if you want to run an individual task command, you can just run one of these pregenerated batch scripts. I think when we auto-generate the task definition in the tools site, we'll be able to open a terminal that explains information like this in a "message of the day" type format above the prompt, or something similar, but indeed there is some work to do to make this user experience more intuitive.

Please let me know if you have any other open issues, and feel free to update the wiki page if you see gaps there that could be better explained.

Many thanks!

There was only one batch file and it was for command_000000_wrapper.bat; no additional batch files were created.

Ah, in that case I suspect either the first command did not complete (or only one command was specified).

Explanation: the wrapper scripts are created as the task iterates through the commands since the worker only knows what the environment variables and working directory should be for command n+1 when command n has completed. The wrapper scripts set the environment and working directory appropriate for the command, and then run it. Therefore these batch files are generated on-the-fly as the worker iterates through execution of the commands, when it knows what the environment and working directory for each command should be when the previous command completes.

From the start docs I thought that start would return immediately unless /wait was specified, so I'm surprised, if start cmd was the first command, that it didn't return immediately. I was hoping it would simply open a command shell, and then the task would continue to run. It sounds like that wasn't the case.

Like I say, long term, we should probably get a wizard that can step you through the commands of an interactive task, but unfortunately for now it is a little clunky.

Another option I can think of is having the first and last command as start cmd, with everything else sandwiched in between. The first start cmd should open a shell, and you can install everything you want to on the system. When you exit that shell, the subsequent task commands should run. At the end, it can open a new shell for you with the elevated auth token, so you can choose to rerun any steps, or do any troubleshooting you need. I think the key is just to exit the command prompt when you've done what you need to, in order that the other task commands can continue to run.

Let me know how you get on!

(In reply to Pete Moore [:pmoore][:pete] from comment #10)

From the start docs I thought that start would return immediately unless /wait was specified, so I'm surprised, if start cmd was the first command, that it didn't return immediately. I was hoping it would simply open a command shell, and then the task would continue to run. It sounds like that wasn't the case.

Does Taskcluster use job objects to execute the commands? If so, that would explain why start didn't work even though it wasn't waiting: the instance of cmd would still be inside the job object, so the job would never be considered to have completed. For this to work, we need to be able to start a child process that can be broken away from the job.

Operating under that theory, I downloaded PSTools from Sysinternals and used its psexec command to start cmd. I was finally able to get this stuff to run the way that I need it to.

For reference, here is how to add it to the task configuration such that it will automagically run ahead of the tests:

  command:
    - wget https://download.sysinternals.com/files/PSTools.zip
    - unzip PSTools.zip -d pstools
    - start pstools\psexec.exe -accepteula -nobanner -d -i -h cmd.exe
    - >-
      C:/mozilla-build/python3/python3.exe run-task --
      c:\mozilla-build\python\python.exe -u
      mozharness\scripts\desktop_unittest.py --cfg
      mozharness\configs\unittests\win_unittest.py --xpcshell-suite=xpcshell
      --setpref=media.peerconnection.mtransport_process=false
      --setpref=network.process.enabled=false --download-symbols true
      --total-chunk=2 --this-chunk=2

A breakdown of the psexec command line:

• We still use start because psexec sets its return code to whatever it got from starting the child process. In my case, this value was 1, which TaskCluster was interpreting as a command failure (even though psexec had actually worked). Using start gives us a successful return code.
• We need to accept the EULA so that psexec does not prompt or block for user input;
• -d tells psexec not to wait on the child process;
• -i ensures that the child process is run in the console session;
• -h ensures that the child process is run as Adminstrator.

Like I say, long term, we should probably get a wizard that can step you through the commands of an interactive task, but unfortunately for now it is a little clunky.

Yes please. For those of us who are working on Windows-specific issues, we have no choice but to go through this every time we need a loaner.

Another option I can think of is having the first and last command as start cmd, with everything else sandwiched in between. The first start cmd should open a shell, and you can install everything you want to on the system. When you exit that shell, the subsequent task commands should run. At the end, it can open a new shell for you with the elevated auth token, so you can choose to rerun any steps, or do any troubleshooting you need. I think the key is just to exit the command prompt when you've done what you need to, in order that the other task commands can continue to run.

I tried this, and it worked until the command running the tests aborted (due to the very timeouts that I am trying to investigate), and the second start cmd was never run. Presumably because the test command aborted, TaskCluster did not proceed to run the next command which was the second start cmd. But my psexec solution works nicely enough that this becomes a moot point.

FWIW I think it would be very handy to include PSTools as part of the base image, much like Process Explorer and Process Monitor already are.

Thanks Aaron.

I'll reopen this bug as there are some open points, and look to digest the information you've provided into other new/existing bugs before closing this bug again, as you've provided a lot of useful context here that we shouldn't lose / forget about. First I'll have some discussions with others about how we should tackle some of these issues, and report back here.

Not actively working on this right now.