How can we improve the SMA (K1000)?

UAC compatibility

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.

170 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Mark Rodee shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
completed  ·  Ken Galvin responded  · 

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:

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:


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Jason commented  ·   ·  Flag as inappropriate

    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

    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

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

    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

    if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )

    if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges)
    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

    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%" %*
    exit /B

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


    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

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

  • Cass commented  ·   ·  Flag as inappropriate

    HUGE P.I.T.A. Give me a break! Why is this such an evasive response with no resolution from Dell?

  • Dan Barr commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.


  • Dan Barr commented  ·   ·  Flag as inappropriate

    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.

  • Jon commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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 !

  • Sarah commented  ·   ·  Flag as inappropriate

    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!

  • Nate commented  ·   ·  Flag as inappropriate

    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.

  • Robert Hardy commented  ·   ·  Flag as inappropriate

    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.

  • Dan Barr commented  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base