Forum Replies Created
-
Posts
-
Normally a deployment exit code is returned by the installer package. However, in the case of exit code 2 it could be that there is an issue with the actual command line syntax or an issue with psexec executing on that computer. I would suggest as…
Step 1, make sure the .msi package itself is not corrupt. Make sure it can install successfully when run manually without using BatchPatch.
Step 2, make sure that BatchPatch is able to successfully execute ‘Check for available updates’ on that computer. If this works, then we know that psexec is working properly.
Step 3, assuming psexec is working properly, then probably your deployment configuration is problematic. I would need to see the deployment configuration in order to tell you if there is something obviously wrong with it. You can use the link that dorianborovina posted above to see examples of how to deploy .msi files with BatchPatch. If you continue to have problems then maybe you can post a screenshot of your deployment configuration. This forum does not allow images, but you could post it to something like imgur.com and then provide a link here.
-Doug
No.
The data has to get to the machine one way or another. If you manually launch your batch file, when it runs the setup.exe don’t you think the files have to be copied from the network share to the computer anyway? After all, the files are needed for and part of the installation. What’s the difference if they are copied/staged by BP or copied when the setup.exe is launched by the batch file? Is there something that I’m missing? Also note, in this case you should start with the files on the BP computer instead of the network share. This would halve the time required to perform the copy because the data would not have to get pulled down from the share through the BP computer to each target. Instead it would just be copied from the BP computer directly to each target. I’m not certain why your batch file is failing. You could try using full path in the copy commands, and you could try setting remote execution context (Tools>Settings>Remote Execution) to ‘elevated token’ instead of ‘system’ because ‘system’ does not have network access.
There is nothing in BP that will show the total size of all updates. It only shows the individual size of each update. We will consider adding this in a future version.
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.txtYou 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.txtThanks 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.
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.
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.
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
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'”
Works for me without issue. When you say that it doesn’t work, could you be more specific? What exactly happens in BatchPatch?
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.
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
The section on ‘Access Denied’ in this article might help.
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
Yes
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.
Tools > Export saved commands, deployments, job queues, copy jobs
Tools > Import saved commands, deployments, job queues, copy jobs
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.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
“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
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
Have a look at ‘Tools > Settings > General > Concurrent thread maximum’
Explained more here: BatchPatch Performance Tuning
I’m glad that worked. Thanks for confirming.
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
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
Sorry for the difficulties. We’re working on a solution this for for the next release.
Thanks,
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
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.
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
—