Forum Replies Created
-
Posts
-
You said you only want error reports. The example I gave you will only send the email if there is an error. In your case there was no error, so no email was sent. “Exit code: 0” means success. Non-0 exit codes would generate an email.
You can use the job queue to create a multi-step action to execute on the target. You can use the special item in the job queue ‘Send email notification if previous action fails/errors’ to trigger an email to be sent.
So for example your job queue could be:
1. Download and install updates + reboot if required
2. Send email notification if previous action fails errors
Other options for sending email notifications are explained here:
using-email-notifications-to-check-status-of-automated-patching-events
Hi Laurie – I’m sorry to hear that you are having trouble. From the information you provided I would not be able to tell you why the issue is occurring. I would need to review the actual .bps file to even have a chance at that. If you’d like to contact us via email (use the contact form on our website), then we can try to figure out what’s going on. Otherwise my guess is you won’t have any issues if you simply start a brand new grid from scratch. We have never seen this error occur or had any reports of it, so it’s likely something specific to your .bps file. Either it is legitimately corrupted, in which case you would definitely need to start a brand new file from scratch, or do you have any kind of process that might be trying to modify the file directly on disk rather than modifying it through BP? This would be another possible thing that could cause issues if the modifications do something to the file that is breaking the xml format in some way and thereby preventing the xmlreader from being able to consume the file without encountering an unexpected end. Aside from that I couldn’t really imagine that anything else could cause it.
-Doug
Thanks.
BatchPatch does not impose limits, but Windows does have limits to how large reg values can get, depending on the OS. What OS are you running BP on?
We’ll look into getting this sorted out for a future version and prob saving them to a file rather than the reg.
Oh, ok. That makes sense. So yeah if they are on two separate servers then it would not be an issue. It would only be an issue if you launched batchpatch.exe more than one time on the same server or if you used ‘File > New window’ in BatchPatch, which works the same way by launching a new instance of batchpatch.exe. If you have only a single batchpatch.exe running on a computer, then there will be no overwriting occurring. That said, at the moment I have zero guesses as to what could be causing your issue. Not that it should make a difference, but do you have an unusually large number of saved commands/deployments/queues etc? I would suggest that you do a test. Close all instances of batchpatch.exe. Then launch a single instance of batchpatch.exe. Then add a single item (command/copy job/queue/deployment etc). Then close and reopen BP. Is it still there? What about other items that previously existed? So for example are ALL items cleared or does it seem like only the ones that you are creating new are being cleared? Almost sounds like there is something preventing BP from writing to the user hive of the registry? The items are saved in HKCUSoftwareBatchPatch under values titled SavedUserDefined…XXX
The new version of BatchPatch will not be any different as far as this issue is concerned. The way you responded left it unclear if you are using multiple instances of BP, but it sounds like you are, yes? That’s surely the problem. If you have two or more instances running, whichever instance is closed last will control which commands you see when you launch a new instance. We’ll look at ways we can improve this in a future version, but for now you’ll need to be mindful of the order that you close instances. Or if you are going to make updates to commands/queues/deployments etc, do it with only a single instance open.
We have had zero reports of this ever happening, and we have never experienced it here. There are only two things that I can think of…
1. Are you saving them in one user profile but then looking for them in a different one? So if you are running BP as userA and saving them, but then looking for them by running BP as userB (or as running as admin vs not running as admin, for example?), that could make it seem like they are missing when in fact they are there but just not where you are looking.
2. Are you running multiple instances of the BatchPatch.exe? If you are creating/saving them in one instance of BatchPatch.exe but they don’t exist in the other instance of the BatchPatch.exe, then this could easily create a scenario where you inadvertently overwrite all of the saved stuff with the other instance.
Thanks. We’ll consider this. In the meantime you can actually get this answered at least partially by using ‘Generate consolidated report of available updates’. In the lower left corner of that report window there is a ‘Rows’ number that tells you the total number of updates found.
In the current version of BP it’s not possible to trigger one multi-row-queue-sequence to start when a different multi-row-queue-sequence ends. However, you could simply combine them into just a single multi-row-queue-sequence because that is effectively what you would be doing anyway. What is the purpose of keeping them as two separate sequences if the goal is to run them as a single sequence?
Just on the computer where BatchPatch is running.
-Doug
Thanks. Turns out there are two separate issues here, but they manifest with the same result.
1. When the vertical resolution is smaller than 1024, portions of some windows like the Settings and Job Queue are cut off from view.
2. When the DPI/scaling is set to a non-standard value such as 125% or 175%, portions of some windows like the Settings and Job Queue are cut off from view.
To resolve/workaround please use vertical resolution of 1024 or greater. Please use DPI scaling of 100%, 150% or 200%. We’ll look into improving this for a future version.
Thanks,
Doug
Don’t do this. Do not disable the Windows Update services. It’s the wrong approach, and it’s a bad idea. Instead change the group policy (or local policy on each computer if there is no domain) for ‘Configure Automatic Updates’ and set it to “2 – Notify for download…” Any machine that is configured for setting 2 will *NOT* automatically download updates anymore. Then you can use BatchPatch for this process.
To do this… In the Group Policy / Local Policy editor (gpedit.msc) go to ‘Computer Configuration > Administrative Templates > Windows Components > Windows Update’. Set the “Configure Automatic Updates” setting to 2.
Also make sure you do not have ‘Dual Scan’ enabled on your computers. More here:
Hi Mats – Could you elaborate on what purpose this would serve? I’d like to understand from your perspective why you think this would be beneficial. At the moment from my perspective I can’t think of how this really is helpful, so I’d be interested to hear what you think. Furthermore, could you explain how you would want it to be handled in the case that multiple rows need the same patches. So for example if there are 5 hosts in the grid, and each host needs the same 4 updates, do you want to see 4 updates needed for the grid or do you want to see 20 updates needed or do you want to see something like 4 unique updates / 20 total updates needed?
The issue is your DPI/scaling setting in Windows. BatchPatch tries to detect and warn you if you are using a DPI that BatchPatch isn’t able to display properly, but it might not have been successful in detecting this or perhaps you closed the warning without realizing it. In any case if you change the DPI/scaling to 100% things should look normal again. 150% and 200% are also probably fine. I think the issue is when you set it to something like 125% or 175%. That’s when it will cut off part of the BatchPatch windows.
Normally you would just ping the device (‘Actions > Ping…’) to see the IP. Of course you’ll want/need your DNS to be accurate and up to date.
-Doug
Yes, BP cleans the remote working directory after successful updates or deployments. However, an unsuccessful operation could leave files there. In all cases, BP always leaves a couple/few log files in the folder, and I would recommend that you do not remove these since they contain the history of update operations. If you do decide to remove these, it won’t break anything but you’ll lose some of that history information. If you want to delete the entire directory you may use ‘Tools > Delete remote working directory.’ If you want to delete only certain files/folders in it, then you would have to use a custom command.
-Doug
The current version does not provide this functionality, but we are looking at adding it for a future version. However, you can workaround it by adding the DNS suffixes to your NIC, so then when the short name is in the grid, your NIC will automatically append the needed suffix, and connections will work just as if you had added the FQDN to the name in the grid. This video demonstrates how to add the suffixes to your NIC (note, we did not make this video):
In the previous versions of BP, the job queue title was not displayed in the cell with the job queue steps. In the new version we display the job queue title in the first line, while the steps of the queue are below that. We surround the title with *. Example:
* Job Queue Cycle Number 2 *
. . . . . . . . . .
Download and install updates + reboot always
Wait 10 minutes
Wait for host to be detected online
Check for available updates
Terminate queue if previous ‘Check for available updates’ finds 0 updates
Download and install updates + reboot if required
As described at the previously posted link above about BatchPatch ports, the solution is to configure your hardware firewall to allow DCE/RPC. BatchPatch does not use WinRM.
In the current version of BP this won’t work. BP will only look for files in the BP cache folder itself. It will not look into subdirectories. We’ll consider for a future version having BP recurse subdirectories when searching for files in the cache.
-Doug
BatchPatch port requirements here: BatchPatch Port Requirements
Nope. It sounds like something specific to the particular .MSI that you are trying to install.
Well, I have no idea what the .MSI package is that you’re trying to install, so that makes it tough to comment on. This would be a case where you’d want to consult with the vendor who created the .MSI to see if it’s possible to successfully complete a silent installation or not with that package. Or do some googling to see if and how people are doing silent installations of the .MSI package in question. Of if there is a .MSU or .EXE version of it, then there could be other switches/parameters built in to the package that enable you to specify via a parameter to close the search/cortana as part of the silent installation.
I have never heard of nor have I ever seen a situation where a .MSI package returns 0/success but does not actually install. That sounds odd. Unless it’s returning a 3010, which is ERROR_SUCCESS_REBOOT_REQUIRED to complete the installation.
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.