We have tests that require the Mozilla Maintenance Service to be installed. Rather than rely on some very ancient version being installed on the system, we should install the service as part of the test. I have no idea if we can do selective privilege escalation on Windows, but I'd really love it if we could find a way. Having tests that depend on this kind of system state is pretty shitty. Not to mention that we're not even testing the right version of the maintenance service code.

You'd need to do this first step ahead of time when setting up the test image to save the admin creds. Run this from a command prompt: runas /savecred /user:Administrator cmd You'll be prompted for admin password which will be saved in the user's credential store persistently. Now when testing you can run: runas /savecred /user:Administrator <path_to_maintenanceservice_installer.exe> during testing and the service will be installed using the creds that were previously saved. Does that give you what you need?

I'm adding this as a dependency of win32test since our Windows Server 2012 AWS VMs currently do not have a maintenance service installed. Instead of just installing an old service (which I agree is super shitty), I think it would make the most sense to get this bug fixed and get proper maintenance service testing working.

I haven't tested it, but it sounds like it would work. The main question now is where to put that code. It probably doesn't belong in the test harness, maybe in the mozharness script that runs the test... Brian, what do you think about this approach?

(In reply to Ben Hearsum [:bhearsum] from comment #0) > We have tests that require the Mozilla Maintenance Service to be installed. > Rather than rely on some very ancient version being installed on the system, > we should install the service as part of the test. I have no idea if we can > do selective privilege escalation on Windows, but I'd really love it if we > could find a way. Having tests that depend on this kind of system state is > pretty shitty. Not to mention that we're not even testing the right version > of the maintenance service code. We are testing the most recent version of the maintenance service. We're using the pre-installed maintenance service as a bootstrap to be able to install the new maintenance service only. No testing results depend on it, other than it being a bootstrap. If there is a bug introduced in a portion of the maintenance service code covered by tests, it will be caught. Generally there would be no point running tests automated if that wasn't the case.

In that case I'm going to remove this bug as a dependency of win32test.

Yeah, given that I don't really care about this bug. I think it would be better if these tests could run without a preexisting maintenance service, but it's not worth fixing this if that's the only benefit.

> Yeah, given that I don't really care about this bug. I think it would be better if these tests could run without a preexisting maintenance service Agreed, I didn't have other ideas at the time, but it could be re-visited one day to find out a new way to accomplish testing on windows without a bootstrap. Perhaps by creating a second non admin NT service binary (if that's even possible in HKCU!). For now, probably other bigger priorities though. Thanks for thinking of a possible potential problem though!