[doug]

OK, thanks for the info. The logs you sent are not consistent with what you’re describing. What I mean to say is the log that errors with 1610 is erroring and then exiting BEFORE execution of the BatchPatchRemoteAgent.exe ever occurs. Yet, you’re telling me on the other hand that you’re seeing execution take place (this is confirmed by the appearance of “Searching…” and “Executing BatchPatchRemoteAgent.exe” in the console as well as the 3 .log files appearing in the target working directory. I’ve emailed you so that we can try to get things figured out.

-Doug

[doug]

These all sound related though strange/unexpected.

First, please make sure you are only running one action at a time per target computer. Running multiple actions at the same time against the same target can, in some cases, produce weird results when one action severs a connection and ends up killing a different action in the process.

Second, do you have any type of anti-virus or intrustion protection/detection software running on the target machine or on the BatchPatch computer?

It seems like something is interrupting either psexec and/or the BatchPatchRemoteAgent that runs on the target. I would start by examining any software that is running on the target that could possibly be doing something along those lines. Try disabling or uninstalling (or testing on a machine that doesn’t have the same app installed) to rule it out.

The ‘Access Denied’ message does indicate a permissions problem, but I could also believe that it’s related to the other errors. Certainly it’s the case that under normal circumstances the domain admin would have local admin permissions on the target, but you should still verify the permissions to be sure.

It sounds like you’re using “run-as” to run the entire BatchPatch.exe as a domain admin user, yes? Could you try running as your regular logged on user and then input the alternate credentials into a BatchPatch row in the grid for the target host? Does this make a difference (it shouldn’t, in theory, but let’s see). Another test would be to log on to your computer with the domain admin credentials and then run BatchPatch without using run-as and without entering alternate credentials. Let me know what happens.

When you execute BatchPatch, try watching the target computer’s working directory (C:Program FilesBatchPatch). You should see the BatchPatchRemoteAgent.exe appear and then you should see several temp/log files appear that are created by the executing BatchPatchRemoteAgent.exe. Let me know if you do or don’t see this happening.

Also, please watch the processes list in task manager on the target. You should see the BatchPatchRemoteAgent.exe as well as psexesvc.exe. Do you see these or not?

Lastly, please check the services on the target machine. Normal psexec behavior is to install a temporary service called psexesvc, which lives for however long the process runs, and then it is removed. Does this service get orphaned on the target instead of being removed? If it is orphaned somehow, that could be why you get different error the second time around. If that’s happening, try removing it with these two commands.

sc.exe stop psexesvc

sc.exe delete psexesvc

What is the percentage of your targets that you’re seeing this behavior on? Or is it just a single one?

-Doug

[doug]

New Cached Mode / Offline Mode options for deploying updates to computers that do not have internet access: Cached Mode and Offline Updates

For deploying multiple MSU files, I’ve posted a tutorial here: Remote Script Deployment – Install Multiple MSU Files In A Single Action On Remote Computers

[doug]

Thanks for your interest in BatchPatch. You’re in luck because we have a whole ‘offline update’ feature coming out very soon, probably within the next 8 weeks, that will enable very easy updating of machines that have no access to the internet or a WSUS. Keep your eye out for it.

In the meantime, to accomplish your goal you can put all of your MSU/MSI/MSP/EXE etc files in a single folder. In that same folder put your script that installs the files. Then, using the Deployment action in BatchPatch, deploy the script to your target machines and check the box to “copy entire directory.” Then when you execute the deployment, the entire folder of MSU/MSI/MSP/EXE files will be copied to the target hosts with the script, and the script will be executed, which will then install all the files.

I hope this helps.

-Doug

[doug]

We have seen this problem caused by an old psexec process still running/hanging. Once the old process is killed, the new BatchPatch action is able to complete successfully.

[doug]

Thank you for the suggestion. We will consider this for a future build.

-Doug

[doug]

Hi Erwin – I emailed you directly so that we can continue troubleshooting.

Thanks,

Doug

[doug]

Well, you might be able to accomplish this, but there are some caveats.

The Deployment feature of BatchPatch will not allow you to execute the remote process interactively.

However, Remote Commands 1 and 2 do support psexec switches, and so they WILL let you specify the -i switch to execute processes interactively. That said, the file to execute would have to already exist on the target machine (or you might be able to use the psexec -c switch to get the file there – haven’t tested it).

There are a couple of things to be aware of if you try this…

First, if you use -i without also specifying -d, then psexec and consequently BatchPatch will wait for the process to complete. You probably don’t want this, so you would generally want to use -d in addition to -i. When you do this the exit code that appears in BatchPatch should be the PID of the remote process.

Second, the way Windows deals with multiple desktop sessions can give you unwanted results. For example, if you use -i to execute a process interactively on a non-server OS, like Windows 7, it will work as expected if you’re sitting at the console. But if you are using an RDP session to the Windows 7 machine, you probably will not see the process, and instead it will still run hidden. On a server OS you might be able to deal with this by connecting to the console session using the /admin switch in the RDP client. However, I’m not positive if this will work, so you’ll want to test.

I hope this helps.

-Doug

[doug]

You have two options. Either create a list of updates to install that includes all but the one update, or use the “hide” action to hide the one bad update. Once it has been hidden, you can install all remaining updates visible updates with the normal “download and install updates” action. See Method 1 and Method 2 outlined here:

Remotely Install Only A Subset Of Available Windows Updates

-Doug

[doug]

Erwin – thank you for all of this additional information. The behavior is VERY peculiar. It’s especially weird that things work properly over your VPN connection but not on the LAN. This makes me wonder if the issue is possibly related to your DNS configuration. I would suggest trying to use the IP address instead of the computer name in the BatchPatch grid. Let’s see what happens in that case. If it works properly, then the issue is likely to be with your DNS configuration. If it produces the same error, then we would know that the issue is probably not related to DNS.

When you said that the issue does not occur over the VPN connection, are you using the same source computer to run BatchPatch or are you running BatchPatch on a different source computer? I understand that the target computer is the same in these tests, but perhaps the issue is related to the computer that is running the BatchPatch console and NOT the target computer? Is there some application that runs on the source computer that could be responsible for briefly severing the network connection?

-Doug

[doug]

Erwin – It does sound like the Symantec Threat Protection could be the culprit. I understand that some servers that have this software are not having a problem, but it could just be a timing issue (timing of how long it takes for the threat protection to sever the connection vs how long it takes for the Windows Update action to complete on the server), with some servers completing quickly enough to avoid being killed by the Symantec app. Let me know how it goes.

-Doug

[doug]

Hi Erwin – 1611 is a BatchPatch internal code, not a system error code. The important number here is the 64, which means

ERROR_NETNAME_DELETED

64 (0x40)

The specified network name is no longer available.

The questions I have for you are:

1. What version of BatchPatch are you using? Does the problem occur with the latest version of BatchPatch?

2. Are you using Integrated Security or are you specifying alternate credentials for the hosts in question?

3. What OS are you running BatchPatch on?

4. What OS is running on the problematic target host?

Something appears to be causing the network connection to be severed before BatchPatch finishes its work. However, it’s unclear what that might be. Maybe some type of host intrustion protection software running on the target? I’m not sure.

Thanks,

Doug

[doug]

The uninstallation method used by BatchPatch invokes WUSA.exe, which does not exist on Windows 2000, 2003, and XP.

You can uninstall an individual update on these OSes by executing a ‘Remote Command’ action in BatchPatch with the following syntax:

C:WINDOWS$NtUninstallKB1234567$spuninstspuninst.exe /quiet /norestart

[doug]

This is definitely an odd issue. There is either an problem with the update file itself or with the windows updates database information about the particular update. You might have success in fixing the problematic update if you stop the wuauserv service, then rename the C:WindowsSoftwareDistribution folder, then start the service.

However, as a workaround for right now, I believe you should be able to hide the particular problematic update using BatchPatch Windows Updates > Hide/unhide action, after which you would then be able to continue installing all the other updates. You can later unhide it if you wish.

Separately, in the next release of BatchPatch we will modify the code so that instead of failing to install all updates, when an issue like this is encountered it will simply skip the problematic update and continue installing the other updates (in most cases it already does skip issues like this, but for this particularly case it does not, apparently).

Thanks

Doug

[doug]

camadatacom – jday_23 never responded to my email, and no one else reported it, so we were unable to test or troubleshoot further. I will email you so that we can work on the issue more directly.

Thanks,

Doug

[doug]

Thank you for reporting this error. It has been fixed in the build published 8/13/2014.

Thanks,

-Doug

[doug]

The only other currently available method for export of the grid would be to just highlight the entire grid and use ctrl-c to copy it. You could then paste it into Excel and do whatever you want with it from there.

Additionally, you could save the grid to a .bps file using File > Save. The .bps file is pure xml, which means that it can be loaded into a spreadsheet app like Excel, or a database.

We are considering more options for a future version, including database interaction of some kind. However, at the moment this is not available in the currently published build, and I’m not sure what the timeline is for it to become available or if it will definitely become available.

-Doug

[doug]

The consolidated update history report is designed to simply report what updates have been installed/uninstalled on target hosts. If you want the actual BatchPatch activity for a given session, you can export the actual BatchPatch grid to a .html file. When you initiate a Windows Update action in BatchPatch, the log info that is written to the BatchPatch.log file is also written to the Remote Agent Log column in the BatchPatch grid. If you make sure that this column is visible and then select File > Export grid to HTML file, you’ll get the information you’re looking for.

I hope this helps.

-Doug

[doug]

I emailed you directly to troubleshoot the issue.

Thanks,

Doug

[doug]

Hi DJ – the tab names are based on the saved .bps files. So if you simply save a tab to a .bps file, the tab name will take on the actual file name. Does this suffice for your needs?

[doug]

1. Highlight your hosts in the grid and select Actions > Execute remote process/command > Create/modify remote command 3 (logged output)

2. In the command window type the defrag command that you want, such as: defrag c: -v and then click OK.

3. With the same hosts still highlighted, select Actions > Task scheduler > Create/modify scheduled task

4. From the task drop-down list in the scheduler window, select Execute remote command 3 (logged output), and then select the run time and recurrence options that you would like. Then click OK.

5. The last thing you need to do is enable the scheduler. Click on the small clock image in the upper right corner of the BatchPatch window to enable the schedule.

[doug]

Yes, it will support PowerShell scripts too. We expect it will be published probably within the next 6 weeks.

Thanks,

Doug

[doug]

Hi Lee – We’ll do some more testing here to see if we can reproduce it and also determine why it’s happening. Thanks for the additional info. I’ll contact you and post more info in this thread if/when there is anything to report.

-Doug

[doug]

Hi Lee – This is unexpected. The Windows Update Agent maintains the database on each machine that contains the information about what updates have been installed or uninstalled. In the case of the “Uninstall individual update” action, BatchPatch uses WUSA.exe to uninstall the update. In the Update History Report, “wusa” would normally appear in the ‘Application’ column next to the entry for the uninstallation of the update. I don’t know why it wouldn’t show in your case. Outside of rebooting the machine after the uninstallation to make sure that the uninstallation is committed to the database, the only other thought I have is that perhaps you weren’t sorting properly in the Update History Report and maybe you were expecting to see the ‘Application’ as BatchPatch when in reality it will be listed as ‘WUSA’ ? BatchPatch doesn’t actually commit changes to the database itself. The Windows Update Agent makes the changes. I’m sorry to say that I’m unsure why that change wouldn’t have been committed in your case.

-Doug

[doug]

Hi Eric – please read through the details of this thread. Error 2 Very Often – Server 2012 R2

Let me know how it goes…

Thanks,

Doug

[doug]

Strange. BatchPatch retrieves the LastBootUpTime and LocalDateTime properties from Win32_OperatingSystem to calculate the uptime. Somehow the machine was in a state where Win32_OperatingSystem wasn’t reporting the correct values, but I have no idea why/how. I’ve never seen that happen before. Glad to hear that rebooting fixed it.

-Doug

[doug]

Hi Stuart – It sounds like you’ve got everything configured the way that it needs to be. If the firewall is disabled on the destination computer and the RPC service is started, then there is no (logical) reason for you to receive “RPC server is unavailable.” So, you may be correct that there is a timeout issue. Or perhaps there is some type of other issue such as the one described here: https://support.microsoft.com/kb/935677

I wish I had another suggestion, but unfortunately it really does sound like you have everything configured properly, so I’m not sure what else to make of it. You might consider checking in the target computer’s event log to see if there are any indications of what might be happening or if a connection is ever being attempted. Another thing you could try is to run a packet capture utility like Wireshark on the target system to see if you see the connection attempt.

-Doug

[doug]

The way this will be addressed in the next build is through the Deployment action. You will be able to choose “Actions > Deployment” to deploy a script just like you can already do, but there will be an additional checkbox to “retrieve logged output.” When that box is checked, not only will BatchPatch copy the script from wherever it’s located to the target computer for execution, but upon completion the output of the script will be returned back to BatchPatch for viewing.

-Doug

[doug]

Note – PsExec v2.1+ now uses an encrypted channel for communication between the source and destination computers. Passwords are NO LONGER sent in clear text, which is very cool. This means that using alternate credentials in BatchPatch is no less secure than using integrated security.

-Doug

[doug]

Thanks for letting us know about this. We’ll see what we can do to address it in the next build.

-Doug

[Author]

Posts