Forum Replies Created
-
Posts
-
BatchPatch works fine in a cross-domain cross-forest config. We use it like that all the time. The error you are receiving is not a BatchPatch error per se. It’s from Windows (being passed through by BatchPatch). It could be something with your domain controller config or DNS or SPNs or forest trust relationship etc. It has nothing to do with BatchPatch. I would suggest you review the various suggestions/fixes/resolutions described by people in forums on the web:
I can confirm that it’s not a BatchPatch issue. When using BatchPatch in the default mode, the target computer’s Windows Update Agent is what handles downloading the updates. You can find lots of complaints on the web about Win 2016 update downloading being slow. That said, you have several options to help deal with this or workaround it.
1. My primary recommendation would be to have the computers download the updates using group policy so that the updates are already downloaded by the time your maintenance window begins. In this way you can use BP to initiate and monitor the installation process without having to wait for the slow download (use BP action ‘Install downloaded updates’). You could of course also use BP to initiate the download process before the maintenance window, but why not just let the computers take care of it themselves with group policy?
In Group Policy editor (gpedit.msc) go to ‘Computer Configuration > Administrative Templates > Windows Components > Windows Update’ and set the ‘Configure Automatic Updates’ setting to 3 = ‘(Default setting) Download the updates automatically and notify when they are ready to be installed’
2. You could use BatchPatch in online cached mode. In this mode the BatchPatch computer downloads the updates and pushes them to target computers rather than each target computer’s Windows Update Agent downloading the updates, so you will not be subject to the same slowness issue. However, unfortunately there is one potential roadblock with this method, which is that starting with Win 10 v1709 Microsoft made a change that makes it no longer possible for BatchPatch running in online cached mode to automatically download the large cumulative update each month. I assume the same issue exists in Win 2016 v1709 and is not exclusive to Win 10, but I have not actually tested Win 2016 for this issue at the time of this writing. This issue is not a bug. It’s a change to how Microsoft distributes the cumulative updates. I would suggest you give it a try just to see if it works or not. I suspect that Win 2016 is going to behave the same as Win 10, but you’ll be able to test it more quickly than I can because at the moment our lab is in the process of being upgraded, so I don’t have access to it right now. Also, if you are still running a version of Win 2016 that is older than v1709, then I think this will work well for you because the change was not introduced until v1709. Also note, it’s the OS version of the target computers that matters in this case, not the version of the computer running BatchPatch.
cached-mode-and-offline-updates
3. You could use BatchPatch in offline cached mode. This will work and will not have the same potential roadblock as described for online cached mode. However, there is still a caveat, unfortunately, which is that offline mode does not include *all* updates. It includes all security updates plus various other updates that Microsoft selects, but it will not include all non-security updates that you would see when using online regular mode or online cached mode. That said, one possible solution might be to do a download/install cycle with offline cached mode, and then go back to online cached mode and do a second cycle to get any remaining non-security updates. (Or for the second cycle you could try online regular non-cached mode and see if it’s quick because the large updates presumably would have been handled during the offline mode cycle, so perhaps the slow download issue might not be a problem in the second cycle if there are only small updates left.)
4. You could use the BatchPatch ‘Deployment’ feature to deploy the updates to target computers instead of using the BatchPatch Windows Update actions. In this case you would need to manually download the desired update files from Microsoft from the update catalog (typically they come in .MSU format), and then you can distribute them with the BatchPatch deployment action.
remotely-install-multiple-msu-files-or-msi-and-msp-files-to-numerous-computers
It appears that you have not actually “opted-in” to the Microsoft Update service. As noted in the following error message, you must first opt-in to the Microsoft Update service. Use ‘Actions > Windows Updates > Opt-in…’ one time on any target computer that you want to scan for updates using Microsoft Update. Performing this action is equivalent to launching the Windows Update GUI on the target computer and selecting the option to ‘Get updates for other Microsoft products.’ This must be completed one time before you will be able to successfully scan for updates using ‘Tools > Settings > Server Selection > Microsoft Update.’
Di-13:56:59> Windows Update: Error -115: Failed to execute the search. Unknown update service. If attempting to use ‘Microsoft Update’ you must first opt-in to the service. See ‘Actions > Windows Updates > Opt-in…’
This might help. batchpatch-and-the-windows-update-control-panel-report-a-different-number-of-available-updates
Offline Mode: If you have enabled offline mode you will likely notice a discrepancy between the available updates that are reported in BatchPatch as compared to the available updates reported in the Windows Update control panel or when *not* using ‘offline mode’ in BatchPatch. This is because offline mode is designed for offline scanning when no internet or WSUS is available. An offline mode scan relies on the WsusScn2.cab file that Microsoft releases each month. This file contains all security updates along with various other updates, but it does not contain every update that is published on Microsoft’s public Windows Update and Microsoft Update servers.
BatchPatch does not ever empty the cache folder automatically since contents in the cached folder might be needed for a different computer. If you want to empty it you can simply delete its contents. If a file that you delete from the cache is needed for a future task, then BatchPatch will have to download it again in the future when it’s needed.
If BatchPatch detects that there is a new WsusScn2.cab file available from Microsoft, it will download it and replace the previous one.
It’s not better. It’s different. Generally if you do not have a specific need for using ‘cached mode’ then we recommend not using it and just using “normal” BatchPatch. The following link explains the different scenarios for using BatchPatch in different modes.
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.