Hello,
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:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Name:ConsentPromptBehaviorAdmin
Type:REG_SZ
Data:00000000

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...

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
@echo off
CLS

::::::::::::::::::::::::::::::::::::::::::::
:: Elevate.cmd - Version 4
:: Automatically check & get admin rights
::::::::::::::::::::::::::::::::::::::::::::

:init
setlocal DisableDelayedExpansion
set cmdInvoke=1
set winSysFolder=System32
set "batchPath=%~0"
for %%k in (%0) do set batchName=%%~nk
set "vbsGetPrivileges=%temp%\OEgetPriv_%batchName%.vbs"
setlocal EnableDelayedExpansion

:checkPrivileges
NET FILE 1>NUL 2>NUL
if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )

:getPrivileges
if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges)
ECHO.
ECHO **************************************
ECHO Invoking UAC for Privilege Escalation
ECHO **************************************

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%"
goto ExecElevation

:InvokeCmd
ECHO args = "/c """ + "!batchPath!" + """ " + args >> "%vbsGetPrivileges%"
ECHO UAC.ShellExecute "%SystemRoot%\%winSysFolder%\cmd.exe", args, "", "runas", 1 >> "%vbsGetPrivileges%"

:ExecElevation
Start /B /Wait "%SystemRoot%\%winSysFolder%\WScript.exe" "%vbsGetPrivileges%" %*
exit /B

:gotPrivileges
setlocal & cd /d %~dp0
if '%1'=='ELEV' (del "%vbsGetPrivileges%" 1>nul 2>nul & shift /1)

::::::::::::::::::::::::::::
::START
::::::::::::::::::::::::::::

cd C:\Files\laptop-install\CDK

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:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Name:ConsentPromptBehaviorAdmin
Type:REG_SZ
Data:00000005

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.

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.

Hello Kevin,

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.

Thanks!

Hi Kevin,
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.

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.

You can get around the UAC issue IF you know the local Administrator password on the local machines.

Under the provisioning settings, use:
Username: Administrator
Domain: leave blank
Password: password

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

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.