[doug]

Hmmm. Weird. Glad you got it working. It’s very difficult to say what the problem might be with your original computer in this case.

-Doug

[doug]

Sounds like maybe a dialog box (maybe some type of confirmation dialog asking if you want to proceed with an action) popped up behind the main BP window, and so it seemed like BP was frozen when it was actually just waiting for you to respond to the dialog? Does this happen every time you run BP or just happened one time?

The next version (to be released later this summer) of BP forces all confirmation dialogs to remain on top of the main window (along with many new features and lots of other bug fixes and performance tweaks/controls).

-Doug

[doug]

We’ll look at adding this in a for a future release.

Thanks,

-Doug

[doug]

Yes. We expect to publish this feature later in the summer. However, in the meantime you can accomplish the same thing using the Job Queue. The Job Queue allows you to string together multiple actions such as “Install Updates” and “Reboot” to guarantee that the machine is rebooted after updates have been installed.

-Doug

[doug]

Glad you got it figured out.

-Doug

[doug]

daemon8814 – is there an error.log file in the remote working directory on the target server where you experience this problem? The default location would be C:Program FilesBatchPatchBatchPatchError.log. Please post the contents of this error log. Also, it might be useful to see if there are any associated errors in the system or application log (check eventvwr) on the target system at the same time as this problem occurs.

Thanks,

Doug

[doug]

2250 appears to indicate a networking problem of some kind:

ERROR_NOT_CONNECTED

2250 (0x8CA)

This network connection does not exist.

-Doug

[doug]

We’re hoping to have this feature published in a new build later this summer.

-Doug

[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

[Author]

Posts