Remote deployment - Background service not running

I am trying to integrate PDQDeploy into our MDT deployment task sequences for software installs but running into a snag. I found a post that discusses how to trigger a deployment from a remote machine and I have what I believe to be the correct command in a batch script, but when I run it, even manually, on the remote PC, I get a message that "The background service is not running". The service PDQDeploy.exe exited with error code 1.

I've checked in the console and the background service is running. I've tried running the same script while logged into the remote PC as the service account used on PDQDeploy as well. 

The command looks like this: 

psexec.exe \\server -h -n 120 -accepteula "C:\Program Files (x86)\Admin Arsenal\PDQ Deploy\PDQDeploy.exe" Deploy -Package "GINA Client" -Targets %COMPUTERNAME%



Date Votes
  • I literally was getting ready to post a similar question 20 minutes ago until I stumbled onto how to get it to work. 

    You have to use this format at the start:

    psexec \\server -u <domain>\<username> -p <password> -h -accepteula

    I also have it set to use the IP instead of the hostname to avoid pesky DNS issues, so it's structured like this: 

    for /f "skip=1 delims={}, " %%A in ('wmic nicconfig get ipaddress') do for /f "tokens=1" %%B in ("%%~A") do set "IP=%%~B"
    psexec \\server -u <domain>\<username> -p <password> -h -accepteula "C:\Program Files (x86)\Admin Arsenal\PDQ Deploy\pdqdeploy.exe" Deploy -Package "Baseline" -Targets %ip%
  • Thanks David. That definitely works when entering the username and password. I was really hoping to avoid having to do that though since the password lives in plain text in a script, correct?

  • Kris has a blog post here about storing credentials securely using a key file. Have a look at that. I'm with you on storing creds in plain text.

    You could then wrap all this up in Powershell to be able to utilize it.

    This sounds like a good topic for a write-up. I'll put it on my radar to get that done for the community.

  • It does on the initial image, but it's gone before it leaves our hands. We use FOG for imaging, so we just run a batch file that handles all the post-imaging steps. The very last thing it does is run a separate batch file that deletes the script with the login information.

  • We use FOG here as well.. We just use a Collection for a specific AD group, and a heartbeat schedule deploys to it. Works really well.

  • That's awesome Stephen, thanks. I found Kris' blog post so I'll give that a read. And I think a write-up would be very helpful for a lot of users so thanks for any time you put into that.



  • I haven't watched this yet, but Admin Arsenal recently created a video about OS imaging and deployment.

  • Colby, 


    I was watching that webcast when it was live. It really wasn't that granular to be able to be used for ALL imaging scenarios. Missed the mark of what they were going for in my opinion.

  • Ah, ok. Good to know :)


Please sign in to leave a comment.

Didn't find what you were looking for?

New post