How do yo handle the practial installation (installing when users potentially logged on)?

I am just digging into PDQD (although the few packages I've distributed so far have gone swimmingly!) but I have some prior experience with PSADT and it will do just what you need as long as you have powershell on your clients (and if you don't, just push it out via gpo first).  Check it out - it's notification methods and ability for clients to basically schedule their own install is really useful in situations like yours.

https://psappdeploytoolkit.codeplex.com/

I plan to integrate it with some of my PDQD deployments in the future, so I'm right there with ya.

Thanx for the tip. That looked sweet. Wil look into it as soon I get time.

Just based on the screensohts, it would be amzing if PDQ would have a similar feature. Or maybe an "psappdeploy" integration/plugin solution.

I'm also looking at psadt, but would love the functionality in PDQ.

Would love the functionality in PDQ also

While a more robust message step has been discussed by the developers (currently a GUI based version of msg.exe) most of what you're looking for in this feature would require an agent on the target machine and since we are an agentless product I'm not sure this is on our current road map.

Also to note a lot of software that is able to be deployed silently, does not require any interaction or notice to the end user.  Packages like Java that kill the browsers or others that require a reboot are where this takes a little ingenuity planning the deployment or having a maintenance window.  We also have created the ability to set conditions on the package steps to not run if a user is logged in so that accidental issues don't arise as well.

Hello, OP here, with another account. I don’t fully understand your last post Jason. Yes, most deployments is silent. That is beside the point. The major problem we face is the consequence of the installation. Almost every deployment would benefit of a message step. Not new installations that much but updates to applications. I bet most admins update application more often then they install new versions. Updates normally results in the killing of the application that is being deployed/upgraded, or other related applications. A user does not care if the browser session is lost due to a Java update, that kills the browser or a browser update that kills the browser. Work might be lost either way. Let’s say you deploy a new version of Gimp, and a user is using Gimp, a heads up would be most welcome. If not work will be lost. A message step would solve this!  Especially if the message step would have the following features:

1. A configurable message (Remembered by autodeployments)

2. Continue/Install-now  button

3. Cancel button (Should be able to disable this button on package level, remembered by autodeployments)

4. A timer, that would proceed (call the Continue function related to the Continue button) the installation automatically after xxx (confiugurable) minutes. If the timer is set to 60 min, and cancel button have not been hit, this would indicate the user have left the workstation, and that it is probably safe to procede with the deployment.

If I can do this with a VB script, you can most certainly do it with a message step and without an agent.

Let me know if this would work for you:

1. A message step, "Hey there, FYI, in 60 minutes, a deployment will be pushed that's going to kill your program as it performs and upgrade. Please ensure you have saved all your work prior to this time." (for Autodeployments, this is being reviewed by Dev at the moment).
2. Sleep step for 60 minutes/3600 seconds.
3. Deploy.

Because of the tools we use and how we initiate deployments to target machines (e.g. an agent-less approach), having a cancel button doesn't necessarily work with our methods, which is why you can do things with a VB script that are not practical using Deploy directly. 

Brigg,

So you aren't getting a status of "button pushed" or not?  It seems to me, your software creates a directory in %windir%, and copies deployed software to that staging area, right?

If so, why couldn't you create an "app" that displays a message (or messagebox) with yes/no/cancel/whatever, and writes that status to a text file in the staging directory that could be read/acted upon after the delay time is up?  Hmm, seems like that might be something we could do on our own...

<just thinking out loud now>I already have a writable directory within my repository that the deploy user(s) may write to.  If you could have a process that would watch a directory and act upon files as they appear (maybe within 1 minute of appearing), we could create an app that displays a message box which results in a status of 1=okay, deploy now  2=cancel, skip deployment.  If there were a unique identifier for each system (like netbios name or something), you could tie that file into a waiting app to determine go/no go status.  That would allow a timer, instant yes, and instant no.  If we could select what the default would be after the timer, things would almost be perfect!  </thinking out loud>

This would seem to be agentless...  Maybe?

Yes, I wanted to do my own thing since displaying a message just isnt the end result I'm wanting. I asked about adding a Command Step before and after auto deploys but was told that will not be possible because they are only adding the ability to add a Message step and no other type of steps. While this is a step in the right direction, it still really does nothing for me.

I dont understand why they don't focus on allowing us to add Auto Packages as we would add any other package as a nested step. This would allow everyone to do exactly what they want to do including add a simple message step before the auto package.

Let's look at this from the software's standpoint:

We implement an "okay" or "cancel" deployment message, and we send the code via text file to the temp directory that tells Deploy to proceed or to stop. From there, the runner service must send back a message to the mother ship console at the end of the process, whether it's to install (which will be a success message) or to cancel (which will be... some other message?). Since return codes are currently binary -success/fail- the software would need another return code, but that is problematic. You can't have a success code on a package where the package was not installed. You can't have a failed code on a package where the deployment uses the retry queue or heartbeat. You also can't have a failed code on a package that was cancelled/postponed by a user. And from here, reporting would be off as well. And how does the software know which codes are success and fail? Maybe we come up with our own, so a code 666 means canceled/postponed, but the problem remains that large portions of the software fundamental to the basic workflow of Deploy would have to be rewritten to accommodate something that can be more or less handled in a script. Or we start using agents, which is something we'd rather not do for the time being.

Brigg Angus you're making it more complicated than it should be. Right now, auto-deploys can really only be pushed out via Schedule. But what If along with normal downloadable packages, we had Auto Packages? Auto, because they use the latest version of the package at the time of deployment. We could then setup our own packages to do anything we want before the nested "Auto Package" as well as do anything we would like after the nested "Auto Package".

For example to push out JAVA, I could create a package that has a command step that runs a script, If I wanted I could have the script return an error code that causes the entire package to fail. If not it continues to the Auto Package step where the latest JAVA package is pushed out. and it then continues on to the next step just like any other package. The key is to be able to add a nested package that stays current, if not we have to manually download and update the package each time there is a new version.

Hi Guys,

This thread has gone in a few different directions and topics.  For the Auto Deploy packages, our developers are currently looking at adding more flexibility to those so that you could possibly nest other packages with them thereby allowing your script to work as you've described.  Brigg was responding more to Dwreese on why our product doesn't currently support that method with the way it's written.  We appreciate all of the feedback.

Thanks for the update Brigg.

I also agree that the autodeployments should be able to used more as a regular package, but that is another story.

Your first answer is a rather big step in the right direction. However, does not really help much. 

I want to get back to the VB script a bit. I still don’t understand why you cannot do what I can do in a VB scrip. To clearify, I execute a VB script as a command step in a package.

I see no reason why AA cannot build a step, where you configure the parameters in the step. And at deployment time/or when the package is created or updated, It creates an identical script. Then executes it, just like the command step. You can even put it in PDQ deploy’s working directory as well at deployment time. I have it on UNC, currently, but that should not matter.

Here is what I have done.

Created a script

-       that takes one parameter (number of seconds before the deployments starts on it’s own)

-       Displays a message to the LOGGED on user, giving him a warning that a deployment is about to start. He can click yes to start the deployment immediately, (exit code 0). Or he can click no to cancel the deployment all together (made up exit code of 999, indicating a failed steop). If the user does not do anything, the script ends with exit code 0, that tells PDQ Deploy to continue to the next step. (the actual package(s) I want to install)

-       Of cause, this step needs to have a success code of only 0. In addition, the “error mode” should be “Stop deployment with error”.

This script gives me everting I need, to deploy packages SAFLY from an end-user perspective.

-       Message to user

-       User can chose to install immediately

-       User can choose to cancel the install

-       If user does nothing (probably away) the install executes. (At least this is vaild if you set an hour wait time for the script)

I would really see this step streamlined and integrated to PDQ Deploy as a “Message” step.
Where the PDQ Admin only need to choose:

-       Timeout/auto install after xx seconds

-       Message title

-       Message to user (The message should also show xx minutes to “auto start”)

-       Optionally list all applications in the steps the are going to be installed. (This is something I cannot do, without making separate scripts for each flavor of packages.)

PDQ Deploy would already know that a non-successful message on this step should stop deployment. And that it should run on as logged on user OR “Deploy user (Interactive)” seems to work as well…..

The only problem I can see about this solution is that it logges a FAILED installation when user selects “no” in the message.. But it’s no far from the truth, actually is more precise then a success. Because there was after all nothing installed.

I will attach screenshots in a word file of the step and the script, and the script itself. I think I have posted an earlier version of it someplace else here too, but this is the latest one.

Oh, one more thing.
I have also created different package that only contains the command step (that executes the VBS file). I like to those packages "functions".
I have called one of these packages/functions "Warn & autoaccept 5 minutes".
I can then (as a first step) nest this package/function into whatever package i want to give the user some choices.
(I have a few different types, only thing that varies is the time before autoaccept kicks in).
However it is useless in auto deployments, since it does not remember nested steps from one release to another. And it is in auto deployment this feature really would shine.

Attached is screenshots of the the setup.

Yes, exactly. If you have two packages in a schedule. it push's each package one by one to each computer. So if you have a package that displays a message, the second package doesnt start pushing out until all the computers run the first display message package.

I have tried this with auto deploy and two packages added to the schedule. Package 1 displays message and locks down workstation so user can't use the computer during the install. Package 2 is the autodeploy package, and Package 3 is a package that unlocks the workstation and removes the message being displayed.

The end result is all computers get the message and lock up and none of the computers start to unlock until all of the computers have finished installing the auto deploy package. 

Mmuni. I thik we have different needs for the autodeployment. 

What I would like to do is to add an "warning" step (not another package) to each autodeployment. This step should be remembered when the next version is released.

This way a warning would be given to every user where the autodeployment kicks inn, without me having to go and add a new warnings step to every auto deployment each time a new version is released. That's the sole reason to use autodepoyments (insetad of schedules)..

Yes, I want the exact same thing you want, I'm demonstrating how adding via schedules witch is currently the only way does not work. We need to be able to add steps to an auto deploy package or be able to create our own package that includes a nested Auto Deploy step.

Just another comment.
Still not sure we need the exact same thing.
Since all my auto deployments are linked to a dynamic grooup in inventory.
(Because of this I cannot have multiple autoedployments on one schedule/since the target are linked to the SCHEDULE and not the package itself.. witch made more sense, but thats another story :))

This means I have a 1 to 1 realationship between targets, computers and schedules.
Meaning i can just add /link the warning package to the schedule (instead of using a step in the autodeployment itself)

And setting the warning step at the top. Se attached image.

Setting it up this way hold of the autodeployment until the first pacakge (wait function) have finished. If it fails (user clicks no) then it will not install.

I think this is a rather dirty workaround. But it serves its purpose.

This made no sense. Fixed:
And setting the warning step at the top. Se attached image.

And setting the warning PACKAGE  at the top. Se attached image.

Yes I also have them set to a dynamic collection in inventory and do not have multiple auto deploy's in a single schedule (not sure if that's even possible or why anyone would attempt that)

They have confirmed that they are working on the ability to add a "Message" step to the auto deployment packages. However the simple "Message" step just does not do everything I want/need it to do like Lock down the keyboard/Mouse right before installing the intended program. What we need is to be able to add any time of step not just the message step, both before and after the auto deploy.

I agree, just a Message will no t help much. Have you tried the warning script in this thread?
Make a pacakge of it and link to an autodeployment. It actually works, regardless how dirty it is :)

No I have not tried it, I made my own that I'm using with my packages.

The problem is with how the schedules deploy. Instead of the schedule kicking of like a single deployment package with all of its assigned packages nested in it, It instead just creates a deployment for each of its packages. So Package one pushes to everyone and once everyone has package 1 it moves to package two. This works fine if I'm deploying to a single machine but when deploying to thousands of machines you end up with all of my computers being locked up until the last one finishes.

 Do you actually Lock Down/disable the keyboard/mouse for the duration of the deployment? Or at least thats what you want?

Yes, I black out the screen and put a message in white text saying what is happening and not to turn off the computer, I lock the keyboard and Mouse. This also gets a timeout value so lets say the install should only take 5 minutes, I may put a 10 minute timeout. What that does is if the package ever fails during installation after the timeout period the message will go away and keyboard/mouse will unlock. If the package is successfully installed, the last step kills the message and unlocks mouse/keyboard immediately so they can start using the computer.

Ok, then we have two very different approaches to this.
- I want the warning step to protect the users from losing data.
- You want this step to lock down the computer so users cannot interrupt the running installation.

I actually need the users to use the keyboard/mouse to make the selection to either start the installation or cancel it.

If I just were to lock down the mouse and keyboard, they would not be able to finish of/save their existing work, be it Skype, notepad++ or whatever.

However, I see some benefit in locking down a workstation, but most installs are silent so they could actually be working with most programs without noticing the install at all.
I might create another warning step with a lock down function as well. But the lockdown would only happen after the user have clicked YES on the dialogue/accept the install or it "auto accepts" by timeout.

Yes, have a step that runs a script prompting the user to continue or not, depending on the result it returns an error code, PDQ step is set to know what error code allows to continue to the lock down step and if an unknown error code gets returned it aborts the deployment to that machine and marks it as failed.

I think I have a solution for what you want to do by just using a simple Command step. Since this forum does not play well with script code I have also attached a screenshot of it in action. What this does is present a message to the user with a Yes and No option, If the user selects No then it returns error code 7 causing the step to fail. If they select Yes the step will not fail and pdq will continue to the next step.

@echo off Call :YesNoBox "This computer needs to upgrade Microsoft Office, please save any open documents before continuing. Start upgrade now?" "Update..." if "%YesNo%"=="7" ( exit /b 7 ) exit /b :YesNoBox REM returns 6 = Yes, 7 = No. Type=4 = Yes/No set YesNo= set MsgType=4 set heading=%~2 set message=%~1 echo wscript.echo msgbox(WScript.Arguments(0),%MsgType%,WScript.Arguments(1)) >"%temp%\input.vbs" for /f "tokens=* delims=" %%a in ('cscript //nologo "%temp%\input.vbs" "%message%" "%heading%"') do set YesNo=%%a exit /b

Still, this cant work unless command steps are allowed to be added to auto deploys