Running deployments at user logon

Is Heartbeat good enough? That deploys as soon as the target computer comes online.

hmmm....  Yes and no.  Heartbeat is fine if a machine comes online and the user subsequently logs in.  But if someone just turns the machine on that won't be good enough for this particular deployment.  It must run as the logged on user because it is installing a device that is specific to the user.  If it runs under the domain admin, local admin or the pdq service account, the device will not be installed for the user that needs to use it.

deploy at logon is a feature we have been hoping gets implemented for quite a while now.  It would be great to use PDQ for that instead of GPO's for such things.

What device are you trying to install? There is always a way my friend, always a way :)

printer migration - simple vbsscript that detects the user's networked printers, removes them and replaces them with the new printer pointing to the new print server.  It also detects the default printer and ensures the new printer is set properly.

If it does not run as the logged on user they will never get the change.

This is ugly. But bear with me. What if you created a package and deployment to push your VBScript to the machine, and throw it in rather StartUp, or make it RunOnce with the registry. Would that be an acceptable fix?

RunOnce won't be a viable option I don't think because as I understand it to add something to the RunOnce key you have to specify the SID in the reg add command.  More trouble than it's worth I think.  The startup option might work, but I only want this to run one time.  So what would be the best way to ensure that?  Would I need to modify the script to delete itself after it runs or use PDQ to remove it?

 

Yeah. You could code it to self destruct from Startup after it is done doing its work. I knew using RunOnce was going to be a pain in the ass, but wanted to throw it out there as it is an option, just not a very good one.

What I would do is create a package to copy the file down somewhere on the machine, and create a .lnk file in Startup to the file. 

 

Inside of the vbscript, at the end of the file delete that .lnk from the startup folder.

 

Create another PDQ Package that you can run after you verify everything is working that deletes the vbs script from the machines. Or leave it there. Whatever. But I would delete it if you aren't in need of it being on the machine anymore. The important thing is getting it out of Startup after it is done.

I believe that might be the solution.  I'll test it out today.

Sounds good. Let me know the outcome, I'm curious now!

well the test works but it's way more work than I care to do again.  First, I didn't write the script I used so I had to figure out how to write and where to put the code that deletes the .lnk and the syntax etc... I'm no vbscript genius at all so lot of trial and error.  Finally I got it to work but it would have been great if PDQ would just run the script at logon.  I got enough to do in a day.

This would be a great feature but without an agent installed on the target machines it's a little harder to achieve.

harder doesn't mean impossible :)

 

Take the Kennedy approach and give us that feature:

"...not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills..."

The beauty of PDQ is that it doesn't require an agent client-side. I for one hate them. It adds a layer of complexity, and another point of failure to a solution.

If they do decide to do some sort of agent based software, I hope to see it as an optional way of deploying. Give us the flexibility to use it as it currently is, and the way you want to use it.