unable to deploy registry key to servers

BatchPatch Forums Home Forums BatchPatch Support Forum unable to deploy registry key to servers

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #9267
    it4ever
    Participant

    for some reason I was not successfully deploying a registry key to a server. I received an “Exit Code:1”, please help.

    thanks

    #11366
    doug
    Moderator

    Did this problem occur with just a single target computer or all target computers? What are the contents of the .reg file?

    Thanks,

    Doug

    #11367
    it4ever
    Participant

    In both cases single server and multiple servers. The registry file contains SUS local policies such as SUS server info, auto update option, and etc…By the way we used DA account but same error code.

    #11368
    doug
    Moderator

    To be clear, I need to see the exact contents of the .reg file please instead of a description of the contents. If you want to modify server names and IP addresses, that’s fine, but I want to see the .reg file so that I can test the same thing here. If you are a current customer, please email us directly using the contact form on our website. Include the name on your license, so that we know who you are.

    (I won’t ask why you would publish local policies via reg key rather than push these through group policy.)

    -Doug

    #11369
    it4ever
    Participant

    Hi Doug,

    Here is the content of the registry file.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]

    “WUServer”=”http://WSUS Server:8530”

    “WUStatusServer”=”http://WSUS Server:8530”

    “TargetGroupEnabled”=dword:00000001

    “TargetGroup”=”Testing”

    [HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]

    “NoAutoUpdate”=dword:00000000

    “AUOptions”=dword:00000003

    “ScheduledInstallDay”=dword:00000000

    “ScheduledInstallTime”=dword:00000003

    “UseWUServer”=dword:00000001

    “DetectionFrequencyEnabled”=dword:00000001

    “DetectionFrequency”=dword:00000002

    #11376
    doug
    Moderator

    Will get back to you on this in a few days…

    #11378
    doug
    Moderator

    I’m not able to reproduce your issue. However, I also think that what you are experiencing might be fixed in the most recent release of BP from yesterday. We added a setting for ‘Remote Execution Context’ under ‘Tools > Settings > Remote Execution.’ I suspect that in your case if you try to execute the deployment under ‘SYSTEM’ that all will work, but when you try to use one of the other execution contexts, it will not work. That’s my best guess, at least. Try it out and let me know.

    If the above suggestion doesn’t work, then please can you paste the entire ‘All Messages’ column contents for me to review?

    Also, can you confirm that in the Deployment window you have UNchecked ‘Retrieve console output…’ ?

    Lastly, can you confirm that your ‘Command to execute’ field reads like this (name of the .reg file might be different, of course):

    regedit.exe /s "wu.reg"

    #11379
    it4ever
    Participant

    lets me try to upgrade to the latest version and i’ll post the update. Thanks

    #11391
    it4ever
    Participant

    Doug,

    I updated the version of BatchPatch to 2016.9.14.14.23 from 2016.7.7.14 and we still couldn’t deploy the registry file to the server. Below is the message from the log.

    Deployment

    regedit.exe /s “wutest.reg”

    All Messages

    Mon-14:18:08> Deployment: Exit Code: 1

    Mon-14:18:08> Deployment: Executing \testserver -s -w “C:Program FilesBatchPatchtemptemp” regedit.exe /s “C:Program FilesBatchPatchtemptempwutest.reg”

    Mon-14:18:08> Deployment: Copying file(s) to testserver …

    Mon-14:18:08> Deployment: Queued file copy operation…

    Mon-14:18:08> Deployment: Establishing connection…

    Mon-14:18:08> Deployment: Queued…


    Here is the command that we executed in BatchPatch, regedit.exe /s “wutest.reg”

    #11392
    doug
    Moderator

    I wonder if there is an issue with PsExec on the computer that you’re currently using to run BatchPatch?

    Do other BatchPatch actions work?

    What happens when you try ‘Actions > Windows Updates > Check for Windows Updates’ Is it successful?

    What happens if you try to run PsExec from the command prompt (without BatchPatch) and just try a command like this:

    PsExec \targetComputer IPCONFIG

    What happens if you run the BatchPatch console on a different computer?

    -Doug

    #11393
    it4ever
    Participant

    I was able to restart the server but not “check for available updates” action, I received “error 1611:1. Failure”. And I was not able to run ipconfig through psexec, I received and error say that “the term \testserver ipconfig is not recognized….”

    Here is my command: cwindowspsexec \testserver ipconfig

    #11394
    it4ever
    Participant

    Doug,

    Ignore the command error above. I was able to run the command successfully in cmd, I didn’t use the right powershell .exe

    #11395
    doug
    Moderator

    It’s not clear to me what’s going on here, but it seems that something is not working with PsExec on the computer you are trying to use BatchPatch. And since PsExec is not working properly, BatchPatch is not able to successfully utilize PsExec for any operations that it uses PsExec for.

    I don’t understand your last comment about powershell.exe, as I didn’t request you to do anything with powershell.exe, and powershell.exe should not be used to test because it is not used by BatchPatch or PsExec for the .reg deployment or the Windows Update actions.

    I would suggest you try running both PsExec and BP from a different computer. Make sure you don’t have any HIPS or AV software that would be preventing PsExec from running on the BP console computer.

    -Doug

    #11397
    doug
    Moderator

    He emailed me that he ended up resolving by extracting the latest version of psexec into his C:windows folder.

    -Doug

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