Forum Replies Created
-
Posts
-
You can specify a list of patches to apply, which would prevent any other patches from being applied. However, it would not guarantee that all the specified patches would be applied because the computer would first have to view those as “available updates” before it could ever apply them.
You could then just apply that same list to any machine that you wanted to update.
This link should help:
Unfortunately I do not have any better suggestions than the ones I provided in the previous posting.
-Doug
Error 1601: Failed to retrieve WMI info. The interface is unknown. (Exeption from HRESULT:0x800706B5):
This indicates that WMI is not working properly on the target computer. This hotfix may resolve the issue. If that hotfix does not fix the issue, then you will need to troubleshoot WMI in more depth on the target computer. This link explains how to do that.
Error 1601: Failed to retrieve WMI info. A security package specific error occurred. (Exeption from HRESULT:0x80070721):
I would suggest the following links to help troubleshoot:
https://msdn.microsoft.com/en-us/library/aa394603%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
Matt ended up running BatchPatch on a different computer without any problems. All target computers were reporting properly when running BP from a different computer. We did not isolate the exact cause of the issue on his original computer.
-Doug
Hi Matt – This is peculiar. I’m going to send you an email to discuss further.
Thanks,
Doug
Sounds good, Mats. One thing that you might consider as you move forward is to spend some time looking through the KB articles for the 99 remaining updates. That way you can see if you feel like any of those updates is important enough for you to modify your setup so that they get applied to your computers.
Take care,
Doug
I understand your concern. Of course this is really a question that only Microsoft could answer, but I have never seen them answer it anywhere. However, I can tell you what we have observed over the years.
First, Microsoft puts all security updates in the WsusScn2.cab file, but they don’t include other updates. This is documented, but I’m not sure of the actual *reason* for excluding non-security updates. They seem to suggest that this is to keep the update footprint as small as possible while still keeping devices secure. I suspect the idea is that the fewer updates that you install, the less likely you are to introduce problems. And in the case of devices where security is the priority, installing only the security updates means you keep the OS secure while reducing any potential negative impact from other non-security updates.
With regard to ‘Important’ updates, we have noticed that Microsoft seems to use the ‘Important’ classification really just as a means to distinguish which updates they want to put on user computers, as opposed the ‘Optional’ updates that they don’t care so much about getting onto user computers or in some cases might even prefer that users didn’t install. For example, you can be sure that Microsoft would release a telemetry update as ‘Important’ because Microsoft wants to have the best possible telemetry. However, this isn’t something that the end user necessarily wants or cares about. So, while it’s not ‘Important’ to the user, it is definitely ‘Important’ to Microsoft. We have also seen cases where they put an update in ‘Optional’ for a few months before later moving it over to ‘Important.’ They move the update to ‘Important’ not because the actual importance level of the update has changed for the end user. It’s because the importance level of the update has changed for Microsoft.
So, while the ‘Important’ classification will include all security updates, it will also include other non-security updates.
To push the other 99 updates to computers using BatchPatch you would have to either use online cached mode instead of offline cached mode, but in this case the target computers would perform their search for available updates against Microsoft’s servers, which you do not want. Or alternatively you could install a WSUS server in your environment. In this scenario you would give the WSUS server internet access, but you would not have to give the target computers internet access. They would simply need access to the WSUS server. You would then update the group policy that controls where the target computers search for updates so that they search the WSUS. Then when BatchPatch tells them to search/download/install updates, they will do that using the WSUS as the source for the updates instead of Microsoft’s public servers.
Let me know if you have any other questions.
Mats – The Windows Update database *does* get updated when BatchPatch installs updates. The BatchPatch update installation process actually utilizes the Windows Update Agent (WUA) to install the updates. The WUA handles the process of updating the Windows Update database with all the relevant information about which updates have been installed.
If you connect to Microsoft’s public Windows Update server and see different updates available, there are multiple reasons why this can occur:
1. The most common reason for seeing a different number of available updates in BatchPatch is due to the search scope. In BatchPatch under ‘Tools > Settings > Windows Update’ there is a section titled ‘Search Preferences.’ If you select ‘Search for *all* software updates’ AND ‘Search for *all* driver updates’ then you’ll see every possible available update in BatchPatch. However, if you limit the search to only ‘Important’ and/or ‘Recommended’ then you’ll only find the subset of available updates that Microsoft has deemed ‘Important’ and/or ‘Recommended.’
2. The second reason you might see a different number of available updates in BatchPatch is due to the search location (‘Server Selection’).
Default / Managed: Uses the target computer’s existing configuration to determine where to search for updates.
Windows Update: Bypasses the target computer’s configuration and searches for updates on
Microsoft’s public server. Includes only Windows updates.
Microsoft Update: Bypasses the target computer’s configuration and searches for updates on
Microsoft’s public server. Includes Windows updates AND updates for other Microsoft products.
Before using Microsoft Update, target servers must be opted-in to the service.
See ‘Actions > Windows Updates > Opt-in…’
If your search for updates in BatchPatch is not searching the same location as when you search for updates manually at the Windows Update control panel GUI, then you will not necessarily see identical results. In BatchPatch you can confirm the location that the target computer is configured to use by executing ‘Actions > Windows Updates > Get Windows Update configuration.’
3. It’s possible that what is appearing in the Windows Update GUI on the computer itself is not up to date. On newer Windows operating systems (i.e. Windows 10) this information is cached and can therefore become stale. Until the computer initiates a new search for updates to refresh what it is reporting, the search results it displays could contain out-of-date/inaccurate information.
4. Lastly, another reason for the discrepancy is if you’re using offline mode. Offline mode scans for security updates updates against the wsusscn2.cab file from Microsoft, which does not contain every update that is published on Microsoft’s public update servers. So, if you installed updates using offline mode and then later connected the computer the Microsoft’s public Windows Update server, you will see that Microsoft’s public Windows Update server offers additional updates.
I hope this helps.
-Doug
Nick – Deployment exit codes are coming from the target computer, not BatchPatch. They are typically going to be Windows error codes, not BatchPatch codes, hence why you see just a number.
Windows System Error Codes:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx
59:
ERROR_UNEXP_NET_ERR
59 (0x3B)
An unexpected network error occurred.
Windows Update error codes:
https://support.microsoft.com/en-us/kb/938205
2359302 ==> 0x00240006 (you can convert decimal to hex using http://www.rapidtables.com/convert/number/decimal-to-hex.htm)
0x00240006 WU_S_ALREADY_INSTALLED The update to be installed is already installed on the system
40025:
Justin – Please contact me via email to sort this out. This is an issue that you and I already discussed, and in our last exchange you had it working properly, so I don’t know what you’re doing differently now from then. From what you are describing, it should be working fine, and it’s not clear to me that you need to do anything differently from what you’re already doing.
-Doug
You have to first make the hosts column editable under ‘Tools > Enable / disable column editing’
Once that is done you’ll be able to click into the host name or select it and press F2 to edit it.
-Doug
OK great! HTML report or delimited file? Just curious.
Thanks,
Doug
Laurie – At this time what you could do is get the list of installed programs for the desired computers and then export the grid to HTML or delimited file. The delimited file could then be imported into Excel. It probably would still not be in the format you desire, but that’s the best option for now.
We’ll consider adding a report that provides a better format for consuming the information in a future release.
Thanks,
Doug
To be clear, the updates that you find via offline updates are all security updates. There are no “regular” updates via this method. Only security updates.
-Doug
There is not a built-in way in BP to do this. You would have to manually or with a script sort through the downloaded updated updates to pick the ones you want.
-Doug
In order to avoid having BatchPatch download the updates, for what you are describing I would suggest the following:
1. Create a BP URL list for the Win 7 updates.
2. Write a simple script that looks at each filename in the BP URL list and compares it to your directory of previously downloaded updates. Have your script then copy any matches it finds into a new directory.
A different option would be to go into your directory of previously downloaded updates and sort them by name. Then manually copy any desired files – perhaps the ones for Windows 7, into a new directory. Then set this new directory as your BatchPatch cache folder. Then download the entire repository of Windows 7 updates to that cache folder using the BatchPatch download updates repository option. This will skip downloading any files that already exist in the destination.
-Doug
No problem. Unfortunately there is a known issue with Win 10 1607 and Server 2016 getting updates from WSUS. It’s not a BatchPatch issue. Have a look through some of the google results and you’ll see what I’m talking about…
https://www.google.com/#q=1607+wsus
Good news is there is a solution – A Microsoft rep here says https://marc.info/?l=patchmanagement&m=147689665032051&w=2
“This issue should be addressed by the cumulative update released in late September. My suggestion would be to install the latest cumulative update via some other method, then the issues should disappear.”
And from what I have read further, the latest cumulative update (currently November) will fix the issue, so you do not specifically need the September version.
So, one option would be to manually install the latest cumulative update via BatchPatch’s ‘Deployment’ method. Download the update directly from Microsoft’s website, and then push it to your targets using a BatchPatch deployment. Alternatively you could go to BatchPatch ‘Tools > Settings > Windows Update’ and change the ‘Server Selection’ to ‘Windows Update.’ This will prevent you from having to modify the group policy or registry key on target computers that controls where they receive updates from. When you check for updates after modifying this BatchPatch setting, the computers will check against the Microsoft public Windows Update server instead of your local WSUS. After you install the available updates from the public server, then things should start working again with your local WSUS.
-Doug
Error 1611: 59
First, in the ‘All Messages’ column what do you see the line right before the ‘Error 1611:59’ appears? We would generally expect to see another failure right before it such as:
“Failed to obtain result. ERROR MESSAGE”
59 is a Windows system error code:
ERROR_UNEXP_NET_ERR
59 (0x3B)
An unexpected network error occurred.
It’s unclear to me what might have caused this. I don’t think it’s an issue with BatchPatch. I also wouldn’t be surprised if the issue goes away on its own. What happens if you try again after rebooting the target computers?
When you perform ‘Install downloaded updates’ in BP, the ‘Searching’ that you see take place occurs because before we can install updates we have to search for updates that have already been downloaded to the computer. This is actually an offline search that doesn’t reach out to WSUS or Windows Update, and normally this search should be quick, but it seems that something might have changed with Windows Updates this month because we did hear of one other customer (so far) who experienced very slow searching on Windows 2012 R2 targets this month too, similar to what you experienced.
Starting about 2 years ago, Windows 7 targets began to experience very slow search for updates. You can find discussions about this all over internet forums, and you can read our posting about it here: Checking for Available Windows Updates on Windows 7 Targets Takes Too Long
The aforementioned issue was not specific to BatchPatch usage, but rather was just slow searching for Windows Updates, regardless of the method used to perform the updates search/download/install. They claimed the issue was related to supersedence rule chain processing, which is why one of the characteristics is that svchost.exe consumes a lot of CPU while the search is taking place. That issue was resolved a couple of months ago (after plaguing users for the better part of 2 years) for Windows 7 targets, but now the behavior seems to be the same this month for at least some people with Windows 2012 R2. I would expect that if you checked the CPU usage during the search that you too would see svchost.exe consuming a lot of CPU resources while the search is being performed.
What we saw in the WindowsUpdate.log file for the one customer who reported slowness this month was that even for AutomaticUpdates, the search was also very slow. However, I think it seems fast when you do the action at the Windows Update control panel GUI directly on the target computer because Microsoft is utilizing some sort of caching, such that when you go to install the updates at the panel, the slow search was already performed behind the scenes, and so all you end up seeing is the download/install going pretty quickly.
Ultimately the issue is not something that we really have any control over since it’s tied to the Windows Update Agent and not to BP specifically, but we are researching and testing now to see if we can reproduce it or learn any more about what is really going on here. I will post here with any updates, and I predict that we will probably also end up posting about it in the BP blog at some point too.
-Doug
Sounds like an issue with PsExec not working properly on those two machines. The 233 is a Windows system error code:
ERROR_PIPE_NOT_CONNECTED 233 (0xE9) No process is on the other end of the pipe.I would first just test psexec at the cmd prompt from the BP computer to the problematic target computer by doing the following from the cmd prompt of the BP computer:
psexec \\targetComputer cmdAnd then see if you are able to issue commands successfully. Check for the existence of the psexesvc process on the target computer.
In some cases where psexec isn’t working quite right to a particular target computer, sometimes you can simply run it from a different computer, and similarly you can end up successfully running BP from a different computer.
In other cases switching the version of psexec can seem to help. If you can find a copy of an old version (ideally v1.98), you might have luck using that instead. We’ve even heard of a couple of cases where switching to an old version of psexec and then switching back to the latest version works.
Another option is to try paexec (a clone of psexec), and see if it works in place of psexec.
-Doug
cappper – In pointing out ‘Generate consolidated report of Windows Updates,’ my thought was that you would use it *instead* of running ‘Check for available Windows Updates,’ not *in addition to* running ‘Check for available Windows Updates.’ This way you would just run a single action in which you would be able to see which updates were applicable to your systems, based on your filtering selections.
I have added your suggestion to our list. Thanks.
-Doug
cappper –
First, I would strongly recommend that you select ‘critical,’ ‘security,’ ‘definition,’ ‘updates,’ ‘update rollups.’ Microsoft regularly delivers important updates under ‘updates’ and ‘update rollups’ too, so if you leave those unchecked you will be missing LOTS of important updates.
That said, if you still want to only select ‘critical,’ security,’ and ‘definition’ updates, then currently your best option would be to use the ‘Generate consolidated report of Windows Updates’ action. This will allow you to immediately see which updates will actually be applicable to your machines based on your selected classification filtering since there is a column in that report that will display the update classification, and the report grid can also be sorted by that same column, if desired.
-Doug
Glad you got it worked out!
Thanks,
Doug
Hi Paolo –
To do what you are wanting to do, you’ll need to use the BatchPatch Multi-Row Queue Sequence. You’ll probably use the advanced option, but depending on your needs you might also just use the basic option. Tutorials for this feature are at the following links:
Basic Multi-Row Queue Sequence Tutorial
Advanced Multi-Row Queue Sequence Tutorial 1
Advanced Multi-Row Queue Sequence Tutorial 2
For stopping and starting services inside of a multi-row queue sequence, you would probably use remote process/command actions that look like this:
NET STOP "DisplayNameOfService"
NET STOP "DNS Client"
NET START "DisplayNameOfService"
NET START "DNS Client"OR
WMIC SERVICE where caption='DisplayNameOfService' CALL stopservice
WMIC SERVICE where caption='DNS Client' CALL stopservice
WMIC SERVICE where caption='DisplayNameOfService' CALL startservice
WMIC SERVICE where caption='DNS Client' CALL startservice-Doug
BatchPatch lists logged on users in the following format:
3 users:
DOMAINuser1
DOMAINuser2
DOMAINuser3Since BatchPatch rows are only large enough to view one line at a time, you may use any of the following methods to view the contents of the cell:
‘Middle-click’ or ‘Right-click > View cell contents’ will display just the contents of the single cell that you clicked on.
‘Double-click’ will display the contents of the entire row that you double-clicked on.
‘Actions > Expand row(s)’ or ‘Right-click > Expand row(s)’ will display the contents of all selected/highlighted rows.
-Doug
-102: Failed to execute the search. HRESULT: -2145124322 =>
0x8024001E -2145124322 WU_E_SERVICE_STOP call was aborted due to service stop or system shut downSounds like you tried to execute the operation while the computer was shutting down or booting up, and the Windows Update service was not started.
When you kill the search it will produce an error. That is expected/normal.
-Doug
No.
If it says ‘Searching…’ then it is likely to actually be searching still. Killing it won’t solve anything because you’ll then just have to start over and wait for it to search all over again. The process is really not ever ‘stuck.’ But some computers can take a very long time to search for updates. This is not a BatchPatch issue. Generally it is a Windows 7 thing, which Microsoft acknowledged. You can read more about slow check for Windows Updates on Windows 7 here:
Windows 7 slow check for updates
-Doug