Forum Replies Created
-
Posts
-
I posted a link (twice) above that describes the possible causes and resolution steps. Please review it.
We will look at adding an option in a future build to automatically exclude disabled rows from synchronizations. In the current build you would have to manually add the desired computers to the ‘Exclude hosts from synchronizations’ list in the grid synchronization settings window.
Does the uppercase DNS suffix create some kind of problem? Or is it just visually distracting/uncomfortable? I’ll discuss with the team. I’m not sure if there is a reason for it or if it was just to standardize the values.
-Doug
Makes sense. Thanks for the update.
-Doug
If it stays “Executing” indefinitely, it generally means that it did not actually run “quietly” and instead it is waiting for user input of some kind. However, since it runs hidden, of course no user input can be provided.
I would suggest that you test this syntax manually at the command prompt WITHOUT using BatchPatch. Get your syntax working manually at the command prompt without it requiring any user interaction. Once you have the syntax figured out at the command prompt, then you can easily port it into BatchPatch.
Assuming your parameters and syntax work at the command prompt without requiring any user interaction, then when you enter the command into the BatchPatch deployment the “Command to execute” field would look something like this:
msiexec.exe /p "YourFileName.msp" REINSTALLMODE=omus REINSTALL=ALL BB_DEFAULTVIEWER=0 BB_DESKSHORTCUT=0 IGNORE_RBT=1 DISABLE_WELCOME=0 /qnNOT like this:
msiexec.exe /p "C:SomeFolderYourFileName.msp" REINSTALLMODE=omus REINSTALL=ALL BB_DEFAULTVIEWER=0 BB_DESKSHORTCUT=0 IGNORE_RBT=1 DISABLE_WELCOME=0 /qnThe likely cause of this is that psexesvc is not running successfully on the target. Normally psexec creates the psexesvc service on the target computer, but this is likely failing in your case. It might be that there is antivirus or other similar blocking in place.
I would start by trying the following setting in BatchPatch:
Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service nameThis setting allows you to modify the remote service name that is used by psexec from ‘psexesvc’ to ‘BatchPatchExeSvc’ or any other custom name of your choice. In the case where anti-virus or other security related software is blocking the remote service from running, changing the name of the remote service with this setting can often work to bypass the restriction for some of those applications without having to add psexesvc to a whitelist.
I would also suggest reviewing these postings:
Thanks. It sounds like psexec is blocked on the computer. This can happen as a result of Windows settings that prevent running an executable file that was obtained from somewhere else until after permission has been explicitly granted. One way this manifests is with a popup of a dialog that says “File Insecurity Warning” and prompts you to either check or uncheck a box to make sure that it never prompts again. The issue with this is that if you are running BatchPatch as a user that is not the logged-on user, then this popup might not be visible. It’s also possible that this popup doesn’t appear at all. Another way that this can usually be resolved is to right-click on the psexec.exe and select ‘Properties.’ Then on the ‘General’ tab at the bottom there is a section titled ‘Security’ that says “This file came from another computer and might be blocked to help protect this computer. Then there is a checkbox next to that to “Unblock.” Select the checkbox and click ok.
Please confirm you got everything working.
-Doug
Can you give me the verbatim text that it gets stuck on?
The app never says these two things exactly:
“initiate windows update…”
“initiate deployment”
In order to troubleshoot this to determine exactly where things are getting stuck, I need to start with learning the exact text that you’re seeing hang indefinitely. There are too many places with *similar* text, so I can’t pinpoint your issue without knowing the exact text.
Thanks.
PsExec is a tool, not a criminal. A tool can be used by a criminal or a tool can be used by a law-abiding person. If a criminal uses a tool, does it make sense for the law abiding person to stop using that tool? What impact would this have on the criminal’s behavior or usage of the tool? For example, if a criminal used a car as the transportation mechanism to rob a bank, what would it solve if you then stopped driving your car?
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.
Normally 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.
Your 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?
OK, glad you got everything working.
A 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
If 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.
The 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.
You 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
I 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.
You’re very welcome.
PsExec 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.
PsExec 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
OK, 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.
One 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.
The 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
I 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:
The 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.
We would need to know the HRESULT value to determine why there was the failure.
batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx
Generally 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.
In 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.
That’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.