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.

Feature Request - Uninterrupted Deployment

It would be nice if we had the option for certain packages to make them uninterruptible by the end users. For example if you are pushing out a new browser version silently, any open instance of the browser will be closed prior to the install. However if the user is at the computer they will just reopen the browser before the install starts. I know there is an option to display a message to the users but they all just close the messages and most don't even read them.


What this feature would do is display a full screen massage to any users currently logged on and disable their Mouse & Keyboard. After the package has finished being deployed the message would go away and the users Mouse & Keyboard would be re-enabled so they can continue working.

We could even use the popup message step available now with this to warn them to save all current open documents as the update will be taking place in a few minutes. Use the sleep step to give them time to save things and then jump into the uninterrupted deployment steps.



Date Votes
  • This would be very useful, especially for those infamous java updates that want the browser closed

  • I was able to put together my own work around for this. I made a small EXE that I can pass two variables to when executing. One is a max timeout so that it lets the user back in after a set amount of time if the deployment did not complete or fails. The second is the text to be displayed on screen.

    The end result is a full screen message to the user and mouse/keyboard disabled during package deployment. The last step in the package kills the EXE giving control back to the end user.


    While this is good for my own personal packages, I was hoping to use it with auto-deployments however the way that PDQ deploys schedules with multiple packages will not work with this. What would end up happening is all the computers would get locked up while the second package deploys slowly, a hand full of PC's at a time.

  • My apologies for the very delayed reply, however, I just wanted to let you know that this is with our developers for consideration.