views:

1014

answers:

4

OK here is my issue:

I am trying to run a script remotely on a server.

I am an administrator on both boxes, firewall exceptions are in place, remote admin is enabled, and everything else looks good that i can see.

invoke-command -ComputerName $ComputerName -ScriptBlock `
{
    cd C:\Windows\System32\inetsrv\; 
    ./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files>
}

I keep getting the following error in return

ERROR ( hresult:80070005, message:Failed to commit configuration changes. Access is denied.

The server it is trying to run on is a server 2k8 R2 box and I am thinking the issue is a UAC problem. Is there anyway to get this to run as administrator without having to click yes on a UAC box?

This piece of code will eventually become a script that will have to be completely automated.

Any help would be greatly appreciated.

A: 

Is there anyway to get this to run as administrator without having to click yes on a UAC box?

If this were possible it would entirely defeat the point of UAC.

Thus, it would appear your only real solution is to disable UAC on the box.

Anon.
Unfortunately Disabling UAC is not an option since it will be on high visibility servers. Hopefully someone can figure out a solution or workaround. Maybe I am just doing something wrong.
Tim
The other alternative would be to have whatever launches these scripts run elevated - then it can spawn other elevated processes without requiring another UAC confirmation.
Anon.
The only question i have with that is will it carry over remotely. This script will run different commands on multiple servers from a management server. So Server A (mgmt) runs commands remotely on servers 1, 2, and 3. If the Process is running as elevated on Server A is it going to run elevated on Servers 1, 2, and 3?
Tim
A: 

This seems to indicate that you need to ensure you are a local admin on the remote machine (although admittedly this is for WMI specifically). According to this you can change a registry key to stop UAC applying to remote logons for administrators (search for LocalAccountTokenFilterPolicy). That shouldn't disable UAC just not filter the token if you use powershell/WMI remotely with an administrator account.

tyranid
+1  A: 

OK. After some research and testing I figured out the issue. After disabling UAC and the firewall and the script still not working I dug a little deeper and discovered that the main issue was the way invoke-command runs the commands. it uses the credentials of the person running the script to authenticate to the server then tries to use another account to run the permissions or lowers the privileges of the user so that certain commands cannot be run.

I added the -Credentials switch to the invoke command and everything is working great now. Corrected code sample below:

$user = New-Object Management.Automation.PSCredential("$UserName", $securePassword)
invoke-command -ComputerName $ComputerName -Credential $user -ScriptBlock ` 
{ 
    cd C:\Windows\System32\inetsrv\;  
    ./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files> 
} 
Tim
A: 

Set the EnableLUA DWORD value in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 0 and reboot.

this will disable UAC without a problem, i would do it to all your users, with or without permission is up to you, because the vista UAC is so horrid that i do believe the less people that have it on the better (in vista only) it is now better in win7.

have fun with my registry trick :)

works in win7 as well, let me know how you got along with it.

it turns out stackoverflow is censoring comments that show how ti disable UAC as my post/thread with above answer from a diligent answerer was removed.

Erx_VB.NExT.Coder