This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Custom Third Party app requires Administrative privileges to download

I have created a custom third party package. However, when I attempt to "install updates" on the client computer when logged on as a non admin user, it requires admin rights and displays the UAC prompt. When logged in as an admin it installs perfect. Windows update shows the following when attempting to download using WUInstall.exe:

013-06-28    17:35:02:726     900    12e0    Agent    WARNING: WU client fails CClientCallRecorder::BeginDownloadUpdates2 from  with error 0x80240044

Searching around, it appears that this is a permissions error. I believe that Custom third party apps when sent through WSUS as a package are run under the system context. Apparently, in this case, it is not so.

The app is a vbs script, which is run by wscript <filename>. I have compiled it as a package, but Patch Manager displays "The publisher is unable to verify the selected executable file" when uploading the executable. To overcome this, I have used wscript.exe as the executable, included required files as "additional files" and used the script name as the command line.

Would any one be able to help me find out what is causing this behaviour? Thanks.

  • Some questions come to mind:

    Is this your only 3rd party custom app that you are deploying?

    Of all the items you are deploying with Patch Manager, is this the only one giving you problems?

    Is this the only one that requires the "custom custom" workaround?

    (I have a few packages that are normally deployed with .vbs scripts that require admin privileges, but the only way to get it to deploy properly with PM is to use a temp.exe file that does absolutely nothing (just ignore the verify message), but allows me to upload all the other files and use a custom packageboot.xml that calls a CUSTOMNAME.cmd file in the post-execution section which has a single line of code:  START /WAIT WScript "%~dp0SCRIPTNAME.vbs" //NoLogo)

    Also, I have discovered when having these odd issues with PM, that sometimes, deleting the item from the WSUS server, and creating a whole new package helps - because simply making the changes in the package, and sending the updates to the same PackageID folder doesn't always work.

    Hopefully, some of that info will be useful.

  • You have some great suggestions here; however, the issue is totally different.

    The problem is that on "Select Package" screen, under Settings, Advanced, if  "Install can request user input" is selected, somehow the context changes and the non-admin end user is prompted for Admin credentials.

    I agree that deleting the package and creating the new one is always the best option. I am yet to have success in revising a file within a package. No matter how I try, the new file shows in the package, but not in the published package. "Package boot helper" file is worse. It displays the last used file instead of the one that is included with the package.

  • Exactly! Once you publish a package with content, unless you are changing the applicability or installed checking rules, any content change almost always requires a deletion then re-publish.

    You may also want to keep a packageboot.xml file handy to overwrite every time you check that package boot helper option.

    (also, make sure you delete the one that gets auto-populated, then when you click on the view .xml file - you will see yours)

    Here's my generic that I use when I have to deploy a fake application that calls the vbs script (and as a when I need to create a new custom one)

    -----------------------

    <?xml version="1.0" encoding="utf-8"?>

    <packageboot version="1.0.0.0" id="dd53b76e-babc-410f-8901-426d0989f5f1">

      <instructions>

        <preexecution>

          <processes>

            <process name="Application.exe" action="terminate" failureaction="stop" enabled="false" />

          </processes>

        </preexecution>

        <execution>

          <programs>

            <program type="exe" typeaction="runandwait" name="TempPatch.EXE" successcode="0" failureaction="stop" enabled="false">

            </program>

          </programs>

        </execution>

        <postexecution>

          <programs>

            <program type="exe" typeaction="runandwait" name="CUSTOMNAME.cmd" successcode="0" failureaction="stop" enabled="true">

            </program>

          </programs>

        </postexecution>

      </instructions>

    </packageboot>

    ----------------------

    Please post if you actually get to the root cause and solution.

  • The root cause is "Install can request user input" option. Whenever this option is selected, UAC kicks in. The solution that I found is to create a task that runs upon creation, and a batch file in post execution that deletes the scheduled task.

  • Yeah, read the other thread about the UAC prompt. Not the first time you will have to Macgyver a solution, certainly won't be the last.