Use Paexec instead of Psexec

BatchPatch Forums Home Forums BatchPatch Support Forum Use Paexec instead of Psexec

  • This topic has 5 replies, 2 voices, and was last updated 8 years ago by doug.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #9282
    gene12517
    Participant

    Paexec seems to work on the remote server, but I keep getting an error with Psexec (windows could not start the psexesvc service on local computer the system cannot find the path specified).

    Is there a way for BatchPatch to be configured to use Paexec?

    #11406
    doug
    Moderator

    Close all instances of BatchPatch. Then in HKCUSoftwareBatchPatch change the REG_DWORD isPsExec to 0. Then launch BatchPatch. That will work.

    Alternatively you can just rename paexec to psexec.

    #11407
    gene12517
    Participant

    I am launching psexec remotely to test a server that is giving me an error in batchpatch. psexec doesn’t work, but paexec does. Your suggestion above did not help. I still see the error when running batch patch.

    The sever is a VM running W2K8 SP2.

    All Messages

    Mon-12:27:42> Windows Update: Error 1620: 3. Failure

    Mon-12:27:42> Windows Update: Failed to obtain result. Could not find file ‘\HDCP-REDACPROC1C$Program FilesBatchPatchBatchPatchTempResult.log’.

    Mon-12:27:37> Windows Update: Executing BatchPatchRemoteAgent.exe…

    Mon-12:27:35> Windows Update: Attempting to initiate Windows Update (Action: Download and install updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …

    #11408
    doug
    Moderator

    Gene – To be clear, I didn’t make a suggestion. I simply responded to your question about how to use PaExec instead of PsExec in BP.

    I don’t know what you mean when you say “I am launching psexec remotely to test a server…” Could you clarify *exactly* what you are doing/testing? PsExec should not ever be launched “remotely” as it needs to run locally on the same machine that is running BatchPatch.

    If you have an error with just a single target server, then it’s unclear what might be the issue though it seems specific to that particular server since other servers are working normally/properly. It may have something to do with psexec/paexec, but it might not. However, if you have an error with any/all target servers, then it seems to be an indication that there is a problem with the computer that is running BatchPatch.

    At this time I don’t fully understand exactly all of the things that you are trying and experiencing. Is BatchPatch working properly to patch target servers with the exception of the single target computer you are experiencing the error on? The more clearly you can explain in step by step detail of what you are trying and what you are experiencing, the more likely I’ll be able to understand and help.

    -Doug

    #11420
    gene12517
    Participant

    This one particular server is having an issue. I get the above error about not finding the batchpatchtempresult.log file. I am testing from my batchpatch machine. See below from a command prompt on my batchpatch machine. psexec doesn’t run with the below error, but paexec seems to work when connecting to the HDCP-REDACPROC1 server from my batchpatch macine. That is what I meant about testing. I tried the reg edit, but I don’t think batchpatch used paexec instead of psexec on HDCP-REDACPROC1.

    Hope this is clearer now.

    Microsoft Windows [Version 6.1.7601]

    Copyright (c) 2009 Microsoft Corporation. All rights reserved.

    C:Users>psexec \hdcp-redacproc1 cmd

    PsExec v2.11 – Execute processes remotely

    Copyright (C) 2001-2014 Mark Russinovich

    Sysinternals – http://www.sysinternals.com

    Could not start PSEXESVC service on hdcp-redacproc1:

    The system cannot find the path specified.

    C:Users>paexec \hdcp-redacproc1 cmd

    PAExec v1.26 – Execute Programs Remotely

    Copyright (c) 2012-2013 Power Admin LLC

    http://www.poweradmin.com/PAExec

    Connecting to hdcp-redacproc1…

    Starting PAExec service on hdcp-redacproc1…

    Microsoft Windows [Version 6.0.6002]

    Copyright (c) 2006 Microsoft Corporation. All rights reserved.

    C:Windowssystem32>

    #11421
    doug
    Moderator

    Thanks for the additional info and clarifications. With just one particular server having a problem with psexec, I don’t really have a great solution for you, unfortunately. Every once in a great while we here of a customer with a psxec issue on a single target server, and there never seems to be any rhyme or reason to getting it working again. We have had a couple people who simply updated the psexec version to the latest, and then all of a sudden it started working. We have had a couple people who downgraded the psexec version (usually to v1.98 if you can find it) and then all of a sudden it started working. Using paexec instead of psexec could possibly work too, but possibly not. We have also heard of it spontaneously just starting to work with no apparent changes made. And we have heard of it working from a different source computer where you simply run psexec from a different computer instead of the one that you’re currently using as the source.

    With regard to the registry key to change BP to using PaExec instead of PsExec, it definitely does work as we use it all the time for testing. You can ensure it’s working by simply removing any copy of psexec that you have, so you’ll know if psexec is not even on the system, paexec is the one that is being invoked. You can also watch in realtime the processes list in task manager on the BP computer or with other tools or on the target server task manager processes list etc. Additionally, if you for some reason you have problems, you can also simply remove psexec and then take paexec and rename it to psexec, and that will work too from BP.

    However, of course if you get paexec being used by BP that won’t guarantee that it will fix your problem, unfortunately.

    I hope this helps a bit.

    -Doug

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.