KACE agent fails install when UAC (User Access Control) is running with Windows 7. Disabling for the install only is a nasty hack and should be fixed.
I separated the two different requests contained in this thread.
1. Installing K1000 Agent using when UAC is on:
Installing agent using GPO will eliminate the need to disable UAC on the end point. See Using the K1000 GPO Provisioning Tool for Agent Deployment: https://support.software.dell.com/k1000-systems-management-appliance/kb/133776
2. Bypass UAC while running scripts:
Running scripts as System does not involve UAC. If run as User, UAC applies. That case is still under consideration for a future release.
Please see Bypass UAC while running scripts: http://kace.uservoice.com/forums/82699-k1000/suggestions/11691015-bypass-uac-while-running-scripts
Some issues we seen with UAC in our Org, and how I resolved them..
1st. In our Org, we no longer use the main Domain account (which every PC has the root administrator account renamed to in GP) so when we set up new computers we log in with a domain account, which by default DOES NOT have the same elevated UAC level as the main root administrator account on a PC...
1 way to get around this is to change a local GP setting or temporarilly change it, which we do in the script by editing a registry value:
This allows no UAC popup to "allow" something to run...without needing to click OK (no popup)
2nd. when we execute our scripts within the k1000 script, we elevate the admin access like this...
:: Elevate.cmd - Version 4
:: Automatically check & get admin rights
for %%k in (%0) do set batchName=%%~nk
NET FILE 1>NUL 2>NUL
if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )
if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges)
ECHO Invoking UAC for Privilege Escalation
ECHO Set UAC = CreateObject^("Shell.Application"^) > "%vbsGetPrivileges%"
ECHO args = "ELEV " >> "%vbsGetPrivileges%"
ECHO For Each strArg in WScript.Arguments >> "%vbsGetPrivileges%"
ECHO args = args ^& strArg ^& " " >> "%vbsGetPrivileges%"
ECHO Next >> "%vbsGetPrivileges%"
if '%cmdInvoke%'=='1' goto InvokeCmd
ECHO UAC.ShellExecute "!batchPath!", args, "", "runas", 1 >> "%vbsGetPrivileges%"
ECHO args = "/c """ + "!batchPath!" + """ " + args >> "%vbsGetPrivileges%"
ECHO UAC.ShellExecute "%SystemRoot%\%winSysFolder%\cmd.exe", args, "", "runas", 1 >> "%vbsGetPrivileges%"
Start /B /Wait "%SystemRoot%\%winSysFolder%\WScript.exe" "%vbsGetPrivileges%" %*
setlocal & cd /d %~dp0
if '%1'=='ELEV' (del "%vbsGetPrivileges%" 1>nul 2>nul & shift /1)
start /B /wait DriveSetupAllInOne.exe
Then at the end of the k1000 script, we reset the registry key to turn UAC popup back how it was:
This process has allowed us to setup our new PC installs alot faster while logged in as domain admins, but that are not the highest level admin as the main root administrator account on the pc..
Hope it helps anyone else with UAC issues..
And as far as installing the agent, use GP as it works great...
HUGE P.I.T.A. Give me a break! Why is this such an evasive response with no resolution from Dell?
UAC elevation when using an account other than the built-in Administrator or Local System is still an issue, however I am reducing my votes on this from 3 to 1 because for most use cases where we need network share access during a script, Local System does work if we give the computer accounts read access to the needed share. BUT, there may always come a time when we need a specific non-system domain account to run a script, and proper UAC elevation may be needed.
Christopher Little commented
I am doing a POC for Kace to replace our existing IBM Endpoint Manager set up and this stopped me dead in my tracks. I'll have to use the existing product to deploy the new client, which is ridiculous. IBM's client deployment tool doesn't have this issue. Four OS releases in, there is no excuse for not properly handling UAC in 2015.
Martin Wichert commented
for us the Distributing of KACE Agent is not a Problem but script executing (e.g. batch) requests elevation on local system account as well. Disabling UAC is not an option in our Enterprise environment. Bypass UAC if KACE is already installed would be perfect. We see similar problems like Dan Barr. Scripts execution if a User Account is in Administrator group.
We do not see UAC elevation issues when scripts run as Local System, because Local System is exempt from UAC.
The issue is when we have scripts which need to access a network share during execution, and need to run them under an AD service account. The service account is a member of local Administrators on the PCs, but the script process is not launched into an elevated session, so the steps which require admin access fail. Turning off UAC is NOT an option. Since the K1000 agent service itself runs as Local System, it should have no issue spawning new elevated processes. We have seen numerous other products which do just that without issue. This is by far the single biggest pain point we have with the K1000.
Martin Wichert commented
It is still a pain for us when executing scripts, making registry changes. A solution would be great
We have been having issues with the CIS benchmarks (UAC) and our Kace too, It would be nice if MI and Scripts could be ran with Elevated permissions.
Robin Coombe commented
You can get around the UAC issue IF you know the local Administrator password on the local machines.
Under the provisioning settings, use:
Domain: leave blank
And it works !
We are implementing KACE and this is a huge pain. This should be reviewed.
I am hoping that KACE is taking a good look at this. Disabling UAC in a government agency following FDCC is not an option, which removes the option of using the appliance. Ridiculous! I have been fighting with the .bat file, using a 3rd party tool (what a waste of $$), and GPO install isn't supported by MS! This is something I wish I had known about the product before sinking thousands of dollars into it!
Any update on the "under review" status of this issue? We've upgraded to Kace 6.0 an we really like the Active Directory integration that allows us to discover computers that may not have the Kace Agent installed for some reason. Having the ability to Provision to those computers without hacking in and disabling the UAC, would be great. As it sits, our helpdesk staff will just need to manually RDP to the computer and install the agent.
If you don't want to disable UAC, you can always deploy the agent with GPO: http://www.kace.com/support/resources/kb/solutiondetail?sol=111244
Robert Hardy commented
KACE purports to be a security product. It is truly sad when the only solution offered by a security product is to turn off security. What throws salt in the wound is when that bug is treated as an "this might be considered for future releases" enhancement request instead of the critical security bug this really is.
And not just for agent deployment, but also any script running under a service account which is a local Administrator. We have some scripts that need to pull resources from network shares, but when running as a domain account which is in the local Administrators group, they fail because the KACE Agent does not elevate properly. Our only recourse currently is to use the actual built-in Administrator account which bypasses UAC, and have a matching account on the file server. This is far from idea. Disabling UAC is not an option for us.
This is still not fixed.