Forum Replies Created
-
Posts
-
I don’t have a solution for you to overcome it in the current version of BP. In the next version of BP, BP attempts to ignore this particular error (Windows Update: -106G: Update search completed with errors: -2145123271) and continue. However, that’s not a guarantee that it will always be able to successfully ignore it, but it might solve the issue in your case.
-Doug
The uploadReadAheadSize adjustment is to be made on the WSUS server, not on the target servers, even though you only see the error on particular target servers. If you are not using WSUS but instead are getting updates directly from Windows Update or Microsoft Update, then this potential fix does not apply to you.
-Doug
If you select all 50 rows at once, you can modify them all at once, but they will all end up with the same run date/time, which I understand is probably not what you want. In order for 50 tasks to all have different run times, they cannot be modified at the same time in BP. Your best option is probably to save the grid to .bps file, and then open the .bps file in a text editor like Notepad++ and manually update the run dates.
-Doug
When you say “since the find only goes to the first result” could you elaborate? I’m not sure what you mean. If you use the “find” feature, it will go to the first result, but if you continue to press enter or click “find” it will step to each result in the order that it finds them. Does this give you what you need?
We will consider a find/filter option for a future build.
Thanks,
Doug
Actually, coincidentally it’s already been added to the next version, which is coming soon. That is… in addition to $computer the ability to use $notes, $notes2, $location, $category, $description in local command/remote command/getinfo query/deployment.
-Doug
My first suggestion is to please *uncheck* the box ‘Retrieve console output…’ in the ‘Deployment’ window.
-Doug
Hmmm… this should already be working. I’m not sure why it isn’t, but we’ll look at updating/fixing this for the next release.
Thanks,
Doug
I’m glad you got it worked out. FYI there’s no reason you shouldn’t be able to use run-as from your other account. We have many customers who do this, and we do it here all the time. If it’s not working like that, I’m not quite sure why, but it’s gotta be something about your environment. I’m sure it could be made to work.
-Doug
I think you would have to execute the action with the desired account (the account logged on to the target computer) being used as the ‘Alternate Credentials’ account in BatchPatch or actually launch BatchPatch.exe with that account. Then under ‘Tools > Settings > Remote execution’ specify ‘Elevated token’ instead of ‘SYSTEM’. Then try your command. I can’t guarantee that this will work to do what you want, but it might.
It sounds like something is preventing psexec.exe from running. There are a couple/few possibilities.
1. Make sure that there isn’t a hidden ‘Open File – Security warning’ popping up and waiting for a response. Since psexec.exe was downloaded from the web, Windows can sometimes prevent it from running by popping a dialog that you have to click on. However, if this dialog pops up in the background, you might not know it’s waiting for input. If the dialog is the cause, there is a checkbox on the dialog that can be modified so that the dialog does not continue to pop up every time psexec.exe is executed.
2. If you are running the BatchPatch.exe as a different logon account than the account that you are logged on to the computer with (so like if you use right-click run-as to launch BatchPatch), make sure that you have logged on to the computer one time as the run-as account. And also when logged on with that run-as logon account, launch BatchPatch.exe and attempt an action that uses psexec. Once things are working properly in this account, then you can switch to the other account where you may use run-as to run the batchpatch.exe successfully as the run-as account.
3. Another thing to consider is anti-virus or other similar security software. This could be an issue. Aside from disabling or removing the AV software on both the BP computer and the target computer, one option that sometimes can work to bypass the AV issue is to provide a custom name for the psexec service. This is done under ‘Tools > Settings > Remote Execution > Use psexec -r switch…’
I can’t think of any other possible causes for the problem you are experiencing.
-Doug
I’m not sure why this would occur. In theory it should utilize all available cores. We’ll look into this.
Thanks,
Doug
You can create your own queue/sequence to accomplish what you want. There is a job queue item “Terminate queue if previous ‘Check for available updates’ finds 0 updates.” This queue item would allow you to check one host to make sure it has 0 available updates before its queue ends and the next host in the sequence starts.
-Doug
Hi Laurie –
‘Get MAC address’ is not part of the scheduler or job queue because up until now we have had no reason to add it. Normally the MAC address is static/unchanging. So you would gather or enter the MAC for a target only one time, and then you would never have to do it again. What purpose would it serve to reach out for the MAC address on a scheduled basis? In fact, it seems to me that it only causes problems because of what you described where it is overwritten with ‘The RPC server is unavailable.’ when the machine is not online. Why would you want to get re-get the MAC address on a regular/scheduled basis? Why not just get it one time when you first add the computer, and then you don’t have to keep getting it?
I would suggest you first follow the troubleshooting guide and make sure that you can complete the ‘Windows Update’ section. If ‘Check for available updates’ is working properly, then the permissions should be fine for deployments. In that case, it sounds like when you are beginning the deployment some other process (not BatchPatch) is locking the file. Anti-virus software could be one example of software that might do this. Another possibility that could cause this is if you try to execute the same BatchPatch deployment twice. The second one attempts to execute while the first one is still executing, and then it produces this error.
In the next version of BP we have modified the code so that BP is able to successfully ignore this particular error ( -2145123271 ) and continue, at least in certain instances. Release date TBD, but it should be not too far off. We are not sure which other “flavors” of -106G will be ignorable since we cannot reproduce all of them. However, we know for sure that some “flavors” of -106G cannot be ignored while others can be.
-Doug
In the next version of BP we have modified the code so that BP is able to successfully ignore this particular error ( -2145123271 ) and continue, at least in certain instances. Release date TBD, but it should be not too far off.
-Doug
For the following error:
Windows Update: Error 1620: -106. Failure
Windows Update: -106G: Update search completed with errors: -2145123271
In the case where this error occurs when using a local WSUS (as opposed to using ‘Windows Update’ or ‘Microsoft Update’ public servers), one possible solution is described below:
The problem appears to be:
WARNING: The server returned HTTP status code ‘413 (0x19D)’ with text ‘Request Entity Too Large’.
WARNING: MapToSusHResult mapped Nws error 0x803d0000 to 0x80240439
The solution described at the following link suggests:
After increasing IIS setting uploadReadAheadSize on WSUS server from 49152 to 491521 the missing updates (KB3213986, KB3214628) is installing properly on 1607 client.
Launch “Internet Information Services (IIS) Manager”
Expand the Server field
Expand Sites
Select the site you want to make the modification for. (WSUS Administration)
In the Features section, double click “Configuration Editor”
Under “Section” select: system.webServer -> serverRuntime
Modify the “uploadReadAheadSize” section (This value should be in Bytes)
Click Apply
Do an IIS Reset
For the following error:
Windows Update: Error 1620: -106. Failure
Windows Update: -106G: Update search completed with errors: -2145123271
In the case where this error occurs when using a local WSUS (as opposed to using ‘Windows Update’ or ‘Microsoft Update’ public servers), one possible solution is described below:
The problem appears to be:
WARNING: The server returned HTTP status code ‘413 (0x19D)’ with text ‘Request Entity Too Large’.
WARNING: MapToSusHResult mapped Nws error 0x803d0000 to 0x80240439
The solution described at the following link suggests:
After increasing IIS setting uploadReadAheadSize on WSUS server from 49152 to 491521 the missing updates (KB3213986, KB3214628) is installing properly on 1607 client.
Launch “Internet Information Services (IIS) Manager”
Expand the Server field
Expand Sites
Select the site you want to make the modification for. (WSUS Administration)
In the Features section, double click “Configuration Editor”
Under “Section” select: system.webServer -> serverRuntime
Modify the “uploadReadAheadSize” section (This value should be in Bytes)
Click Apply
Do an IIS Reset
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'”