[doug]

Do not use a batch file. Instead create a deployment following the tutorials at software-deployment

This would entail placing all of the files for installation/configuration into a single directory. Then create a deployment to deploy the setup.exe from that directory, and check the box that says “copy entire directory.” Then put the following line into the parameters field:

-inputFile installer_input.txt

You will *not* need to modify the ‘command to execute’ field in BatchPatch. However, when the deployment is properly configured it should show:

"setup.exe" -inputFile installer_input.txt

[doug]

Thanks for clarifying. OK so in this case you are deploying the .bat file, but the .bat file is making network calls to UNC paths. This is effectively pretty much the same as using a BatchPatch ‘remote command’ to run the command, so for all intents and purposes much of what I said in the previous posting still applies.

So your options are:

0. Try disabling UAC as a test, as mentioned previously.

1. Try what I suggested in the previous post item 6 about supplying alternate credentials so that the remote process is not impersonating. This might solve the problem. IMPORTANT: Make sure to try this with all three ‘elevated token’, ‘normal’, and ‘system’ remote execution contexts. Let me know what happens.

2. Create a deployment to deploy Office instead of a deployment to deploy a .bat file. In this case you would configure your deployment to deploy the setup.exe, you would check the box to ‘copy entire directory’ and you would add to the parameters field “/configure configuration.xml” without the quotes. There are no UNC paths used in this method. The configuration.xml file will be located by the setup.exe without specifying a path because it will be found in the same directory as the setup.exe on the target computer during the installation. All required files are copied to the target, the installation is performed, and then the files are removed.

[doug]

OK, so you’re not executing a BatchPatch ‘Deployment’ action… you’re just using a ‘Remote Command’ in BatchPatch. I didn’t realize that. Certainly then one simple solution/workaround would be to use a BatchPatch ‘Deployment’ instead. I’m sure that this would work without issue. However, if you really don’t want to use a BatchPatch ‘Deployment’ then I have some questions and suggestions because UNC paths inside remote commands can be problematic.

1. You never tested disabling UAC even though you seemed quite certain that UAC was the culprit. While I don’t think that UAC is the culprit, I do think it’s worth disabling it as a quick test just to rule it out.

2. Are you using ‘Remote Command (logged output)’ or the regular ‘Remote Command’ ? Try both because they work a bit differently under the hood and can produce different results.

3. What is the exact command that you are executing? Without being able to see the command, it’s very difficult for me to really make a guess about what might be happening.

4. What exactly happens when you execute the command? You said it “gives a success but never installs.” Does this mean that in BP you see ‘exit code 0 (SUCCESS)’ or similar? Does this occur immediately after execution, or does it appear to execute for a while before returning?

5. There could be an issue with quotation marks (single vs double vs none) in the command.

6. It’s worth trying to supply ‘Alternate credentials’ for the row in BP even if the account you specify in the alternate credentials field is the same account that is being used to run BP. This is because when alternate credentials are supplied, the authentication does not rely on impersonation, which can create problems when trying to use UNC paths.

[doug]

I really don’t think the issue would/could be with UAC, otherwise we would expect to see the same problem occur with every single application or MSI etc that is deployed by BatchPatch, but we don’t.

To rule out the possibility that UAC is the culprit I would suggest disabling UAC completely as a test. If the exact same deployment works when UAC is disabled then it would indicate that UAC is, in fact, the culprit. Frankly, this would shock me, but do let me know.

Assuming that the issue still exists even when UAC is completely disabled, the next steps I would suggest are:

Try changing the remote execution context to ‘elevated token’ under ‘Tools > Settings > Remote Execution > Deployment’ and see if that makes a difference.

If it does not make a difference… In your deployment, can you confirm that your .xml file is in the same directory as the setup.exe on the BP computer? Can you also confirm that all of the other setup files that go along with the setup.exe are also in that same directory? If all of the files required for the installation are in the folder (with directory structure preserved, of course), then when ‘copy entire directory’ is checked, they will all be copied to the target computer so that when the setup.exe is executed, it will be able to find all of the files that it needs, including the .xml file. Make sure you have actually checked the ‘copy entire directory’ box in your deployment configuration.

[doug]

In the current version ‘Generate consolidated report of available updates’ is for on-demand usage only. It cannot be run from the job queue. In a future version this might change.

-Doug

[doug]

Considering that you are passing the $computer variable into the web request, this can be run as a local command and does not need to be run on the target computer, so I would focus on running it as a local command for the moment. I know you said it returns exit code 1, but what is returned in the ‘Local Command Output Log’ column?

I am able to run all of the following commands successfully in BatchPatch as local commands. Obviously I am unable to test your particular web application, so I couldn’t comment on why it would not be doing what you are expecting, but BatchPatch appears to be able to successfully execute invoke-webrequest powershell commands without any issues for me:

powershell.exe -ExecutionPolicy Bypass -command “Invoke-WebRequest https://mysite.whatever”

powershell.exe -ExecutionPolicy Bypass -command “Invoke-WebRequest ‘https://mysite.whatever'”

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command “Invoke-WebRequest https://mysite.whatever”

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command “Invoke-WebRequest ‘https://mysite.whatever'”

[doug]

Works for me without issue. When you say that it doesn’t work, could you be more specific? What exactly happens in BatchPatch?

[doug]

In the current version of BP, BP pushes the updates to the target, which means that they must pass through the BP computer. We recommend keeping the cache dir on the BP computer. We are considering a “pull” methodology in a future version.

[doug]

Excerpt from

Understanding the Special Items in the Job Queue

IMPORTANT: ‘Wait for host to go offline and come back online’ should be used carefully. In particular, we do not recommend using this special action with virtual machine target computers. The reason for this is because virtual machines can often reboot within just a couple of seconds, which unfortunately can be too fast for BatchPatch to successfully detect. If the machine reboots so rapidly that BatchPatch does not know that it ever went offline, then ‘Wait for host to go offline and come back online’ will hang until the global timeout is reached, which will leave you with undesirable results. Here is one possible way you might use ‘Wait for host to go offline and come back online’ in your job queue when the target computer is not a virtual machine.

You could instead do something like this:

Step 1: Download and install updates + reboot always

Step 2: Wait 10 minutes

Step 3: Wait for host to be detected online

Step 4: Download and install updates + reboot if required

[doug]

The section on ‘Access Denied’ in this article might help.

[doug]

Erik – In the current build you’ll have to do this manually. However, thanks for highlighting it. We’ll add these items to ‘Tools > Export’ and ‘Tools > Import’ in the next build. The manual location is in:

HKCUSoftwareBatchPatch

SavedCategoryColumnValues

SavedDescriptionColumnValues

SavedLocationColumnValues

SavedNotesColumnValues

SavedNotes2ColumnValues

[doug]

Yes

[doug]

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

This error message is due to an issue with account permissions. The following link explains everything you need to know about authentication problems: BatchPatch Authentication in Domain and Workgroup (non-domain) Environments

If you are still stuck the BatchPatch Troubleshooting Guide can help you step through to figure out where things are going wrong.

[doug]

Tools > Export saved commands, deployments, job queues, copy jobs

Tools > Import saved commands, deployments, job queues, copy jobs

[doug]

Generally speaking, error codes are coming from the installer package on the target system, not from BatchPatch. However, in this case the 59 might actually be a Windows System Error code:

ERROR_UNEXP_NET_ERR



59 (0x3B)



An unexpected network error occurred.

[doug]

For local accounts you need to make a registry tweak on the target computers, which is outlined here at the bottom in the section ‘Using Integrated Security with a Local Account’:

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

[doug]

“Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))” indicates a permissions issue, not a firewall or port issue.

I couldn’t tell you why your permissions would be modified after upgrading to 1803, but I can tell you that Microsoft has historically had numerous issues in the first release of any feature upgrade, so I would caution against installing any feature upgrade so soon after it is released. It seems, based on your description, that when you applied the upgrade, the permissions on your computers were somehow modified/affected.

That said, since ‘Access Denied’ is a permissions problem, you should be able to resolve it on your 1803 machines by re-evaluating and fixing the permissions.

We have not yet done any testing with 1803 because it was just barely released the other day, so I’m not able to tell you with certainty what specifically might be going on in your situation.

-Doug

[doug]

In the previous versions of BP there were several hard-coded options for clearing column contents. However, we would continually get requests to add new/additional variations. And so then beginning with the 2018.3.28 version there are no longer any out-of-the-box options set. Instead you can now create your own selections lists so that you can have quick/easy access to clear the specific columns that you want to clear.

Select ‘Create/modify selections’ and then tick the boxes for the columns that you want to clear. Then set a title such as “Clear all but X, Y, and Z” and use the double-right-arrow button to save that selection list. Then when you select ‘Execute saved selections’ in the future you’ll see “Clear all but X, Y, and Z” available to use. This way you only have to create the list one time, and then you can use it over and over.

-Doug

[doug]

Have a look at ‘Tools > Settings > General > Concurrent thread maximum’

Explained more here: BatchPatch Performance Tuning

[doug]

I’m glad that worked. Thanks for confirming.

[doug]

At the time of this writing we have not yet tested it, but I’m 99% certain that installation of version 1803 will be performed using the same method as the previous feature updates, which is demonstrated here:

Deploying Windows Feature Upgrades Remotely to Multiple Computers

[doug]

Yes, we are working on a “row template” feature that would allow you to create a special row to be used as a template for the grid so that when you add a new row to the grid it can automatically get a copy of any of the cells in the template row.

Thanks,

Doug

[doug]

Sorry for the difficulties. We’re working on a solution this for for the next release.

Thanks,

Doug

[doug]

You can specify the client IP in the deployment, if you want. The way to do this would be instead of populating the BatchPatch grid with host names, instead go ahead and populate it with IP addresses. You will then deploy to the IP addresses instead of to the host names. Then inside the deployment if you want to use the IP address as a parameter for the deployment, you can do that by specifying the $computer variable. When the deployment runs, BatchPatch will swap $computer for the actual host name of the row, which in this case would be the IP address since you specified IP addresses instead of host names. You can use the $computer variable in BatchPatch local and remote processes / commands too. I hope this helps.

-Doug

[doug]

1620 is a generic code in BatchPatch that essentially means that BatchPatch received an unknown/unexpected return code from the remote process. The batchpatchremoteagent.exe does not have a -1 return code, so this is likely an issue with psexec not being able to complete successfully. I would suggest going through the steps in the troubleshooting guide to test psexec without BatchPatch.

[doug]

Jeffrey – If there is a failure, what would be the purpose of auto-retrying? Wouldn’t it just fail again until you address the reason for the failure? Or are you talking about in cases where you try to deploy to a computer that is not online? And so you want it to auto-retry again when the computer is online? In this case I would suggest two options:

–You could create a scheduled task and check the box ‘Run task immediately upon detecting the computer online’ This option would not run the deployment until BP first detects the computer is online.

–You could create a job queue that looks uses ‘Wait for host to be detected online’ right before the execution of the deployment. This would have the same effect as the above mentioned method. Just make sure in this case to modify the ‘Global timeout for host offline/online detection’ in the Job Queue window to a value that works for your needs.

I hope this helps. If you think there is still a need for an auto-retry option, could you explain why this would be helpful? Then we can evaluate the possibility of adding it to a future version.

Thanks,

Doug

—

[doug]

Hi Mark – The current version of BP does not have this functionality, but we’re working on it for a future version.

Thanks,

Doug

[doug]

BP doesn’t have a trigger for when a user logs on, but you could incorporate that kind of a check into your script if you really wanted. The easiest way would be to use the Win32_Process class to search for running instances of explorer.exe. Generally you would only have an explorer.exe process running if a user is logged-on. If the script doesn’t find it then it can wait a minute and check again.

Here are a few examples of script integration into BP:

advanced-script-integration-with-batchpatch

advanced-script-integration-with-batchpatch-part-2

batchpatch-custom-script-integration-install-windows-updates-only-after-stopping-a-specified-service

Another option would be to perform the deployment through BP instead of through SCCM. Then you wouldn’t have the issue of the command not executing at the desired time. A BP deployment would execute at the time you choose to execute it.

-Doug

[doug]

Hi Kevin – In BatchPatch under ‘Tools > SCCM client triggers’ all of the WMIC commands are hardcoded. You can see the complete list here: Triggering ConfigMgr (SCCM) Client Actions Remotely

They’re WMIC commands just like the ones that you are already executing, so I wouldn’t expect them to produce a different result than what you’re currently seeing unless you use a different trigger (there are a total of 49, if I’m remembering correctly). The only thing I would note is that according to any documentation I have seen, the two commands that you are executing are:

{00000000-0000-0000-0000-000000000001} Hardware Inventory

{00000000-0000-0000-0000-000000000121} Application manager policy action

not:

Machine Policy Retrieval Cycle

Application Deployment Evaluation Cycle

I don’t know if this means that you are really wanting to execute different commands, or if you are executing the correct commands, but in either case I don’t think you’re dealing with a BatchPatch problem, as it’s essentially just the messenger delivering the command. The command is clearly being executed. We know this not only because of the ‘SUCCESS’ response but because when the user logs on the deployment starts. So I think the real question is why does this SCCM trigger not do anything until the user logs on. I don’t know if this is something that could be answered by a SCCM guru somewhere or if there is a different client trigger that would do what you need/want. However, from the BatchPatch angle I don’t think there is anything else we can do.

[doug]

It’s much more complicated than just issuing a command.

[Author]

Posts