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

Comments

20 comments

  • SelfMan

    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.

    0
    Comment actions Permalink
  • JGQ85

    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 

    0
    Comment actions Permalink
  • JGQ85

    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?

     

    0
    Comment actions Permalink
  • JGQ85

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

    0
    Comment actions Permalink
  • SelfMan

    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.

    0
    Comment actions Permalink
  • SelfMan

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

    0
    Comment actions Permalink
  • JGQ85

    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. 

    0
    Comment actions Permalink
  • SelfMan

    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

    0
    Comment actions Permalink
  • JGQ85

    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.

    0
    Comment actions Permalink
  • SelfMan

    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.

    0
    Comment actions Permalink
  • JGQ85

    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.

    0
    Comment actions Permalink
  • JGQ85

    These are Windows XP Embedded SP2 systems 

    0
    Comment actions Permalink
  • JGQ85

    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? 

    0
    Comment actions Permalink
  • JGQ85

    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 

    0
    Comment actions Permalink
  • SelfMan

    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.

    0
    Comment actions Permalink
  • JGQ85

    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

    0
    Comment actions Permalink
  • SelfMan

    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.

    0
    Comment actions Permalink
  • JGQ85

    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. 

    0
    Comment actions Permalink
  • SelfMan

    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)

    0
    Comment actions Permalink
  • SelfMan

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

    0
    Comment actions Permalink

Please sign in to leave a comment.