Software Deployment Question

Access Denied in WMI script when run from User Console Library

09/17/2014 4113 views
I have created an AutoIt program to allow users to add a network printer and added it as an install to the User Console Library so that it will run with Admin privileges. This program works perfectly when run locally, but produces an error when run from KACE:

Is there a difference between the KACE Agent's admin rights and typing admin credentials into the UAC?

Here is the function that is throwing up the error:
Func _AddPrinter($sPrinterName, $sDriverName, $sPortName, $sLocation = '', $sComment = '')
    $strComputer = "."
    $objWMIService = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" & $strComputer & "\root\cimv2")
    $objPrinter = $objWMIService.Get("Win32_Printer").SpawnInstance_
    If NOT IsObj($objPrinter) Then Return 0
    $objPrinter.DriverName = $sDriverName
    $objPrinter.PortName   = $sPortName
    $objPrinter.DeviceID   = $sPrinterName
    $objPrinter.Location   = $sLocation
    $objPrinter.Comment    = $sComment
    Return 1

Answer Summary:
Needed to use the "rundll32 printui.dll,PrintUIEntry" CMD script instead of WMI.
4 Comments   [ + ] Show comments


  • typically kace runs its tasks as system
  • you may want them to download the autoit program and run it manually
    • But our users don't have admin rights on their machines. That was kind of the point of creating this program to run from KACE.
      • Include the elevated privileges in the autoit script. We have a GPO that allows our users to install domain printers set so we can run the installs via the user.
  • you can create kscripts to push the printer as a local admin user also
  • #RequireAdmin is already part of the script, so it wouldn't even run if the permissions weren't there.

    I'll take a look at the GPO and KScript options and ignore my wounded pride. I worked so hard on that program... *sniffle, tear*
    • bummer, I learned a long time ago about kace runs everything as system unless you tell it not to. The GPO is the best way to go since you can allow them to add domain printers but not local printers. We went to creating printer groups in AD and when someone needs a printer we just add them to that printer group and done. We use KIX scripts at login to do our mappings and printers

      sample portion of kix script:


      ;Advisory Committee
      If InGroup("Advis Comm")
      Use M: "\\drserver\dept$\Advis Comm"

      ;Financial Aid
      If InGroup("Fin Aid")
      Use S: "\\DRserver\dept$"
      Use V: "\\server309\FA_viewwise$"
      ;Use L: "\\drserver\crystal$"
      Use I: "\\DRserver\upload$"

      ;Classified Council
      If InGroup("Classified Council")
      Use Z: "\\DRserver\dept$\Classified Council"

      ; OK, set up each printer on the server here.
      ; Default printers should be described first.
      ; $PrinterName: A human readable name that will be shown during installation. Shouldn't be too long.
      ; $PrinterPath: The full UNC-path to the printer like \\server\printer
      ; $PrinterGroup: The usergroup that should have the printer installed. Use "Domain Users" if you want everyone to have it.
      ; Just duplicate the above line for multiple user groups.
      ; The numbers in [] must increase by 1.

      $MUpdate= "Please wait while your network printers are connected..."
      $pick = 2
      Gosub welcome

      ; If on an ACAD Machine do not add printers
      If InStr (@HOSTNAME, ".acad.tmccadmn.tmcc.edu")<>0

      $Printers = 60
      Dim $PrinterName[$Printers], $PrinterPath[$Printers], $PrinterGroup[$Printers]

      $PrinterName[0] = "FS - 100 Color"
      $PrinterPath[0] = "\\DR-Main\FS - 100 Color"
      $PrinterGroup[0] = "FS - 100 Color-PG"

      $PrinterName[1] = "RDMT - 315U Color"
      $PrinterPath[1] = "\\DR-Main\RDMT - 315U Color"
      $PrinterGroup[1] = "RDMT - 315U-PG"

      $PrinterName[2] = "RDMT - 200E"
      $PrinterPath[2] = "\\DR-Main\RDMT - 200E"
      $PrinterGroup[2] = "RDMT - 200E-PG"
      • Can you edit the post so that your code is assigned the 'Code' style, please? TIA
      • sorry, tried but you do not have that choice with a comment like you do with an answer

All Answers

The KACE agent runs in system context which means there is no user profile for it to work with, and this will break printer installation which does require user profile access. Local admin is a normal user account with a user profile so will work.
Answered 09/18/2014 by: EdT
Red Belt

Got around the function by running a CMD script:

RunWait(@ComSpec & ' /c rundll32 printui.dll,PrintUIEntry /if /b "' & $printerName & '" /f "' & $printerInf & '" /r "' & $PrinterIP & '" /m "' & $printerModel & '"', @SystemDir, @SW_HIDE)

Worked like a charm. Thanks, guys, for getting me unstuck from my preferred solution. :-)
Answered 09/18/2014 by: tdickinson
Orange Senior Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ