Request for push



  • Shane Corellian


    Let's say you have a PDQ package called "Baseline Apps". This package simply calls other packages (nested packages). You can initiate a deployment via the Command Line if you'd like. From your MDT system you can probably just run a psexec command to call the CLI on your PDQ Deploy server.

    See the attached image where you see a deployment initiated remotely via CLI.

    The following command will run the pdqdeploy.exe on the server, Stanhope, and will deploy the "Baseline Apps" package on two computers, Quintana and Costanza.

    psexec \\stanhope -h -accepteula "c:\program files (x86)\Admin Arsenal\PDQ Deploy\pdqdeploy.exe" Deploy -Package "Baseline Apps" -Targets Quintana Costanza

    This would probably achieve your goal. 

    A downside here is that you will need to, obviously, keep the Baseline Apps package up-to-date when new versions of your baseline apps are released. To get around this you could use Auto Deployments. This means that as the packages are updated (e.g. Java goes from Java 7 Update 6 to Java 7 Update 67) the new version would automatically be added to the schedule and the old version removed. This only works with packages from the Package Library and these are released via schedules. In this case you could have your new machines be members of a specific AD OU that is called "New Computers" or something. The schedule kicks off every day or every few hours and hits the new computers.

    Check out this video for Auto Deployments.

    Comment actions Permalink
  • Remko de Koning

    Hey Shane,

    This certainly did the trick. Thanks for the feedback!


    Comment actions Permalink
  • Joe Wiard

    Using -Targets %COMPUTERNAME% works for me so I don't have to specify a name. Thanks for posting this, Shane! I didn't know about the command line functionality. This simplified my deployments even more. : )

    Comment actions Permalink
  • Craig Hodges

    I want to share this vbscript I put together that will start the deployment from MDT but make MDT wait until the PDQ deployment is complete before continuing the task sequence.

    Just add a command line task to execute "cscript %scriptroot%\nameofscript.vbs".  You will need to copy psexec.exe and add this vbscript to your Scripts folder in your deployment share.  In the script below, change PDQServer to the computer name with PDQ Deploy installed on and change PDQPackage to the name of the package you want to deploy.

    I have this script temporarily turn off the firewall and do some quick fixes for DNS issues I have run into in my environment when re-imaging PCs and keeping the same hostname.


    Option Explicit

    Const PROC_NAME = "PDQDeployRunner-1.exe"
    Const RUN_CMD = "c:\windows\system32\ipconfig.exe /registerdns"
    Const RUN_CMD1 = "%scriptroot%\psexec.exe \\PDQServer -h -accepteula c:\windows\system32\ipconfig.exe /flushdns"
    Const RUN_CMD2 = "%scriptroot%\psexec.exe \\PDQServer -h -accepteula C:\PROGRA~2\ADMINA~1\PDQDEP~1\pdqdeploy.exe Deploy -Package PDQPackage -Targets %COMPUTERNAME%"
    Const FileName = "c:\windows\AdminArsenal\PDQDeployRunner\service-1.lock"
    Const SLEEP_INTERVAL_MS = 30000 ' Check for PDQ Deploy Runner every 30 secs
    Const WAIT_TIMEOUT_MS = 1800000 ' Timeout 30 mins

    Dim objWshShell, objWMIService, FSO
    Dim intWaited, blnProcessTerminated

    Set objWshShell = WScript.CreateObject("WScript.Shell")

    objWshShell.Run "c:\windows\system32\netsh.exe advfirewall set allprofiles state off", 0, true
    objWshShell.Run RUN_CMD,0,true
    objWshShell.Run RUN_CMD1,0,true
    objWshShell.Run RUN_CMD2,0,true


    intWaited = 0
    blnProcessTerminated = False

    Set FSO = CreateObject("Scripting.FileSystemObject")
    While intWaited < WAIT_TIMEOUT_MS And Not blnProcessTerminated
    If FSO.FileExists(FileName) Then
    intWaited = intWaited + SLEEP_INTERVAL_MS
    blnProcessTerminated = True
    End If

    objWshShell.Run "c:\windows\system32\netsh.exe advfirewall set allprofiles state on",0,true


    Comment actions Permalink
  • Michael Muni

    I set all my software up witch schedules and heartbeats. The trick is to then setup the corresponding dynamic collections. Software that gets installed on all computers has collections for computers missing or having outdated versions.

    Then what I do for computers that are installed on a limited basis is setup a Security Group in active directory with the name of the software and add the computer accounts that need the software. I then have a dynamic collection that checks for computers that are in the software security group but dont have the software installed yet.


    This way when I image a computer all the software it needs will get put right back on it without me needing to do anything, and for new computers it's just a matter of adding the computer account to the proper software name security groups.


    This may not kick off the software instantly after being imaged, but it really doesn't take much time at all, and I can always schedule a computer to be reimaged without worrying about what software needs to be added back onto that particular computer.

    Comment actions Permalink

Please sign in to leave a comment.