Why does it fail if I deploy a .cmd file that runs a ping command?

Use NUL not NULL. NULL creates a file in C:\windows\system32

It might be a problem if your script doesnt have the appropriate privileges.

It appears to fail whether I use NUL as well.

Even if I just leave it as:

ping -n 11 127.0.0.1

or

ping -n 11 localhost

It will fail.

The PDQ Deploy Run As option is set to (Default) Deploy User.

I'm not sure what else is going on here 

Ok, I think it IS the computer system that has the problem. Not PDQ or the batch file. 
I deployed it to my computer just fine and it was successful. 

The "Analyze" diagnostic in PDQ Deploy says everything checks out fine on the target machine, so what else could there be? It is an XP Embedded OS with a write-filter running, but surely running a ping command wouldn't be a problem, right?

And I can run the .cmd file by opening a command prompt on the computer and calling it over a UNC path 

try to run ping -n 10 127.0.01 >C:\temp\report.txt and check the file for any content. it might give you a clue whats is going on. Please check also the event logs of the particular system for errors.

ping -n 10 127.0.0.1 >C:\temp\report.txt

It looks like when I change it to:

ping -n 10 127.0.01 >C:\report.txt

It fails but then I check the c:\report.txt on the target machine and it contains:

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

So as you can see it only pinged 3 times then PDQ just failed/stopped 

The System category in Event Viewer just shows the PDQ starting, then stopping, then entering stopped state. 

Weird behavior. Try to ping 127.0.0.2, but I assume it ends the same way.

You should check the network card drivers. What NIC is on the system? What driver version is it using?

There might also be something wrong with winsock. You might create a batch and deploy it:

netsh int ip reset c:\resetlog.txt
shutdown -r -t 10 -f

Ah ok here we go, another system showed this in Event log

The PDQDeployRunner-1 service was unable to log on as DOMAIN\MyUserAccount with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.

Then next entry:

The PDQDeployRunner-1 service failed to start due to the following error: 

The service did not start due to a logon failure.

But then it proceeds to run, running state, stop, stopped state 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This has nothing to do with your kind of a problem.If I remember corretly, PDQ Inventory tries to start as a service with the supplied credentials. It fails in case the credentials dont have the run as service attribute. Then it starts under the credentials it self. You can see it in the event log that it started successfully.

The Admin Arsenal guys can give a propper explanation of the behavior. But still, its not the cause for the problem mentioned.

Yeah I'm confident it's not a logon issue as well. My account state is fine and am a Domain Admin with access to open C$ on remote system and Analyze with no issues using the PDQ Deploy Troubleshoot option.

The event log just shows the chain of events as, all like 2 seconds in between:

The PDQDeployRunner-1 service was successfully sent a start control.

The PDQDeployRunner-1 service entered the running state.

The PDQDeployRunner-1 service entered the stopped state.

The PDQDeployRunner-1 service was successfully sent a stop control.

The PDQDeployRunner-1 service was successfully sent a start control.

The PDQDeployRunner-1 service entered the running state.

The PDQDeployRunner-1 service entered the stopped state.

The PDQDeployRunner-1 service was successfully sent a stop control.

These are Windows XP Embedded SP2 systems 

ok I think I figured the issue

The XP Embedded OS has a file-based-write-filter (FBWFMGR) and when I exclude the C:\Windows\AdminArsenal path and reboot, the PDQ Deploy works fine. 

When the write filter is on and this filter is not excluded, is when the PDQ Deploy job fails. However I still show its PDQDeployRunner lock folders/files being generated in the folder, it just seems Windows, or PDQ Deploy, is ending early for some reason. 

Is there a way to change the path PDQ deploy uses from C:\Windows\AdminAresenal (aka admin$\AdminArsenal\PDQDeployRunner) so I don't have to fiddle with write-filter on all the computers to deploy something so simple? 

Dang it looks like I can't change the Target Service directory path without Pro Mode. that sucks. I just ran out of my trial too which I didn't even use 

See, this one thing, you did not supply enough information for dealing with the problem. There is no way we could know that you have XP Embedded systems which in most cases are heavily customised and standard things wont work in standard ways. I am sorry I could not help more.

If you ask nicely ;-) I am sure that the Admin Arsenal guys will send you a new trial license. You just have to ask.

yeah I guess my understanding of FBWF was that it just wouldn't retain files in there upon reboot. PDQ just uses it as a temp directory anyway from what I understand, so that is kind of odd that it just quits after it successfully put the files there

Still this does not explain why the ping stops/hangs. It only explains why the files are gone after the reboot. (where original state is restored)

I would run the checkdisk on those systems. You might be dealing with some harddrive failures. You never know.

PDQ cleans up after its done. Otherwise the folder would look like a garbage store.

I think the FBWF may be deleting anything in there shortly after it is created (the pdqdeployservice folder) causing it to error. 

It stops at 3 pings, or 6 seconds of PDQ run-time, which probably corresponds to the time it takes the File Based Write Filter to force delete everything, thus ending the pdq deploy process/job 

At this point I can add an exclusion, but that requires a reboot before the PDQ job can deploy. 

So far I've noticed, it might be dependant on the "threshold" setting, which specifies the Overlay threshold in MB.

But I've worked with XP embedded system only once and it involved a different problem. I am afraid I am no help in this case. (no time fo studying FBWF)

BTW have you tried the same task (deployment of the batch) using PSExec from sysinternals? Does it behave the same way?