Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Why can't I change parameters in autodownloaded packages?

We just purchased PDQ Deploy and I am quite surprised to learn that we can not change the parameters for auto downloaded packages.  I was really looking forward to having PDQ Deploy manage applications such as Zoom and Adobe but our users have requested icons for these applications and the parameters in the auto download packages remove desktop icons.  I'm aware that we can use the copy file option to copy a shortcut to the publics folder as an additional step, but can someone explain the reason behind locking the parameters of an auto downloaded package?  



Date Votes
  • I would surmise it's because if you do something custom, future auto packages would break your customizations.  It would be a simple task to copy the icon/shortcuts you want to the Public Desktop of workstations.

  • You could approach this two ways.

    You can convert the package into a standard package, and you can modify it however you want. But I wouldn't recommend this, because it will no longer gets version updates and end up making more work for you.

    A better solution would be to add a post step that adds the desktop shortcut back. Pre and Post steps in auto download packages won't be changed or removed when PDQ updates the core steps or version. That way if you have non-standard requests from users or your environment, you can add a post step for them but still be deploying the latest approved version.

    Below is a quick PowerShell script you can modify to recreate the shortcut.

    #Creates Shortcut
    $WshShell = New-Object -comObject WScript.Shell
    $Shortcut = $WshShell.CreateShortcut("C:\Users\Public\Desktop\Google Chrome.lnk")
    $Shortcut.TargetPath = "C:\Program Files\Google\Chrome\Application\chrome.exe"
  • Post steps are a great way to accomplish this, as James D said.

  • Thank you everyone for the replies.  I will try setting up some post steps.  


    I can understand why some customizations might break with new releases as some things will change, such as the filename, but it seems to me that the vast majority of customizations that people are doing are standard switches or options that should always be available with new releases.  I guess I am surprised that PDQDeploy locks all customization options here.  I can understand their thinking, but it feels like a lazy way to try and prevent the user from making basic mistakes that they might try and blame on PDQ, instead of giving the user the flexibility and power that I expected with this software.  I'm very new to the PDQ world so perhaps I need to learn their methods a bit more before it will make more sense to me.  Thanks again for the quick answers!