Do all startup scripts requiring administrator privileges also invoke the UAC prompt?

Win 8.1 pro, Hyper-V

Hi Scripting Guys,

Situation:

Hyper-V is not starting a VM automatically even though in settings it is set for "Always start this virtual machine automatically".

Observations/what I've tried:

If I cold boot, the VM doesn't start
If I warm boot (restart), the VM starts
If after a cold boot I restart VMMS via services or command line, the VM starts

I tried to use a Delayed Start for VMMS, but it doesn't seem to be a service that can be delayed.

To date, none of the normal Hyper-V forums seem to have a suggestion for this problem.

What I want to try:

I'd like to setup a script in the Local Group Policy Editor to run on startup to see if 'manually' starting the service at a later point in the boot cycle will result in VMMS properly starting the VM automatically.

Problem:

"net start VMMS" is a command that requires administrator privileges.

If I understand correctly, the UAC prompt always shows up for pretty much any script that calls for an administrator level command such as 'net start' and I understand why this is by design and that if one is purposely running such a script one can always choose to Run As Administrator.  But during startup that's not the case.  Are there any exceptions to the UAC rule for the Local Group Policy Editor which is designed to run during startup, or is the UAC rule present even then?

Thanks.


  • Edited by Alan Wheeler 15 hours 29 minutes ago updated text
July 31st, 2015 10:43am

As a band-aid to the root question (why it doesn't always start), you could use the task scheduler to create a scheduled task that runs as administrator (this is "run with highest privileges" option) with a delay after bootup.

But this isn't a scripting question or problem, in any case.

Free Windows Admin Tool Kit Click here and download it now
July 31st, 2015 10:54am

Hi Bill,

Thanks for your response.  I'm sorry for the misdirection.  I didn't intend for you to answer the issue about Hyper-V, though I will look into your suggestion.  I re-typed above to put the focus on the problem I'm asking about.

The reason I posted here was to find out about the script I wanted to write, but it seems to me I can't really make that work automatically because of UAC, although I thought there might be a scripting way to do that since it is intended as a startup script.  Without being a scripting expert I wouldn't know if there are subtle differences in how startup scripts might be written so that the script flows past the UAC in this case.  That's why I posted here.

July 31st, 2015 11:46am

You can't really make what work automatically because of UAC?

If you create a scheduled task with "run with highest privileges", this runs as administrator and will not display the UAC prompt (since you, the administrator, are creating the task and telling it to run as administrator).

But again: This is a task scheduler/security-related question, not a scripting question.

Free Windows Admin Tool Kit Click here and download it now
July 31st, 2015 11:53am

You can't really make what work automatically because of UAC?

The script I wanted to write to put in the group policy editor as a way of trying to debug my situation.

I'm sorry we seem to be miscommunicating; I wasn't referring to your idea about using the task scheduler to run the task.  I understand that would have nothing to do with UAC. 

Again my question on this forum relates to whether or not there is a way during startup in group policy - is there some other mechanism in that process - that might avoid UAC?  This would be a script, right?  I just thought there may be some nuance using scripts in the startup process that aren't immediately apparent to less-than-guru script writers.

This may all boil down to there is no location or timing in which a script runs that doesn't engage UAC, which is what the first post in this forum says.  I just thought since I'm not really manually running the script, but rather a process during startup is running it, that might be different than what that first post in the forum is speaking to.

Thanks.

July 31st, 2015 12:20pm

In other words, your question is a security question and has nothing to do with scripting per se (the same question would apply if you were running an executable rather than a script; this is why your question is not a scripting question).

I am suggesting a workaround - use a scheduled task rather than a script in the group policy editor.

Otherwise, your question is not about scripting but possibly about group policy, and perhaps even more fundamentally about Hyper-V and why it's not behaving as you expect.

Free Windows Admin Tool Kit Click here and download it now
July 31st, 2015 12:35pm

Thanks for your patience.  I get it now.

Even though I was thinking this is a scripting question because I want to run a script, my issue in running the script is not one of what code/commands/syntax I might write.  The real issue is security and nothing I write in a script will get around that.

Further, in this forum you are really looking for questions about how to write code/commands/syntax within a script file as opposed to systems issues such as group policy, security, and so on, unless they really were relevant to scripting such as changes in the location of the namespaces, etc.

I would say I'm sorry to have troubled you, but this exchange finally helped me better understand how to use this forum, which I'm sure I will do more of in the future - for the right reasons! :-)

BTW, your suggestion to use Task Scheduler did succeed without any permissions issues, but only when the task is run at log on.  It doesn't succeed at system start, which suggests to me there are too many things going on at boot and Hyper-V can't negotiate a clean startup.  This actually helped me run the test I was hoping to run by using a startup script.

If you would like to delete this post because it is off-topic, that's fine with me. But I appreciated you sticking with your point until I got it.

Best Regards,

July 31st, 2015 1:06pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics