[doug]

Sounds good. Thanks.

[doug]

This “Open File – Security Warning” window has nothing to do with BatchPatch. This is a Windows security warning that appears because you trying to run a file (psexec.exe) that you downloaded from the internet.

To stop the box from appearing, uncheck the “Always ask before opening this file” box.

[doug]

Hi Gonzo –

This certainly does seem odd, but there are still some outstanding questions you didn’t answer…

For example I don’t know whether your manual update process had already downloaded the updates before you installed them or if it performed a download plus install like you did with BP.

I don’t know whether you updated from WSUS both times or if you updated from WSUS when you did the manual update, but you updated from Windows Update or Microsoft Update when you did the BP test.

If you’re interested in performing the test a second time, I would like to have you save a copy of C:WindowsWindowsUpdate.log on the target computer before and after the update process for both tests (so a total of 4 WindowsUpdate.log files), and then email me the log files for review to see if I’m able to determine what might be the cause of the speed difference.

Thanks,

Doug

[doug]

Gonzo – There is no reason that I can think of why this would be happening. We have not experienced this behavior before nor has anyone ever reported it. Furthermore, BatchPatch utilizes the Windows Update Agent to download and install the updates, so the process that it runs is virtually identical to the process that is run when performing manual Windows Update directly on the target computer, so there isn’t really anything in the process that should/would cause it to be slower than manual update.

I’d like to confirm first that you are not using BatchPatch in ‘cached’ mode or ‘offline’ mode. Both of these modes are definitely slower than the default mode. In a WSUS environment, neither of these modes is recommended.

Is the WSUS server the same server that is being used by the engineers to run BatchPatch?

How many target computers are being updated simultaneously?

How many engineers are performing these updates, and are the engineers working on the same management server at the same time?

Do you pre-stage the download portion of the updates to the target computer (either with GPO or with BatchPatch) or do you typically initiate the download+installation all at the same time with BatchPatch?

How did you determine that it’s slower using BP than direct update? What I mean to say is did you do a controlled test? Or are you just estimating? If you are estimating, there are a lot of variables I can think that could make it difficult to really know the truth about the performance comparison if you didn’t do a controlled test.

For example, did you install the exact same updates on the control as you did on the test target? Some updates take much longer to install than others.

Did you download + install on both or did you download + install on one and just install without download on the other? Of course if one included a download but the other was just an install, then the one that performed the download would take longer.

Did one install the MSRT and one not install the MSRT? The MSRT installation takes a long time because it does a real-time scan for malicious software right when it is installed, and the update process is not complete until that scan completes.

When you were doing manual update, presumably you couldn’t do all servers at the exact same time. When you use BatchPatch, are you doing all servers at the same time? If they are all downloading from the WSUS server at the same exact time, this could certainly create a bottleneck that wouldn’t exist when manually updating one server at a time. This is why it’s recommended to pre-stage the download portion of the updates (ideally just using GPO), so that when it comes time to perform the installation you are able to use “Install downloaded updates” which does not involve a query to the WSUS server, and therefore wouldn’t create a bottleneck.

-Doug

[doug]

Rob – You’re using an older version of the software. Please update to the latest version with ‘Help > Check for updates.’

You can execute the job queue from the scheduler in 2 ways.

1. Create a job queue and choose the option to “Apply queue to row(s) without executing.” Then go to the scheduler and schedule a job to “Execute job queue.”

2. Create a job queue and “save” it in the job queue window with a title. Then go to the scheduler and execute the task using the title that you created when you saved the job queue.

Thanks,

Doug

[doug]

I agree that it would certainly be most likely to be something like an AV app or some other similar HIPS/security app that has to really embed itself in the OS in order to work properly.

15% of systems is a lot, so I can understand that it would be time consuming. However, just to give you an idea of my perspective on things, I cannot recall a single time in my entire career where I had to use selective startup to get Windows Updates to be successful. And then also from the BP perspective, we have never had a support ticket where the resolution involved that. I make these points only to highlight that what you’re experiencing is by no means expected or normal behavior, as far as I’m concerned.

Good luck with the troubleshooting.

-Doug

[doug]

Hi Mike – This is a peculiar one. My best guess is that maybe you have a DNS issue? I wonder if what might be happening is you have multiple DNS servers in play, and one of them has stale information for that computer? And so maybe when you attempt to execute the process remotely, sometimes BatchPatch reaches out to the correct computer, but other times it gets sent to the wrong location. One way to test this would be to use the IP address in BP instead of the host name. And then of course you would want to take a look at your DNS servers.

Let me know how it goes.

-Doug

[doug]

Hi Jason – Thank you so much for all the feedback. We really appreciate it.

I think I understand all of your suggestions, but I want to just clarify that I understand what you mean by “work spaces.” I think you’re essentially just saying that you want to have multiple users be able to be logged on to the computer that runs BatchPatch at the same time, and you want all of them to be able to view the same grids and perform actions on those grids. Is this correct? Or when you say “work space” do you mean something different?

Other items you’d like to see are:

*Different licensing model

*Security roles that would allow some users to have more abilities than others. Some roles could be more restricted such that they can be prevented from executing certain actions or perhaps even be prevented from viewing certain grids altogether as well.

If there’s anything else, please let me know. We will definitely consider all of your suggestions.

Thanks,

Doug

[doug]

Jason – I have to admit that I’m somewhat shocked that you find yourself having to do a selective startup “often” or even just “sometimes” to get Windows Updates to install. I don’t find that to be normal or expected for most environments, and my immediate reaction is what third-party apps are you guys running? (you don’t have to answer that) Seems like maybe there is one app, in particular, that could be the source of most of these types of problems for you. That’s just a guess.

In any case, we will consider options for how this might be able to be integrated into BP. Thank you for the suggestion.

-Doug

[doug]

While I don’t understand what you mean when you say “Path Execution Job” or “execution type deployment,” I do understand what you wrote about your SQL and IIS servers. If you want to have one server be updated, rebooted, and then come back online before the second server begins updating, you can accomplish this with either the ‘Basic Multi-Row Queue Sequence’ or the ‘Advanced Multi-Row Queue Sequence.’

Here are a tutorials explaining how to use them:

Basic Multi-Row Queue Sequence Tutorial 1

Advanced Multi-Row Queue Sequence Tutorial 1

Advanced Multi-Row Queue Sequence Tutorial 2

-Doug

[doug]

OK, sounds good. Thanks for the update.

-Doug

[doug]

jeffy – Thanks for mentioning this. Unfortunately I’m not able to reproduce the behavior. Ctrl-A works as expected for me, and when I execute actions after pressing Ctrl-A, the commands are executed on all rows.

Are you able to reproduce this consistently? What OS are you running the app on?

Thanks,

Doug

[doug]

booster – Obviously we kept this functionality very simple in the current build. It’s a straight export/import right now, so it’s not currently looking to prevent duplicates. At some point we’ll update this to have more options, but for now we just wanted to get the functionality in there and working so that people could use it. We’ll tighten it up later.

-Doug

[doug]

Currently the only known cause of the following error:

Error: 0. HRESULT: -2147024894

is that PsExec cannot run successfully on a server that has Mandatory User Profiles: https://msdn.microsoft.com/en-us/library/windows/desktop/bb776895%28v=vs.85%29.aspx

When running a simple test of PsExec at the command line when Mandatory User Profiles are in use, such as:

psexec \targetcomputer IPCONFIG

The expected error that occurs is something similar to:

Error deriving session key:

The profile for the user is a temporary profile.

When BatchPatch tries to operate on a machine that has Mandatory User Profiles, it will return with this error:

Error: 0. HRESULT: -2147024894

[doug]

Booster – Are you *sure* that you were getting this *exact* same error? I suspect that the error you were experiencing included the same HRESULT but not the same error number — something like “Error: 2. HRESULT: -2147024894” but not specifically “Error: 0. HRESULT: -2147024894”

[doug]

I’m going to send you an email to troubleshoot further.

-Doug

[doug]

Do you at least have any idea how many machines you are seeing this error on vs your total number of machines? It would be good to get some sense of what the overall percentage of machines are doing this.

The issue has nothing to do with ‘2008 Standard x86’ vs ‘2008 R2 x64.’ I say this because we have customers all over the world patching tens of thousands of 2008 R2 x64 machines who are not experiencing this problem. I believe the issue is likely to be occurring as a result of a particular patch or application being installed on the system, and somehow it’s affecting BatchPatch’s ability to perform its tasks.

Since I am not currently able to reproduce it, I think your best bet is to look at one of your 2008 R2 x64 machines that is NOT having the problem, and then compare it to one of your 2008 R2 x64 machines that IS having the problem. If you can find a certain set of Windows Updates that are installed on the problematic machine that are not installed on the working machine, then you can either remove them one by one, testing BP in between each one, until you determine which update is causing the issue. Or you can install the missing updates, one by one on the working machine, testing BP in between each one, until you determine which update is causing the issue. If you are able to narrow it down and provide me with a suspect KB number, I can then test that here to see if I can reproduce it. If I’m able to reproduce it, we should be able to fix it. Currently you are the only customer to have reported this issue. If the issue is affecting other people, we will hear about it soon enough. However, if it’s isolated to your own systems, then it could be tougher to track down a cause.

-Doug

[doug]

This is very peculiar. Approximately how many machines are you seeing this on? Approximately what percentage of your total number of machines does this include? Considering that this appears to be a new problem for you, I wonder if the issue was somehow introduced during your last Windows Update session. I think it’s plausible that one of the updates that you installed last maintenance window is the reason that this is occurring. Would you be able to list out the KBs that you installed in your most recent update session? If I can reproduce the issue by installing the update that caused it, then we should be able to fix it.

Thanks,

Doug

[doug]

Can you confirm what version of BatchPatch you are currently running? We were seeing this occur last year in July 2014, but we fixed it in August 2014. If you are not running the latest version of BatchPatch (2015.5.7.x.x), please make sure to update and then try again. Let me know what happens.

Thanks,

Doug

[doug]

I’m guessing the issue is that you are copying hosts from an Excel sheet instead of just typing them in or copying them from a text file? In the last release of BatchPatch we made a slight change to how new hosts are parsed from the “Add hosts” dialog, and part of that change [accidentally] made BatchPatch worse at stripping off extraneous characters such as tab characters (t). When you copy hosts directly from Excel, for example, it adds hidden t chars to the end of the host names. This is why BatchPatch can’t ping those hosts. The good news is that we have fixed this in the next release, which will be published pretty soon (probably within a couple weeks). However, in the mean time the solution is to copy host names from a text file instead of something like Excel, or to manually type in the host names.

Let me know how it goes.

-Doug

[doug]

Mats – The current behavior during a deployment depends on whether or not the “Leave entire directory contents” is checked.

If “Leave entire directory is checked” BatchPatch does *not* create a sub temp folder under the target working directory. BatchPatch will place files into the directory that you specify as the target working directory, and then BatchPatch will leave them there when the deployment is complete.

If “Leave entire directory is unchecked” BatchPatch *does* create a sub temp folder under the target working directory. This is because the folder used is, in fact, temporary. BatchPatch then deletes the entire temp folder after the deployment is complete.

I’m a bit confused as to why McAfee would have a problem with a folder simply because it has the name “temp” even if it appears in a program files directory such as C:Program FilesBatchPatchtemp. This seems very odd to me. Can you tell me what happens? How does McAfee respond to this? Is there not a way to simply whitelist C:Program FilesBatchPatch (or whatever directory you’ve set as your target working directory)? Do you know of anywhere that McAfee might have the behavior documented so that I can take a look at what they say they are doing and/or why?

Thanks,

Doug

[doug]

Excellent point, Booster. In cases where a reboot may or may not be initiated you are absolutely correct. However, in the above case “Reboot (force, if required)” is used. This will reboot the machine every time, so this shouldn’t be a problem. “Reboot (force, if required)” always reboots the machine. The “force, if required” flag tells BP to attempt a normal reboot first, but if a user is logged on, then BP initiates a forced reboot, which logs off the user and reboots immediately, regardless of any open or unsaved programs that might be running.

-Doug

[doug]

Lewok – The issue appears to be that your job queue contains the following two items in succession:

Reboot (force, if required)

Wait for host to be detected online

However, the above lines in succession will be problematic. In this case what you really need is:

Reboot (force, if required)

Wait for host to offline and come back online

The issue is that when the reboot is initiated, if you have a “wait for host to be detected online” *immediately* after the reboot command, the host will be detected online before it ever reboots. This leaves you with the following in the log:

16:04:13> Job Queue: Initiating 'Deployment (install pro plus):: FileToDeploy:: E:Office 2007 Professional Plussetup.exe%**%CopyEntireFolder:: TRUE%**%LeaveEntireFolder:: FALSE%**%RetrieveConsoleOutput:: FALSE%**%Command:: "setup.exe" /adminfile C:comparedocstempupdatesinstall.msp%**%Parameters:: /adminfile C:comparedocstempupdatesinstall.msp'

16:04:13> jl2js42 is online and responding to WMI requests

16:04:13> Job Queue: Initiating 'Wait for host to be detected online'

16:04:13> Reboot/Shutdown: Reboot initiated successfully.

The deployment first begins just when the machine is actually about to go offline. So then just seconds later the machine is actually offline and in the midst of a reboot, but the deployment is still trying to execute. So, you need to make sure the machine goes offline and comes back online after a reboot. It is not sufficient to use “wait for host to be detected online” right after a reboot command since the host will be detected online before the reboot occurs.

I hope this helps.

-Doug

[doug]

When you save a job queue or a deployment, it is not saved to the .bps file. It is saved globally (in the registry). The only way, in theory, that you could somehow save the deployments and job queues and then have them seemingly disappear from your saved items, is if you were working with multiple instances of BatchPatch at the same time. If you saved the items in one instance of BatchPatch but then you closed that instance before you closed other open instances, you would lose the saved stuff. This is because the last instance of BatchPatch that is closed is the one that will be saved last, so whatever saved queues and deployments it contains will overwrite anything that was previously saved by another instance.

-Doug

[doug]

Thanks for following up. I’m really glad to hear that you got it resolved.

-Doug

[doug]

Mats – Thank you for the feedback. I do understand what you’re describing, but unfortunately I don’t think this is something that we will be able to “fix.” That’s because it’s simply how the window is rendered in Windows. The issue, I believe, can be prevented by changing where your mouse cursor is hovering over the menu item, in cases where the menu item is very far down at the bottom of your screen. If you move your mouse to the far left of the menu item, this will usually prevent the blinking. Or if you move the BP window higher up to the top of your display so that the menu doesn’t extend all the way to the taskbar, this would/should also help prevent that.

-Doug

[doug]

Excellent! Glad you got it working. Thanks for the extra info about your environment. That’s helpful to know.

-Doug

[doug]

stevedev – This is very interesting, and it sounds like you’ve made some progress. Out of curiosity, would you mind describing a bit about your environment? I’ve never heard of the

The object exporter specified was not found. (Exception from HRESULT: 0x80070776)

error that you were receiving, and I’d be curious to know more about your infrastructure to understand why it was occurring. I’m glad that you got it resolved, but it’s peculiar that it was happening in the first place. The article you linked to above mentions a NAT setup. Are you somehow trying to connecting to WMI through a NAT device? Is it a one-to-one NAT? I can’t imagine how it could work in a many-to-one NAT/PAT setup.

As for the new Access is denied error, can you confirm that the Domain Admins group is the in the local administrators group on the target machine?

Please also take a look at the following link for some additional suggestions. See if any of the options listed here are able to work for you.

batchpatch-authentication-in-domain-and-workgroup-non-domain-environments

Ultimately I can tell you that I have never seen the Access is denied error be inaccurate. That is to say that if you’re getting Access is denied then it’s surely a permissions (or similar) issue, as opposed to there being some other underlying problem.

Another quick test to try is to just make sure that local WMI connections can be made on the box. So instead of trying to remotely connect, try to run BatchPatch directly on the machine in question. However, when you launch BatchPatch on that machine, make sure to run it with elevation using right-click run-as administrator. Then add the localhost (using the machine name) to the grid. Then see what happens. Do you still get the Access is denied error or is it successful?

Also, for the sake of testing, I would suggest using just the “Get last bootup time” action. This is a WMI-only action, whereas the Windows Updates actions use WMI plus PsExec, which requires additional access beyond WMI. It’s prob best to first make sure that the WMI-only actions, such as “Get last bootup time,” work properly first before trying the actions that use WMI in addition to PsExec.

Keep me posted.

-Doug

[doug]

BatchPatch automatically provides the proper quotation marks, so the “command to execute” need not be manually edited by you at all. When you create the deployment as specified in the screenshot, the “command to execute” is automatically populated as you see in the screenshot. I did *not* manually edit it, nor should you.

Thanks,

Doug

[doug]

ombra17 – What happens when you try to access \\targetComputer\admin$ and \\targetComputer\c$ from the BatchPatch computer? This is where BatchPatch is throwing the error. BatchPatch tries to access \\targetComputer\c$ so that it can create the remote working directory. If you try to access these locations manually by going to

start > run > \\targetComputer\C$
start > run > \\targetComputer\admin$

What happens?

[Author]

Posts