1 comment

  • Ryan Joachim

    Yes, I have done it.
    Yes, I have had success with it.
    Yes, I have had horrible luck with it as well.
    None of the issues I had were related to PDQ in any way - Deployment went through without a hitch every time and finished successfully, or failed due to an issue on the machine which was caught by the logs.

    The issue you'll run into is that after the setup/upgrade file has finished the first stage of deployment, it sends back a success code to PDQ (because yes, it was successful up to this point), and then it will trigger a machine reboot. After that happens, PDQ's job is done. What happens next is entirely offline and handled by the target machine, including any and all errors and logging. PDQ has no way to know what is happening, what is successful, or what failed.

    If you have another option like WSUS or SCCM, you should go that route. You'll have a much better time tracking and troubleshooting errors, thanks to how tightly those two integrate into the OS.

    All the warnings aside, you can certainly do this with PDQ Deploy. At it's most basic, all you have to do is run the executable with the switches that make the most sense for your environment and start your deployments. Here is what we ended up with for our environment;

    setup.exe /auto upgrade /quiet /migratedrivers all /ShowOOBE none /Compat IgnoreWarning /Telemetry Disable /DynamicUpdate disable

    An obvious cause of upgrade failures is the /Compat IgnoreWarning switch - it suppresses any warnings about possible compatibility issues the installer found on the machine (either with software or with the hardware).

    So long as you're comfortable with not knowing whether (or why) a machine fails to upgrade from within Deploy itself, and you understand the reasons why, you'll have a good experience deploying the upgrade.

    Comment actions Permalink

Please sign in to leave a comment.