I have a job configured with two tasks:

- Install Windows Updates
- Restart

The Install works fine but often requires a restart (as many windows update do). The restart task is failing with:

Exception in Task: Error occured:Privilege not held.

What is necessary to reboot the machine?

The actual Reboot/Restart is made through WMI. So you need to have WMI access with that user.

---

What's required to have WMI access? How do you set that? This is a local user on a terminal server.

You probably need an admin user. You can see WMI properties (and security) under Computer management. Add this user as a Credential and select it itn the Task.

---

The user is definately in the Administrator group. I'll set the Credential on the task and test it this evening. Thanks.

Since you're running it locally, and its using WMI, its getting that Privelage Not Held. This is apparently default behavior for WMI reboots.

From a PowerShell blog, where they use powershell to do a WMI executed reboot of the server in which the script is running on locally:

You will get a Privilege Not Held from Powershell WMI if you try to reboot a server on which your script/WMI call is executing.

You can see the same result if you try this in powershell:

$server = get-wmiobject -class Win32_OperatingSystem
$server.reboot()

However, if you specify a DIFFERENT computer (remote) you can do this without issue (as long as your ID has perms):

$server = get-wmiobject -computer SOMEOTHERCOMPUTER -class Win32_OperatingSystem
$server.reboot()

Brian

Henrik, you may want to add some extra stuff to your reboot/restart code if someone is trying to reboot the local system and using WMI:


Via Powershell, you can give the privelages (note 2nd line). This DOES work.


$server = get-wmiobject -class Win32_OperatingSystem
$server.PSBase.Scope.Options.EnablePrivileges = $True
$server.reboot()

Brian

We are always using WMI in our Task. I guess the other user is not using any Credential at all. Then WMI is called with default "Local System" which lacks some rights here by default.

Henrik, you may want to add some extra stuff to your reboot/restart code if someone is trying to reboot the local system and using WMI:


Via Powershell, you can give the privelages (note 2nd line). This DOES work.


$server = get-wmiobject -class Win32_OperatingSystem
$server.PSBase.Scope.Options.EnablePrivileges = $True
$server.reboot()

Brian

---

What method are you using to initiate the reboot via WMI when its the local VC computer/server? I'm a PowerShell Junkie and live in WMI :)

Brian

We are always using WMI in our Task. I guess the other user is not using any Credential at all. Then WMI is called with default "Local System" which lacks some rights here by default.

Henrik, you may want to add some extra stuff to your reboot/restart code if someone is trying to reboot the local system and using WMI:


Via Powershell, you can give the privelages (note 2nd line). This DOES work.


$server = get-wmiobject -class Win32_OperatingSystem
$server.PSBase.Scope.Options.EnablePrivileges = $True
$server.reboot()

Brian

We call this method: Win32Shutdown

What method are you using to initiate the reboot via WMI when its the local VC computer/server? I'm a PowerShell Junkie and live in WMI :)

Brian

We are always using WMI in our Task. I guess the other user is not using any Credential at all. Then WMI is called with default "Local System" which lacks some rights here by default.

Henrik, you may want to add some extra stuff to your reboot/restart code if someone is trying to reboot the local system and using WMI:


Via Powershell, you can give the privelages (note 2nd line). This DOES work.


$server = get-wmiobject -class Win32_OperatingSystem
$server.PSBase.Scope.Options.EnablePrivileges = $True
$server.reboot()

Brian

---

What language are you coding in? Got a snippit of code that would produce a reboot using said code?

Feel free to e-mail me, if you don't want it posted here.

Actually, regardless, You need to... when doing a restart task on the local system, use this option if calling WMI:

scope.Options.EnablePrivileges = True

Whatever syntax is appropriate for the language, thats needed.

Brian

PM:d you.

What language are you coding in? Got a snippit of code that would produce a reboot using said code?

Feel free to e-mail me, if you don't want it posted here.

Actually, regardless, You need to... when doing a restart task on the local system, use this option if calling WMI:

scope.Options.EnablePrivileges = True

Whatever syntax is appropriate for the language, thats needed.

Brian

---

Henrik is correct. I reviewed the .NET code they are using for VC and it (not suprised) is exactly the way it needs to be in order for it to work. Never had any doubts ;-)

To that end, I cannot get the local restart task to fail. It works 100% of the time when trying to reboot 'Local'. The scenarios below are what i've tried with success:

I tried running the VC service as the default LOCAL SYSTEM account (NT AUTHORITY\SYSTEM)
I tried running the VC service as my own ID (Domain Admin)
I tried running the VC service as a non-domain local user/admin on the server (2008) with no domain privelages.
I tried running the VC service as LOCAL SYSTEM and using my ID as a Credential for the task

Then I thought.. maybe UAC (User Account Control) might be messing with it, assuming its a 2008 server... So I set UAC back to 'default' instead of 'Never' (our standard). It still continued to work just fine, scenarios below:

I tried running the VC service as a non-domain local user/admin
I tried running the VC service as LOCAL SYSTEM.

I did run into trouble when I tried starting the service as a generic user (non admin) the service wouldn't even start. Not sure whats needed at a minimum, but its not likely the service is running under a plain/new user account that isn't admin.

I wonder what your local security policy is configured for. If you could give us the following information that'd be helpful:

1. What Operating System are you running?

2. What Version of VisualCron are you running?

3. Is the VisualCron Service running as LOCAL SYSTEM, or an Account you've created

4. If Account you've created, what groups is the ID a member of?

5. In Local Policy (run gpedit.msc) what users/groups have the "shutdown the system" and "force shutdown from a remote system" privileges?

The above settings can be found in 2008 if you expand "Computer Configuation"-->Windows Settings -->Security Settings -->Local Policies-->User Rights Assignment:


Brian

I set the Credential on the task to the administrative user that all the other tasks are also running as. This user is a local account in the Administrators group. The WMI permissions for the entire root namespace are enabled for the administrator group (by default).

The reboot still fails with the same message.


bbusse,

1. OS - Windows Terminal Server 2003 SP2 (32bit) (Not in a domain)
2. VC 6.1.7
3. Local System (with Interact with desktop)
4. Credential account (TaskAdmin) is in the Administrators and Users groups.
5. Local Security Policy (Local Policies > User Rights Assignment) both 'Force shutdown from a remote system' and 'Shut down the system' have Administrators group assigned.

I set the Credential on the task to the administrative user that all the other tasks are also running as. This user is a local account in the Administrators group. The WMI permissions for the entire root namespace are enabled for the administrator group (by default).

The reboot still fails with the same message.


bbusse,

1. OS - Windows Terminal Server 2003 SP2 (32bit) (Not in a domain)
2. VC 6.1.7
3. Local System (with Interact with desktop)
4. Credential account (TaskAdmin) is in the Administrators and Users groups.
5. Local Security Policy (Local Policies > User Rights Assignment) both 'Force shutdown from a remote system' and 'Shut down the system' have Administrators group assigned.

About the Credential. Have you checked "Local logon" and "Load profile"?

---

Yes.

I'm not in the office today to try it, but i know I don't have the 'allow service to interact with desktop' option selected for Local System (run as on the service). Maybe enabling that is causing odd behavior?

Brian

Any update or troubleshooting steps needed to figure this out? I still can't get my servers to reboot with the task.

Sorry, running out of ideas. There is some kind of permission problem. Try turning off UAC or similar. Or you could set the VIsualCron service to run as another user.

---