Forum Replies Created
-
AuthorPosts
-
July 26, 2019 at 4:58 pm in reply to: Is there a what's new file for each release of BatchPatch? #11656dougModerator
Yes, whitelisting our domain will be sufficient. This would then also enable the BP check for updates to work from that server in addition to being able to view the change log.
July 19, 2019 at 12:05 am in reply to: Error "Deployment: Queued" and never pushes the package #11653dougModeratorNormally if you can get info like MAC address but can’t do Windows Updates, then the issue is something with PsExec. In your case it doesn’t really add up that Windows Updates works but Deployments are getting stuck. Generally it should be all or nothing. Either both should work or both shouldn’t. It’s peculiar that one would and the other wouldn’t. Seems like certainly one quick option for you would just be to move the licensed app over to the working computer. However, if you would rather get to the bottom of the actual issue on the problematic computer… to be precise which of these two messages are you seeing?
Deployment: Queued...
Deployment: Queued file copy operation...
Are you running BP as a different user than the logged-on user? I mean are you launching BP by right-clicking the batchpatch.exe and using ‘run-as’ to run it as a different user? Or are you logged on with the user account that is running BP? Or are you entering “alternate credentials” into a given row per target?
The things to look at relating to psexec are:
1. Is Windows blocking it from running or is Windows popping up a dialog in the background (or possibly hidden altogether if BP is being run as a different user than the logged on user) where Windows wants you to confirm that it’s ok to run the app. This can happen when you download an exe from the internet. Windows pops a “File insecurity” warning that it wants you to acknowledge, and there is a checkbox to either check or uncheck to prevent it from appearing again. Another way this manifests in Windows can be rectified by right-clicking on the psexec.exe and viewing the properties window. There is a “blocked” or “unblocked” or similar checkbox (I forget exactly how they word it) that can be checked or unchecked to unblock psexec.exe.
2. If you have some type of security related or anti-virus software that is blocking psexec, one option that frequently can be used to get around it is under ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify a remote service name.’ You can give it a custom name like BPExeSvc or similar. And if that doesn’t work you could try disabling or removing any antivirus or similar security related software altogether.
July 18, 2019 at 9:55 pm in reply to: Error "Deployment: Queued" and never pushes the package #11651dougModeratorYour support expiring would have no impact on the functionality of the app. I’m honestly not quite clear on what you’re describing with your licensed version vs the free evaluation. Are you saying that in your licensed version you encounter the issue but then you downloaded the free evaluation and you’re not encountering the issue there? It doesn’t really make a ton of sense because they are the same application… only the eval has some restrictions. But the actions themselves are all executed with identical code. What works in one will work in the other, so maybe you are launching them on different computers or under different user accounts, or are they different versions of the app? Those are the only things that could potentially produce different behavior from one to the other. I’m not quire sure from your description alone what’s really going on. I would suggest you start with this troubleshooting guide to narrow down what might be happening or where it’s occurring. The more info you’re able to provide to me, the more likely I’ll be able to help you get to the bottom of it. For example is it just that one package that is problematic? Or are all packages not working? And were all of these packages previously working and have now stopped without any changes to them?
July 17, 2019 at 9:56 pm in reply to: Error "Deployment: Queued" and never pushes the package #11649dougModeratorOK, glad you got everything working.
dougModeratorA timeout generally means that the SmtpClient was either unable to connect to the SMTP server or the connection was severed or lost at some point during the send operation.
I would suggest going back to ‘Tools > Settings > Email notifications’ and testing your email configuration with the ‘Test email settings’ button to make sure emails are able to send successfully. Your issue could be caused the SMTP server being unavailable or unresponsive at the time of error, or it could be caused by a firewall on that is blocking outgoing connections to the server or blocking outgoing connections on whichever port you are using etc. I believe we have even seen a timeout occur as a result of the mail server limiting the size of attachments to a smaller value than the attachment size that is attempting to be sent.
-Doug
dougModeratorIf you have a script or a command to perform the activation but you don’t know how to run the script or command inside of BP, I can help you do that, but you would need to provide the script/command.
June 27, 2019 at 6:11 pm in reply to: Synchronize with AD Groups and automaticly use AD user alternate credentials #11642dougModeratorThe credentials that you specify in the grid synch settings are for connecting to the target domain during the sync to retrieve the list of computers to be synchronized. Currently that is their only purpose/function. We will consider your desire for a future version. In the meantime the way to accomplish your goal is to put each separate domain in its own BatchPatch grid, and then use the grid’s row template feature to automatically populate the alternate credentials fields in the grid when hosts are added during a synch.
dougModeratorYou can use the example at this link for guidance. It doesn’t do *exactly* what you are trying to do, but it does something very similar. Essentially you just need to have your script return 0 if the service is started and a non-0 int (such as 1 or -1) if the service is stopped. If you use ‘Terminate queue if previous action fails/errors’ immediately after your script deployment, then it will terminate the queue if the script returns anything other than 0.
batchpatch-custom-script-integration-install-windows-updates-only-after-stopping-a-specified-service
dougModeratorI don’t have a VMWare server to test with, but it appears that the first command that you are executing establishes a connection, and then the second command instructs the server to create the snapshot. Since the second command appears to be dependent on the connection first being established with the first command, you wouldn’t be able to run these successfully as two separate commands in BatchPatch. There will likely be no context for the second command because the first command was completely independently run. My guess is it will probably work to chain the two commands together into a single command using the semi-colon like this:
cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "Connect-VIServer -Server vCenter.domain.com; New-Snapshot -VM VM1 -Name Pre-Patch"
Alternatively you can put them in a .ps1 script file and then create a BatchPatch deployment for the .ps1 script file. Then include the deployment as part of your job queue.
dougModeratorYou’re very welcome.
dougModeratorPsExec only needs to be present on the BatchPatch computers. Do not put it on target computers. When it runs it copies psexesvc.exe (this is embedded in the PsExec.exe) to the target. It installs that exe as a service. When done with each operation it then removes the service that it previously installed.
OK, so Cisco AMP is capturing command line text. This has nothing to do with what is being sent across the network by PsExec. On the BP system the credentials have to be sent from the BatchPatch.exe process to PsExec.exe in clear text. This would be equivalent to you running PsExec yourself at the cmd prompt and submitting credentials to it. Then when PsExec performs the remote execution, it encrypts everything before transmitting over the network.
All that said, if you want to avoid the use of credentials altogether, then just run BP with integrated security. Use option 1 or 2 at the following link:
batchpatch-authentication-in-domain-and-workgroup-non-domain-environments
Using alternate credentials in the way that you are currently using does not pose a threat as far as network capture is concerned because the psexec network transmissions will be encrypted. However, if malicious software got installed on the BP computer, then of course it could capture pre-network data or in-memory data or on-disk data or keyboard strokes etc just like Cisco AMP can. At that point though of course any usage of that computer is a problem, not just BP usage.
dougModeratorPsExec v2.11 and newer version automatically encrypt credentials. There is nothing additional that needs to be done. It would seem to me that you have the following possible things happening:
— Maybe you’re not actually using the version of PsExec that you think you’re using? Maybe you have multiple copies of PsExec on the computer and BP is not using the one you expect?
— Maybe credentials are encrypted but you are getting a false alert from Cisco AMP. I’m not sure how Cisco AMP would be able to know whether or not credentials are encrypted. That to me seems like something only a human would be able to know. I don’t know what the alert looks like that you are getting from Cisco AMP, but is it possible that you are simply misinterpreting the alert? Or it is possible that the alert is misrepresenting the actuality? Maybe it’s warning that PsExec is being used but it’s not specifically stating that it detected clear text credentials?
In any case it’s quite easy to verify that there are no clear text credentials being sent by simply capturing traffic with Wireshark and reviewing it. If you have concerns then you should fire up wireshark and review the packet capture.
-Doug
June 13, 2019 at 1:54 pm in reply to: Ability to not reboot prior a defined time and wait for operations #11631dougModeratorOK, no problem. For custom functionality like you are describing you can still use scripts similar to what I described in the above posting. You would just need to modify the scripts to do exactly what you need instead of using the script as-is without any modifications.
June 12, 2019 at 7:09 pm in reply to: Ability to not reboot prior a defined time and wait for operations #11629dougModeratorOne option is to schedule the job queue like this:
Download and install updates
Wait X minutes
Reboot (force, if required)
If the job queue is scheduled for 5AM, but you don’t want the reboot to occur before 7AM, then you could do this:
Download and install updates
Wait 60 minutes
Wait 60 minutes
Reboot (force, if required)
In the above case the reboot would occur some time after 7AM, depending on how long the ‘Download and install updates’ operation took.
If your goal is to completely separate the scheduled tasks so that you have one scheduled task for the ‘Download and install updates’ plus a separate scheduled task for the ‘Reboot (force, if required)’ then you would either have to separate the tasks far enough apart in time that you can safely assume that the installation has completed when the reboot task starts, or otherwise if the tasks are scheduled close enough together that you can’t safely assume that they won’t overlap then you would have to use a custom script to make sure that the reboot does not occur while the ‘Download and install updates’ action is still running. The tutorial on this page shows how you could use a custom script to check for the existence of a process on the target computer. It will only proceed when the specified process is no longer running. In this case you could modify the script to look for batchpatchremoteagent.exe. If that process is not present, then the BatchPatch Windows update action is not running.
dougModeratorThe 5 in ‘1620: 5’ would generally mean access denied, which is a permission problem, but this is not how BatchPatch would typically report an actual permissions problem. That said it’s hard to know for sure what is going on in this case. I see you have the target going OFFLINE then ONLINE at one point in the middle of an operation. This could mean that the reason for the 1620:5 failure was actually due to a network issue or the target computer going offline or some kind of other weird issue like if you have anti-virus software running on the target that is killing the connection or the batchpatchremoteagent.exe or the remote psexesvc.exe service. If it occurs repeatedly as opposed to just being a transient issue I’d suggest using the troubleshooting instructions at this page to see if you can determine exactly where things are going wrong.
batchpatch-troubleshooting-guide
Also if you have antivirus software running on the target then it would be worth trying a different remote service name as described here, just to see if that might make a difference:
what-to-do-when-psexec-is-blocked-by-your-anti-virus-software”>batchpatch-troubleshooting-guide
June 11, 2019 at 6:46 pm in reply to: Run Command Prompt From BatchPatch In "Administrator Mode" On Host #11625dougModeratorI copied your exact syntax (without the quotes) and inserted it into BatchPatch remote command, and it works properly with both SYSTEM and Elevated token remote contexts. I was able to execute it successfully in all remote commands 1,2,3 and 4 without issues.
‘Local command’ is not what you want for this. ‘Local command’ is for executing a command on the BatchPatch computer, not on the target/remote computer.
As a side note, there is another way to add registry values using the BatchPatch deployment action:
June 10, 2019 at 10:00 pm in reply to: Run Command Prompt From BatchPatch In "Administrator Mode" On Host #11623dougModeratorThe issue is probably nothing to do with those settings. In order to troubleshoot it I would need to see exactly what you are doing… what is the exact syntax that you are trying to execute, and how exactly are you trying to execute it in BP? Remote command 1/2 or 3/4 or with a script deployment or some other way? What is the exact error message text? etc.
dougModeratorWe would need to know the HRESULT value to determine why there was the failure.
batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
June 10, 2019 at 7:17 pm in reply to: Run Command Prompt From BatchPatch In "Administrator Mode" On Host #11620dougModeratorGenerally speaking either one should work for your needs. They effectively have the same privileges, and 99% of the time they will behave the same as far as permissions are concerned.
June 10, 2019 at 6:55 pm in reply to: Run Command Prompt From BatchPatch In "Administrator Mode" On Host #11618dougModeratorIn the default mode that BP runs, if the account that you use to run BP is in the local admins group on the target computer, or if you specify alternate credentials for the target host’s row in BP with an account that is in the local admins group on the target computer, the command will be executed as administrator (elevated token) when it runs on the target computer. The setting that controls this is under ‘Tools > Settings > Remote Execution > Remote Execution Context’. If you were to change that setting to ‘Normal’ then it would no longer execute the remote command with elevated token.
June 8, 2019 at 11:54 pm in reply to: Batch Patch Not Actually Updating The "Host" Computer/s #11617dougModeratorThat’s very peculiar. What version of BP is this? Check under ‘Help > About’. I’m not able to reproduce it. It seems as if somehow the scan is completing and finding the 126 updates, but the actual list of those updates is somehow not getting populated properly in BatchPatch. BatchPatch uses that list of updates to determine what the next step is, and if the list is empty it ends the task because it thinks there are no updates available. We haven’t ever seen this happen, so I’m unsure of how it could actually manifest in your case. However, as a first step I’d like to know what happens when you execute ‘Actions > Windows updates > Retrieve consolidated url list of available updates.’ Based on what you are currently experiencing, it seems like this list will somehow end up not populating. Does the url list grid populate? Does the all messages log report again that it found 126 updates? Let me know what happens, and then we’ll go from there. We’ll probably need to work via email to trade more info after that since this forum is rather rudimentary.
dougModeratorThanks. 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:
-
AuthorPosts