Forum Replies Created
-
Posts
-
Unfortunately I do not know exactly what this means. -198 occurs in BatchPatch when the Windows Update Agent (WUA) fails to add the WsusScn2.cab as a scan destination for Windows Update. The HRESULT is the reason code produced by Windows (not by BatchPatch). Under normal circumstances we would only see -198 occur with HRESULT values that indicate the WsusScn2.cab file is missing or corrupt or unsigned.
HRESULT -939523075 converts to C80003FD
However, I cannot find this documented anywhere in Microsoft’s documentation or on the web. We have never seen this error before.
Considering that this appears to be undocumented and that we have never seen nor heard of it before, my best guess is that this is related to your forum posting from yesterday, where it became clear that you are running Windows versions on unsupported hardware. Windows has preventive measures in place to disallow Windows Updates from being performed on OSes running on unsupported hardware, as you know. I think that is the most likely reason you are experiencing the error.
Microsoft’s error text for that HRESULT is:
0x80240037 -2145124297 WU_E_NOT_SUPPORTED The invoked functionality is not supported.This is not a BatchPatch error per se. It is a Windows Update error. While it might be possible for other circumstances to trigger the same error as above, in your case based on the fact that you resolved it by installing the program at the linked github page, it sounds like you are running a version of Windows OS on hardware that is not supported by Microsoft for the OS version that you are running.
Excerpt from the github project that you linked to:
“The release notes for Windows updates KB4012218 and KB4012219 included the following:
‘Enabled detection of processor generation and hardware support when PC tries to scan or download updates through Windows Update.’
These updates marked the implementation of a policy change they announced some time ago, where Microsoft stated that they would not be supporting Windows 7 or 8.1 on next-gen Intel, AMD and Qualcomm processors.
This is essentially a big middle finger to anyone who decides to not “upgrade” to Windows 10, and it is especially unfortunate considering the extended support periods for Windows 7 and 8.1 won’t be ending until January 4, 2020 and January 10, 2023 respectively.
Some people with older Intel and AMD processors are also affected! I’ve received user reports of the following CPUs all being blocked from receiving updates:”
Intel Atom Z530
Intel Atom D525
Intel Core i5-M 560
Intel Core i5-4300M
Intel Core i7-4930K
Intel Pentium B940
AMD FX-6300
AMD FX-8350
AMD Turion 64 Mobile Technology ML-34
The github project that you linked to attempts to enable Windows Update on older versions of Windows running on computers with newer/unsupported processors. The project author may or may not be accurate in his/her assessment that “This is essentially a big middle finger to anyone who decides to not “upgrade” to Windows 10, and it is especially unfortunate considering the extended support periods for Windows 7 and 8.1 won’t be ending until January 4, 2020 and January 10, 2023 respectively.” However, regardless of your opinion about Microsoft’s motives for the change, if you are running a version of Windows on hardware that is not supported for that version, you’re asking for problems. We do not recommend doing this. Additionally, if you are already doing this, we also do not recommend installing such a program as the one in this github project on your computers. It may resolve the issue temporarily or perhaps indefinitely, but installing such a program would of course be done at your own risk, as it may break the OS in some way or cause instability etc.
Microsoft blogged about the changes to hardware support here: https://blogs.windows.com/windowsexperience/2016/01/15/windows-10-embracing-silicon-innovation/
Under normal circumstances BP will delete the files in the cache folder, but there may be certain situations where it does not, such as in the event of a failure or error of some kind. You may delete the contents of the cache folder at any time (except while BP is in the middle of an update installation) without causing any problems.
-Doug
You can change the color of rows with ‘Actions > Modify category, description, location, notes, color etc.’
You can’t pin or hide a row. Not sure why you’d want to disable it unless the goal in that case is to color it. However, now you know how to color it without disabling it, so hopefully that gives you what you need.
As for it getting in between real hosts when sorting, you should be able to easily at least force it to be at the top or bottom just by naming it accordingly. So like you could name it zzzzz or aaaaa or ….. or whatever makes sense. Then it won’t get put between other rows when sorting. It will only go to top or bottom.
-Doug
Hi Justin – Thanks for the feedback. I’m glad to hear that you like the tool!
There is not currently such a button, but we’ll consider adding one for a future build. In the meantime I would suggest you create a “dummy” row in each grid, and then setup each dummy row with a scheduled task that runs daily to initiate the synchronize operation. Once you have it setup you won’t have to manually synchronize each grid anymore. They’ll all sync on their own at the scheduled time each day. I hope this helps.
-Doug
You’re very welcome. Thanks for the feedback. I’m happy to hear that you like the app!
-Doug
BatchPatch can only input a single MAC into the ‘Mac Address’ field, and there is no way for BP to know which MAC to use, so BatchPatch ‘Get MAC Address’ gets the MAC from the first network adapter on the target computer that has an IP address.
If you want to use WoL in BP with a different MAC, then you can simply enter a different MAC manually into the ‘MAC Address’ field in BP, or when you add a host to the grid you can add a MAC with the host using the syntax below:
hostName#1CF6565D4631If you want to use BatchPatch to retrieve all of the MACs from the target computer adapters that have IPs, you can use the following syntax inside of a BP ‘Remote Command Logged Output’. However, this won’t insert a MAC into the ‘MAC Address’ field/column in BP. This will simply get a list of MACs for you. Then you can choose the one you want to manually enter into the ‘MAC Address’ field.
WMIC PATH Win32_NetworkAdapterConfiguration WHERE IPEnabled=True GET MacAddressNo.
Glad you got it worked out. Note, Microsoft does not publish *all* updates to the WsusScn2.cab file. It’s only security updates and service packs plus a few others. In this case it sounds like maybe the update you were missing was an update for Windows Update itself. Would have been nice if they delivered it in the WsusScn2.cab file, but apparently they didn’t.
Thank you for your feedback. We will consider these items for a future build.
-Doug
BP should find the same updates as the manual check for updates, so long as BP and the manual check are looking for updates in the same place and are not filtering any of the results. After all, BP is using the Windows Update Agent to perform the check. This is the same way that the manual check with Windows control panel does it. We have *never* seen a case where a discrepancy could not be easily resolved, so I believe we should be able to figure out what’s going on in your situation. There are some things that still need to be tried.
The plan was to take the internet connected tablet and run BP in two modes.
1. Run BP in offline mode with that tablet as target host. The results should be the same as when you ran BP in offline mode against the offline tablet. Also, are you certain you have the latest WsusScn2.cab file?
2. Run BP in online mode with that tablet as a target.
A. In online mode make sure in BP you have ticked ‘All software updates’ AND ‘All driver updates’.
B. With ‘All software updates’ AND ‘All driver updates’ ticked, in BP try the following three different tests for checking updates. Under ‘Tools > Settings > Windows update > First try checking for updates against ‘Microsoft update’ which should be the most inclusive, and then try checking for updates against ‘Windows update’, and finally try to check against ‘Default/managed’.
Some other questions… what OS version and service pack or update level is running on the tablet?
Did you confirm that the tablet is showing you accurate (not stale) results? When a search is performed with BP, it’s real-time and gives real results each time. However, when you look at the Windows Update control panel directly on the computer, it will frequently show stale/old/outdated results. At the cmd prompt of that tablet you can run ‘UsoClient.exe startscan’ to refresh the stale results. See if it then reports different updates than it was reporting before.
Based on the information you have provided it seems like the issue is between what is being offered in the WsusScn2.cab file for that computer vs what you are expecting to see available for that computer. To test this I would suggest that you take the tablet that you are able to connect to the internet and have BatchPatch in online mode perform a check for available updates on that target tablet against Windows Update. Then with that same tablet as the target perform the check for available updates in offline mode against the WsusScn2.cab. That should give you the answer if the issue is what is contained in the WsusScn2.cab vs what is being offered online from Microsoft. I hope this helps.
-Doug
Did you read the link I posted above? It explains every possible reason that BatchPatch could report a different number of updates from the Windows Update control panel.
When you say “I have another tablet, with the exact same load on it, and hooked that one to the internet and it found 9 updates, a couple were the same, but the other 7 were different.” … how are you checking for updates on that one? What is the process? Are you using BatchPatch in online mode? Are you going to the Windows Update control panel without using BatchPatch? Are you checking on the update catalog or in a web browser?
In any case I would encourage you to please read very carefully through every reason explained in the link that I posted higher up in this thread. We have not ever seen nor heard of (nor could I imagine) a different reason for the behavior that you are experiencing that is not already explained/addressed in the link. It’s also possible that the updates for the tablets that you are hoping/expecting to see were simply not published by Microsoft in the WsusScn2.cab file, and so you wouldn’t be able to “find” them when using BatchPatch in offline mode.
-Doug
It was fixed last year in version 2017.11.09. Are you sure you are encountering the *same* issue as described in this posting? I just tested 2018.10.4.13.0 and it works properly, so I suspect if you are encountering an issue, it’s not the issue that is described in this posting. Please be as descriptive as possible when explaining the issue that you are encountering.
Thank you. We’ll take a look!
Sounds like an issue with PsExec not working properly on that 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 cmd
And 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.
Also please review this page. The error you are seeing could be caused by the same things that are described here:
troubleshooting-errors-1611-64-1620-64-1611-2250-1620-2250
-Doug
Thanks.
I think you’ve got it backwards. Ivanti Patch for SCCM is a plugin for SCCM that enables you to deploy/update third-party apps through SCCM. You would still be working inside of SCCM as your console, not the other way around. I believe SolarWinds has something similar. In either case I think you are asking for or hoping for the opposite behavior where you can be working inside of the third-party app to control SCCM. I don’t think such a thing exists. And frankly, I don’t really understand what the purpose of having SCCM is if you want to use a third-party tool to apply the updates that have been approved in SCCM. Please update me here if you find that I am somehow mistaken about this.
Thanks,
Doug
BatchPatch cannot currently do this. What other third party tools are you referring to? I’m not aware of any that do what you are describing, but if you’re able to point us to the tools that you are speaking of, we’ll research them to see what we might be able to do.
-Doug
Thanks for confirming.
-Doug
We published a fix for the resolution issue today. Vertical resolutions less than 1024 should now display BatchPatch windows properly. However, the DPI would still always need to be a “normal” DPI of 100%/150%/200%. “Irregular” DPIs such as 125% or 175% will be problematic.
Looks like you found a bug. I just did some testing, and here is what I found:
When BatchPatch is running in default/normal/regular mode (NOT cached mode), BatchPatch will not download updates for which the update classification box is unticked in ‘Tools > Settings > Windows Update > Update Classification Filtering’
When BatchPatch is running in cached mode, BatchPatch will still download updates to the BatchPatch cache folder for which the update classification box is unticked in ‘Tools > Settings > Windows Update > Update Classification Filtering’. The update will be downloaded to the BatchPatch cache folder, and the update will be copied to the target computer’s temporary cache folder ‘C:Program FilesBatchPatchcache’, but BatchPatch will *not* actually cache the update in the target computer’s Windows Update repository. This is to the say that Windows Update on the target computer will not know anything about the downloaded update and will still think the update is NOT downloaded. The update files in question will only exist in the BatchPatch cache folder and in the target computer temp/staging/cache directory – default is ‘C:Program FilesBatchPatchcache’ but will not be “downloaded” to the Windows Update database/repository on target computers.
Note, if an update is excluded in the textual/graphical filters in BatchPatch, the update will not be downloaded at all. But if it is not excluded by the textual/graphical filters and it is only excluded by unticking the ‘update classification filtering’ box, then when cached mode is enabled, the update will still be downloaded to the BatchPatch cache as noted above but will not be downloaded to the target computer’s Windows Update repository, and so Windows Update will have no idea about it. This means that the only issue it can/would/should be able to cause is taking up space on disk in C:Program FilesBatchPatchcache on target computers, but you can safely delete this folder at any time.
We will look into getting this fixed asap.
Thanks,
Doug
Then place script.vbs in a folder with your signature.file. Update the script to replace “signature.file” with whatever your actual signature file is named. So now you have the script.vbs along with your signature file in a folder on the BatchPatch computer. Next create a BatchPatch deployment to deploy the script.vbs. Tick the box that says “copy entire directory…” in the Deployment configuration. Then execute the deployment. If the Signatures folder does not already exist on the target computer this script will not automatically create it. The result is that all user profiles on the target computer that have the Signature folder will get a copy of the signature.file in that folder.
Copy the script text below to notepad and then save it as “script.vbs”
On Error Resume Next
Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set objRegistry=GetObject("winmgmts:\" & strComputer & "rootdefault:StdRegProv")
strKeyPath = "SOFTWAREMicrosoftWindows NTCurrentVersionProfileList"
objRegistry.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubkeys
For Each objSubkey In arrSubkeys
strValueName = "ProfileImagePath"
strSubPath = strKeyPath & "" & objSubkey
objRegistry.GetExpandedStringValue HKEY_LOCAL_MACHINE,strSubPath,strValueName,strValue
Set fso = CreateObject("Scripting.FileSystemObject")
If InStr(Ucase(strValue),"C:WINDOWS") = 0 Then
' Wscript.Echo strValue & "AppDataRoamingMicrosoftSignatures"
fso.CopyFile "signature.file", strValue & "AppDataRoamingMicrosoftSignatures", True
End If
Next%username% works fine in BatchPatch remote command (logged output), but %username% doesn’t solve your problem because it will only echo the current user when using elevated token or the computer name when using SYSTEM. But the current user is going to be the admin account that you are using, not each/every user account on the computer. However, it sounds like your goal is to copy the email signature file to each user profile on each computer. To do this you would need to write a script that enumerates each user profile folder in C:Users, and then loops through that list to copy the file from the same directory as where the script resides to each profile folder on the same computer. Once you have a script like this working properly locally without using BatchPatch, then you could deploy the script plus the signature file using a BatchPatch deployment where you put both the script and the signature file in the same directory, and then you create the BatchPatch deployment with the “copy entire directory” box ticked. When the deployment runs it will copy the folder containing the script and the signature file to the target computer, and then it will run the script on the target computer which will copy the signature file from the script directory to each user profile directory. Just make sure that in your script you reference the signature file just by “signaturefile.whatever” without specifying an absolute path. This way no matter what the actual path is, so long as the signaturefile.whatever is in the same directory that the script runs from, the script will be able to find it when it executes the copy.
Some things have changed since that tutorial was written. In some cases it may be necessary to use the syntax from the tutorial whereas in other cases it might not be needed anymore.
Glad you got it figured out. This should also work:
powershell.exe -command "wevtutil el | Foreach-Object {Write-Host "Clearing $_"; wevtutil cl "$_"}"I’m not quite sure what “export the email notifications” means. If you are saying that you want to export the settings contained in ‘Tools > Settings > Email notifications’ to a file, this is not possible.