PDQ Deploy does not install the same as manual install

Comments

8 comments

  • Luke Nichols

    Could you export the package and link to it here? I'm guessing that the installer does something as the current user and your PDQ Deploy runs as the Deploy User so you don't see the changes for your user account.

    Can you verify that installing the MSI manually still has the Excel add-in for other user accounts? E.g. log in with your user account, install the MSI, then have someone else sign into the computer and see if they have the Excel add-in?

    1
    Comment actions Permalink
  • Michael Capece

    I changed the deployment package to run as logged on user instead of deploy user and that worked. Is there no way around this? The problem I see is if they're not logged in then it won't deploy, or if they're logged in and using Excel, the install will fail.

     

    <?xml version="1.0" encoding="utf-8"?>
    <AdminArsenal.Export Code="PDQDeploy" Name="PDQ Deploy" Version="18.4.0.0" MinimumVersion="15.0">
    <Package>
    <CurrentLibraryPackageVersionId value="null" />
    <PackageDefinition name="Definition">
    <Conditions type="list">
    <PackageStepCondition>
    <Architecture>Both</Architecture>
    <Version>All</Version>
    <TypeName>OperatingSystem</TypeName>
    </PackageStepCondition>
    <PackageStepCondition>
    <IsUserLoggedOn>AlwaysRun</IsUserLoggedOn>
    <TypeName>LoggedOnUser</TypeName>
    </PackageStepCondition>
    <PackageStepCondition>
    <ConditionMode>None</ConditionMode>
    <InventoryCollectionId value="null" />
    <InventoryCollectionName></InventoryCollectionName>
    <TypeName>Collection</TypeName>
    </PackageStepCondition>
    </Conditions>
    <CopyMode>Default</CopyMode>
    <DelayedApprovalTimeSpan>7.00:00:00</DelayedApprovalTimeSpan>
    <DownloadApprovalMode>Manual</DownloadApprovalMode>
    <InventoryScanProfileId value="null" />
    <IsDownloadApprovalModeInherited value="true" />
    <ScanAfterDeployment value="null" />
    <Steps type="list">
    <InstallStep>
    <CustomCommandLine></CustomCommandLine>
    <FileName>\\file1\Installs\Vena\venasetup.msi</FileName>
    <Files></Files>
    <IncludeDirectory value="false" />
    <LeaveInstallFile value="false" />
    <MsiOperation>Install</MsiOperation>
    <MsiQuiet value="true" />
    <MsiRestart>Never</MsiRestart>
    <Parameters></Parameters>
    <SuccessCodes>0,1641,3010,2359302</SuccessCodes>
    <RunAs>LoggedOnUser</RunAs>
    <Conditions type="list">
    <PackageStepCondition>
    <Architecture>Both</Architecture>
    <Version>All</Version>
    <TypeName>OperatingSystem</TypeName>
    </PackageStepCondition>
    <PackageStepCondition>
    <IsUserLoggedOn>AlwaysRun</IsUserLoggedOn>
    <TypeName>LoggedOnUser</TypeName>
    </PackageStepCondition>
    <PackageStepCondition>
    <ConditionMode>None</ConditionMode>
    <InventoryCollectionId value="null" />
    <InventoryCollectionName></InventoryCollectionName>
    <TypeName>Collection</TypeName>
    </PackageStepCondition>
    </Conditions>
    <ErrorMode>StopDeploymentFail</ErrorMode>
    <Title></Title>
    <TypeName>Install</TypeName>
    <IsEnabled value="true" />
    <IsPostStep value="false" />
    <IsPreStep value="false" />
    </InstallStep>
    </Steps>
    <Timeout value="60" />
    <UseCustomTimeout value="false" />
    <RunAs>LoggedOnUser</RunAs>
    </PackageDefinition>
    <Description></Description>
    <NewLibraryPackageVersionId value="null" />
    <OriginalId value="null" />
    <Version></Version>
    <IsAutoDownload value="false" />
    <FolderId value="1" />
    <LibraryPackageVersionId value="null" />
    <Name>Vena Upgrade</Name>
    <Path>Packages\Vena Upgrade</Path>
    <PackageDisplaySettings name="DisplaySettings">
    <DisplayType>Normal</DisplayType>
    <IconKey>Icon-Package</IconKey>
    <SortOrder value="5" />
    </PackageDisplaySettings>
    </Package>
    </AdminArsenal.Export>

    1
    Comment actions Permalink
  • Luke Nichols

    Did you verify after deploying as logged on user that other user accounts can also access the Excel add-in on that machine? My suspicion is that the installer only installs for the user who runs the installer no matter what.

    1
    Comment actions Permalink
  • Colby Bouma

    One thing you can try is adding "ALLUSERS=1" (without the quotes) to Parameters.

    1
    Comment actions Permalink
  • Michael Capece

    It's an AWS WorkSpace dedicated to one user. There are no other users.

    ALLUSERS=1 is already in the Parameters

    1
    Comment actions Permalink
  • Luke Nichols

    If that is the case then I would recommend pushing something to run at startup for the user so you don't have the issue of waiting for the user to be connected. You could do this several different ways, such as scheduled task, putting it in the startup folder, etc. You could even push this with PDQ if you wanted, although doing it with Group Policy might make more sense if that's an option.

    Does each user have admin rights to their own AWS WorkSpace?

    1
    Comment actions Permalink
  • Michael Capece

    They do have admin rights. I tried using a group policy but that didn't work, it only installs one of the add-ins. So far the only thing that works is deploying as Logged in User

    1
    Comment actions Permalink
  • Luke Nichols

    Here is what I would try:

    • Put the MSI on a file share that is viewable by the user account(s) who will be signing into the workspace(s). They shouldn't need write privileges. Alternatively you could copy the MSI file to the same local directory on every machine so you can reference the path correctly.
    • Write a PowerShell or Batch script that runs the installer with the necessary command line options (you can copy this from the "Command Line" field in your PDQ package) and copy it to the AWS WorkSpace's  "%ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp" folder. You'll have to reference the path to the MSI via UNC path. If you copied the MSI file locally then you'll want to delete it as the second-to-last step in the script. You should probably have the final line in the script be to delete the script itself so that it doesn't run every time.
    • After that, have the user sign in and see if it installs the add-ins that they need.

    If the above all works, you can wrap it all up into a PDQ Deploy package and push to the rest of the WorkSpaces. You would just need a file copy step that copies the script (and, if necessary, the MSI) to the local machine. This also hinges on being able to accurately identify the machines that have/do not have the add-ins via a PDQ Inventory collection or you're going to end up accidentally pushing the install to the same WorkSpace several times on accident.

    There are ways to improve on this (like using the RunOnce registry keys to allow you to just push this once to every machine and forget about it rather than needing the script to do its own cleanup) but I think this should work for your needs.

    1
    Comment actions Permalink

Please sign in to leave a comment.