Forum Replies Created
-
AuthorPosts
-
dougModerator
Thanks. Yeah this is really more of a feature than a bug. We wanted the import to allow comma and period delimited, so it was a trade off. You have a couple of options:
1. Obviously you could use something else in place of the comma
2. You can type the notes manually into the grid rather than importing them with the host names. Then you can save the grid to .bps or .bpt to use again over and over rather than freshly importing the hosts with notes every time.
3. We’ll consider modifying or improving the behavior of the import process.
Thanks,
Doug
May 21, 2019 at 10:00 pm in reply to: Write Notes/Notes2/etc Column from Get Information Output Log/etc #9790dougModeratorWe will consider this for a future build. Thanks for your feedback!
-Doug
dougModeratorYou have a couple of options:
Download the desired cumulative/monthly update from the Microsoft Update Catalog, and then deploy it using the BatchPatch deployment feature
OR
Use offline mode in BatchPatch (in your case you would probably want to go with scenario 3) to deploy the cumulative/monthly update from the previous month. In this case you would select the option
"Tools > Settings > Windows Update > Do not download newest wsusscn2.cab file if any version is already cached."
You can take the desired month’s wsusscn2.cab file and put it in your BatchPatch cache folder, and then with that checkbox checked BatchPatch will use that specific wsusscn2.cab file without downloading the new/current one.dougModeratorUpdate Date Filtering:
Tools > Settings > Windows Update > Only install updates that were published/approved at least X days ago
. You can insert any value for X.OR
Use the update include/exclude filters to choose specifically which updates you want to include/exclude from installation:
May 17, 2019 at 6:46 pm in reply to: Ability to set schedule to the next day for computers retaining the time? #9826dougModeratorHi Tim – We actually do already plan/expect to add functionality that would solve this problem.
Thanks,
Doug
dougModeratorYou can review the classification of any available update in the ‘Remote Agent Log’ column after a ‘Check for available updates’ or in the BatchPatch.log file (Actions > Windows updates > View Batchpatch.log) for a given target host. In the sample BatchPatch.log content below the classifications of each update visible at the end of the first line of data for each update, so the classifications in this case are:
1> Update Rollups
2> Updates
3> Definition Updates
4> Upgrades
COMPUTER1 05/17/2019 14:13:44
::Begin online search - Server Selection: Default
The search query "ImportantAndRecommended" returned 4 update(s):
1> Windows Malicious Software Removal Tool x64 - May 2019 (KB890830) (7 MB) (2019-05-14) - Update Rollups
(Type-SoftwareUpdate | Downloaded-FALSE | RebootRequired-MAYBE)
http://support.microsoft.com/kb/890830
2> 2019-05 Update for Windows 10 Version 1709 for x64-based Systems (KB4023057) (1 MB) (2019-05-16) - Updates
(Type-SoftwareUpdate | Downloaded-FALSE | RebootRequired-FALSE)
http://support.microsoft.com/kb/4023057
3> Definition Update for Windows Defender Antivirus - KB2267602 (Definition 1.293.1811.0) (186 MB) (2019-05-17) - Definition Updates
(Type-SoftwareUpdate | Downloaded-FALSE | RebootRequired-FALSE)
http://support.microsoft.com/kb/2267602
4> Feature update to Windows 10, version 1803 x64 2019-05B (3528 MB) (2019-05-14) - Upgrades
(Type-SoftwareUpdate | Downloaded-FALSE | RebootRequired-MAYBE)
http://support.microsoft.com/kb/4499167
::End search
COMPUTER1 05/17/2019 14:13:51May 16, 2019 at 4:39 pm in reply to: Error 1601: Failed to retrieve WMI info. No such interface supported #9823dougModeratorAs noted in the BP ports link in my previous posting, ports 135 and 445 are just for PsExec, not for WMI. WMI uses dynamic ports. If you confirmed that BP works properly when it’s running directly on the system in question, then you can be confident that the issue that you’re encountering when running it from the WSUS system is firewall related. Most modern enterprise firewalls have a setting that works for WMI dynamic ports, so it should be fixable. However, that would require you to make modifications to the firewall, of course. If you are not able/allowed to make further modifications to the firewall, then unfortunately the only other option would be running an instance of BP in the DMZ.
dougModeratorPlease see configuring-ping-status-alerts-in-batchpatch
May 16, 2019 at 3:52 pm in reply to: Error 1601: Failed to retrieve WMI info. No such interface supported #9820dougModeratorWhile it appears that you have confirmed that WMI is probably not the issue, it would be ideal if you could do one more confirmation test that will take just a moment.
Launch a copy of batchpatch.exe on one of the target systems in the DMZ as administrator. It can just be the free evaluation version– it does not need to be licensed. Ok so go ahead and launch the batchpatch.exe as administrator (right-click ‘Run as administrator’) and then enter the host name of the system that you have launched it on. What I mean to say is that if you are launching BP on HOST567, then please enter HOST567 into the BatchPatch grid so that we can test BatchPatch running on the system itself, which will confirm whether or not WMI is the issue or if it’s a firewall issue. Then attempt whatever action it is that you were attempting. Is it successful or does it produce the same “No such interface supported” error? If it produces the same error, then it would seem that the issue is, in fact, related to a problem with WMI on that computer. If it works fine and it only produces that error when running BatchPatch from the WSUS to act upon the target system in the DMZ, then it’s going to be a firewall issue. The following two links will help you resolve a firewall/port issue:
dougModeratorJared – While it’s possible that BP has the feature that you’re looking for, I can’t confirm because I don’t understand clearly enough exactly what you are asking about.
You said:
…”allows for an admin to log updates as approved or unapproved”
and
…”Manage Engine Patch Manager Plus… had a function to track this”
Could you please clarify exactly what you are asking? Please be as detailed and specific as possible. What you wrote is a bit too vague for me decipher exactly what you want to know.
Thanks,
Doug
May 9, 2019 at 4:14 pm in reply to: Feature Request – Auto Opt-In to Microsoft Update if Unknown Update Source Error #9814dougModeratorHi Bob – Thank you for your feedback. We will consider all of this for a future build. In the meantime I would suggest for your situation that you simply always use the “opt-in” action. It sounds like in your environment you cannot guarantee that computers will be opted-in already, which is fine. I would suggest you simply always run the opt-in action before checking for updates. If a computer is already opted-in, then it will continue to be opted-in. If a computer is not yet opted-in, then you will force it to opt-in when you run that action. This way you can guarantee that you won’t ever encounter “unknown update service”, and it removes the need for you to have a contingent operation for that error.
-Doug
dougModeratorThanks. We’ll see what we can figure out.
-Doug
dougModeratorYou found a bug. Thanks for bringing it to our attention. The issue is with “Terminate queue if previous ‘Check for available updates’ finds 0 updates”, which is crashing the job queue thread when the previous check for updates returns an error instead of producing a result. That’s why it just sits there indefinitely. We’ll have this fixed for the next release. In the meantime your options are to either not use the “Terminate queue if previous ‘Check for available updates’ finds 0 updates” or to use something like this instead, which will force the queue to terminate if the check for available updates errors so that the 3rd step in the queue is just never executed in that case and therefore cannot crash the thread:
1: Check for available updates
2: Terminate queue if previous action fails/errors
3: Terminate queue if previous ‘Check for available updates’ finds 0 updates
-Doug
May 6, 2019 at 5:16 pm in reply to: How to push script to client without sharing mdtshare to Everyone? #9806dougModeratorMike – I’m sorry to say that I can’t really understand well enough what you are describing to suggest a solution. However, the following link has numerous tutorials for how to create and execute a deployment in BatchPatch. You should be able to use these to model your current deployment.
BatchPatch Software Deployment
If you continue to have issues and would like further assistance, perhaps you can try again to explain as clearly as possible but include screenshots and any other supporting information to help illustrate exactly what you are doing and what is happening. You may contact us to establish an email dialog for this purpose, if desired.
dougModeratorJay – I’m sorry to say that I can’t really decipher what you’re describing well enough to suggest how to rectify it. It sounds like you just have something misconfigured, but I can’t understand well enough what you are describing to tell you what you’re doing wrong. If you want to take another stab at describing again in a different way, as clearly as possible, I’ll see if I can give you a better response. If you think screenshots will help illustrate your issue, feel free to contact us via email, and then we can then get a dialog going to send/receive screenshots along with your description of the issue.
Thanks,
Doug
dougModeratorbooster – have you tested the old version side by side with the new one? I’m wondering if the issue might be due to a change in server 2016 that happened in between last time you used BP on it to now when you used the new version of BP. We didn’t change anything in BP that would/should affect the load time of the app. The best guess I have is that it is something with the Windows SmartScreen. The new version of BP has a new certificate because the old one expired. I wonder if possibly the Windows SmartScreen check of the new certificate is what is causing the delay.
-Doug
dougModeratorStep 1: Parameterize your powershell script so that it can accept arguments. Multiple examples of how to do that are explained here: https://stackoverflow.com/questions/5592531/how-to-pass-an-argument-to-a-powershell-script
Step 2: Run a local command in BatchPatch to execute the script.
‘Actions > Execute local process/command > Create/modify’ :
powershell.exe c:scriptspowershellscript.ps1 vCenterName, ResourcePoolName
or if you want to pass the host name from the BatchPatch ‘Host’ column you can use $computer :
powershell.exe c:scriptspowershellscript.ps1 $computer, vCenterName, ResourcePoolName
dougModeratorWe do not have any such documentation.
dougModeratorI’m not sure what it could be since the code didn’t change in those commands between the last and current version. I noticed in your video that there is no tab header status icon, which makes me wonder are you definitely using the current version of the app? Or did you just disable it under ‘Tools > Settings > Grid prefs > Show tab header activity / alert images’.
I know you said the issue didn’t exist until you started using the new version, but I’m wondering have you since gone back and tried the previous version to see if it still does not occur in the previous version even though it occurs in the current/new version? Also are you running BP on the same computer as you always were or did you change computers or start running BP in a VM or something like that in between the last time you used the older version and the time that you started using the newer version?
dougModeratorHi Mike – Yes you can do that. You would just need to parameterize the inputs so that you can pass them into the script at the time you run the script rather than having the script prompt you with a dialog. Below are a few different tutorials that should give you an idea of how you can do it.
dougModeratorThere are two things happening here.
1. The ‘Save’ item remains grayed out after you modify the column visibility. We are aware of this, and it’s a design option that we chose intentionally for reasons that are difficult to explain in this posting. The bottom line though is that the grid data needs to be modified before the ‘Save’ item will be activated. Adding or removing a column without actually adding/modifying data in the grid will not activate the ‘Save’ item. We do not plan/expect to change this behavior. To get around this, your solution of using ‘Save as’ and then overwriting the .bps file is your best option. There is nothing wrong with doing this, and it will work properly.
2. You found a bug that prevents the ‘Disk Space (%)’ column from being automatically displayed when loading a grid that had been saved while it was visible. ‘Disk Space (%)’ is the only column where this occurs. ‘Disk Space (MB)’ and all other columns will properly be displayed when loading the .bps file if they were visible when the grid was last saved. Thank you for highlighting this bug. We will look to address the ‘Disk Space (%)’ column auto-display on load in a future build.
-Doug
dougModeratorGlad you got it worked out! That’s my mistake. All of my examples were intended to have the .msi in quotes. Thanks for reporting back.
dougModeratorI’m unable to test this myself because I don’t have the .msi in question, but I would try the following syntax options in the ‘Command to execute’ field. I’d expect that at least one of them should work. Let me know.
msiexec.exe /i SpiceworksAgentShell_Collection_Agent.msi /qn SITE_KEY=”CY3qdCi8EPHqDbHAsWd0″
msiexec.exe /i SpiceworksAgentShell_Collection_Agent.msi /q SITE_KEY=”CY3qdCi8EPHqDbHAsWd0″
msiexec.exe /i SpiceworksAgentShell_Collection_Agent.msi /qn SITE_KEY=CY3qdCi8EPHqDbHAsWd0
msiexec.exe /i SpiceworksAgentShell_Collection_Agent.msi /q SITE_KEY=CY3qdCi8EPHqDbHAsWd0
msiexec.exe /i SpiceworksAgentShell_Collection_Agent.msi /qn SITE_KEY=’CY3qdCi8EPHqDbHAsWd0′
msiexec.exe /i SpiceworksAgentShell_Collection_Agent.msi /q SITE_KEY=’CY3qdCi8EPHqDbHAsWd0′
dougModeratorIn the deployment configuration window you would have to manually modify the ‘Command to execute’ field to make the syntax what you want it to be.
-Doug
dougModeratorI think you’re asking about the WSUS SID. According to the following link, there are a few registry values that store this information.
https://gallery.technet.microsoft.com/scriptcenter/Reset-WSUS-Authorization-2e26d1b0
Registry values to look at:
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate
PingID
AccountDomainSid
SusClientId
SusClientIDValidationBatchPatch can retrieve registry values from target computers using ‘Actions > Get information > Get registry key/value’
dougModeratorI don’t have an explanation for why you would see significantly different load times between the two versions, but I would suggest that you simply try running BP on a physical machine or a VM with more horsepower. For comparison, on my physical workstation, which is approx 8 years old, the current version takes only 2 seconds to load. The older version also takes 2 seconds to load.
dougModerator“load” times? I’m still confused. Are you describing the amount of time that it takes to launch BatchPatch? So like from the time that you double-click the batchpatch.exe until the time that the BatchPatch window appears?
dougModeratorPaul – I actually don’t really know what you’re describing or what you’re comparing. I don’t think it’s the same thing that Justin is talking about. If we just use your 2008 example for a moment, what are you saying took an average of 8 seconds on 2018.10.4.14.1 as compared to an average of 40 seconds on 2019.3.20.16.58?
dougModeratorJustin – I don’t think there is anything in the new version that could cause the behavior to be different than the previous version. Have you tried both versions side by side to compare? The code didn’t change for the actions you’re talking about.
-Doug
April 3, 2019 at 5:46 pm in reply to: Remote Execution – cannot find/fails to create output log #9849dougModeratorYour log illustrates the problem at this line:
Wed-10:07:50> Remote Command (logged output): Executing \target -s
You are executing an empty/blank/non-existent command. You are not executing ‘wmic bios get serialnumber’ as you think, else we would see the command in that line. I’m not quite sure where you’re going wrong, but hopefully this helps you figure things out. Maybe you are creating the command under Remote command logged output 1 but then executing Remote command logged output 2? Maybe you created a saved remote command but you only gave it a title but didn’t give it command syntax to execute? Seems like the issue has got to be something similar to that where you just aren’t properly executing the command, so you end up submitting a blank command instead.
-Doug
-
AuthorPosts