Webcast: Maintaining a Baseline of Applications

PDQ Deploy - Download free mode14-day Enterprise Trial, or Buy (Pro or Enterprise mode)

PDQ Inventory - Download free mode, 14-day Enterprise Trial or Buy (Pro or Enterprise mode)

Scheduled deployments (including Auto Deployments) 2:05

  -Run Active Directory sync first 2:37

  -Update packages in the Package library 3:35

  -Define the baseline packages 4:26

  -Link to Targets vs Choose Targets 6:22

  -Options: Stop deploying to computers once they succeed 9:28

Question: Any plans for a shortcut to AD Sync in the toolbar? 11:34 **UPDATE: this is now a native features as of Inventory 9**

Question: Do we have to link targets? I am thinking of devices that I just installed the OS on and just want to get the items on for the first time. 17:13

Question: When you have a package for a scheduled deployment (auto deployment) , is it necessary to download/import the package a second time for one-off installs? 19:08

Question: When deploying Microsoft Office 2013, is there any way to have it automatically use the recommended settings? When I deploy it now, I have to open Word or Excel, etc. and input admin credentials for this? 25:58

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


  • 0

    Best practices question:

    Currently we nest the Java PDQ Library package inside a package called "OurPackage" -- we do a few custom steps after the installer, and thus far this has worked nicely (you only need to swap in the new Java package each time updates come out to "OurPackage", not duplicate the custom steps each time to each Java package that gets imported per updates).

    However, my assumption is that with nested packages included in a schedule, the scheduler doesn't "know" when we've updated "OurPackage" with a newer Java binary -- right? Or does it? (inquisitive tone)

    How does the schedule know a package version (especially if its not brought in via auto-deployment).  Is there a UNIQUE ID that each package attached to a schedule gets -- is it attached to the package name/version string?

    So, in my example (and assumptions on the unique id) would the best practice be, once a java update comes out -- update "OurPackage" as needed -- and then remove and re-add "OurPackage" to the scheduler to force the scheduler to treat "OurPackage" as a new package -- hence guaranteeing that the actual java update goes out?

    Or would it just be easier to add our custom steps to each imported Java update package and just update the scheduler when Java updates come out (essentially removing the "OurPackage" nested package from the equation and putting custom steps in source package)?

    Thanks for your thoughts

Please sign in to leave a comment.
Powered by Zendesk