[doug]

Thanks for the suggestion. We’re hoping to implement something like this soon.

-Doug

[doug]

Sounds good. Let me know how it goes.

Thanks,

Doug

[doug]

This is not a psexec issue. BatchPatch uses multiple methods for authentication beyond just psexec, due to some special requirements it has. And so when you test psexec directly at the command line it works fine, but when you use BatchPatch in this scenario, access is denied. When you’re using BatchPatch in a WORKGROUP (NOT in a domain) environment, there are special considerations to pay attention to. Please see below.

---

Special Considerations for BatchPatch Authentication in a WORKGROUP:

1. The built-in local administrator account on all computers in the WORKGROUP must be set with the exact same password. Note that I’m referring to THE account named “administrator.” It is not sufficient to use an account with a different name, even if that different account is a member of the local administrators group)

2. The computer that you use to run BatchPatch must be logged on with this built-in local administrator account.

3. BatchPatch must be set to use Integrated Security. Do NOT use alternate credentials within BatchPatch when you’re working under these circumstances.

If the 3 above steps are followed, BatchPatch will work in a WORKGROUP environment. This was tested on 5/31/2013, running BatchPatch on a Win 7 machine with a Win 2008 target, and then also running BatchPatch on a Win 2003 machine with a Win 2008 target.

-Doug

[doug]

This is currently not possible in BatchPatch. We’ll consider it for a future build.

However, there are 2 ways you can accomplish something similar today. One option is to just use the scheduler to launch the job queue on one host/row 15 minutes after you reboot another host/row. A second option is to use the row execution interval. Set it to something like 900 seconds, which is equal to 15 minutes. Then highlight the rows in the order you want them to execute. The first row that you highlight in the sequence will execute 15 minutes before the second.

-Doug

[doug]

I sent you an email directly so that we may more easily continue troubleshooting this problem. Looking forward to your response. Once we solve the problem, I will post an update to this thread.

Thanks,

Doug

[doug]

Thanks for sharing! Glad you got it working.

-Doug

[doug]

Is it the same hosts that exhibit this behavior every time, or does it seem random?

How many hosts are you doing simultaneously in the grid?

Are you running multiple instances of BatchPatch simultaneously and patching hosts in all grids at the same time? If yes, how many instances total, and how many hosts in each instance?

Are you using a saved .bps file to load hosts in the grid? If yes, would you please re-load the hosts into a new BatchPatch instance from scratch (either use a plain text file or just manually paste them into the Add Hosts dialog, but do NOT load an existing .bps file). Let me know if doing this makes the issue go away or not.

Thanks,

Doug

[doug]

Thanks for the heads-up. It’s unclear why this is happening, but we’ll look into it. Does this happen frequently? Is it only when downloading updates or does it happen during installation too? The good news is that it should only be cosmetic, and shouldn’t cause any problems with actual functionality.

-Doug

[doug]

Thanks, Jaga. We’ll look to add this to a future build soon.

EDIT: This feature has been published

-Doug

[doug]

Has anything at all on your wsus server changed? Does the windowsupdate.log file have anything that’s might indicate a cause? If you manually install updates on one of the problem systems and reboot, do you still see the same behavior in BP? I’m not quite sure what to make of this problem. You should be able to figure out if the issue is on the clients or on the Wsus by temporarily pointing a client to a different wsus or to Microsft update, and then see what happens with BP. Also, if you do “install downloaded updates” even if there are no updates downloaded, does this throw an error? I predict it won’t because the client will not do a search on the wsus in that case and will only scan the actual client to see if it has any updates downloaded. This points to a problem or config issue of some kind on the wsus.

[doug]

Could you provide me with the HRESULT code? You’ll find this in the error.log file in the remote working directory on a server that has thrown the -102 error.

Thanks,

Doug

[doug]

Well, currently BatchPatch only supports using the update location that the server is configured for, which is why you’d have to change the target server’s configured update location in order to get BatchPatch to do what you need/want. However, you’re right that it’s a relatively quick switch, in that we’ll be able to change the code to give you the option to use either the configured location or Microsoft Update. Coming soon…

Thanks,

Doug

[doug]

Thanks, Jason!

[doug]

Currently you’d have to change the registry entry on the target computer that controls where it receives updates from, then run BatchPatch, then change the reg key back to what it was before. However, we plan to release built-in functionality for this in a future build, likely to be published in early summer.

-Doug

[doug]

Thanks. If you have new build notifications enabled in Tools > Settings, then you will see this information automatically when a new build is released. If you don’t have “automatically check for updates” enabled, then you can see this info under Help > Check for updates at any time.

-Doug

[doug]

I don’t understand what you are asking for. What are “regular patchnotes?”

-Doug

[doug]

Thanks for the suggestion, Tomas. We will plan on adding this soon.

-Doug

[doug]

You’re welcome Andi. I’m real happy to hear that you like the tool!

-Doug

[doug]

Hi Andi – you found a bug, which is now fixed in the 2013.3.21.20.10 build I just published a few minutes ago.

However, even though there was a bug in the software, you might still consider an alternate way of accomplishing what you’re trying to do.

In the way you’ve described doing this, you would end up copying the file from a network file share, down through your computer running BatchPatch, and then up to the target computer location. This will work fine, but for large files it might not be ideal to have your computer act as a middle-man for the file transfer, especially if you’re trying to do this for many target computers at once.

Instead you might consider using the “Remote Script/Process” with a command like this:

xcopy \someNetworkSharefolderfile.txt c:folderOnTargetComputer

This will execute the xcopy command on the target computer instead of the local computer running BatchPatch. So, the target computer will then directly reach out to the network share and copy the file back to itself, without the file ever having to be pulled through the computer running BatchPatch.

Hope this helps.

-Doug

[doug]

Using BatchPatch With Windows Firewall

[doug]

BatchPatch Ports For Enterprise Firewall ACLs

[doug]

Thanks, Xenophane. This is coming in a future build. In the meantime you can use the WSUS_ConsoleAppQueryTool.exe, which is packaged in the batchpatch.zip file that we publish on our website at the BatchPatch Download Page, to retrieve this information for all computers.

The WSUS_ConsoleAppQueryTool allows you to query your WSUS server directly to find out which machines are pending reboot, which machines have downloaded updates waiting to be installed, and which machines haven’t checked-in with your WSUS server in X days.

-Doug

[doug]

We’ll consider this for a future build.

Thanks,

Doug

[doug]

I emailed you directly so we can trade screenshots.

-Doug

[doug]

I’m trying to decipher what you’ve written. Are you saying that there is a problem on one particular target host? Or are you saying that all target hosts have a problem? On the target host can you look in the remote working directory (typically c:program filesbatchpatch) to see if there is anything more detailed in the batchpatch error log or the batchpatch.log ?

-Doug

[doug]

Thanks for the suggestion, pausen! We plan on adding this in a future build.

-Doug

[doug]

Miguel – You can do this under Tools > Options > Remote Agent Settings.

-Doug

[doug]

Laurie – thanks for your business. As you can imagine, BP was originally designed with specific requirements. It was to be a real-time tool that was portable and could be launched many times in one session. These fundamental requirements are not particularly compatible with running it as a service. However, we have been toying with some clever ways to make running it as a service an option. And while it likely won’t happen in the very near future, we might move in this direction at some point down the road.

-Doug

[doug]

The current build of BatchPatch does not support this, but we can look to add it in a future build. Thanks for the suggestion.

-Doug

[doug]

Interesting. I’m glad you got it working!

-Doug

[Author]

Posts