Forum Replies Created
-
Posts
-
For sales etc contact us directly at BatchPatch Contact Form
If the cmd is giving you the proper result, then I’m sure BP is too. However, because of the column size in BP it is wrapping to the next line. You can view the entire column contents by using the middle click mouse button in the cell or right click on the cell and choose view cell contents. Then you will see the entirety of the result instead of just the top line.
Thanks. What do you see if you run the wmic command at the cmd.exe command prompt *without* using batchpatch? What is the result in that case of just running the command manually?
Have you examined the setting under ‘Control Panel > All Control Panel Items > System > Computer name, domain, and workgroup settings > Computer description’? Have you made sure it matches this text? “Surface Book 2 – Rene de Vries”
The query you specified is the correct query to get the “Computer description” field from the target computer. This is the field that you see under “Control Panel > All Control Panel Items > System > Computer name, domain, and workgroup settings > Computer description.” This is *not* the same information that would appear in the Active Directory ‘Description’ field.
FYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.
FYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.
On January 12 2021 another PsExec update was published that fixes the 32/64 bug, so now the standard psexec.exe (32 bit version) works as expected.
On January 12 2021 another PsExec update was published that fixes the 32/64 bug, so now the standard psexec.exe (32 bit version) works as expected.
Thanks. Also just FYI for anyone else who reads this thread, the 64/32 bit weirdness appears to be a bug in the new version 2.3 of PsExec. At the moment it seems that you have to use the 64 bit version for 64 bit targets, and the 32 bit version for 32 bit targets. We believe this is not a “feature” but rather is a bug, so we are anticipating a fix/update from Microsoft/Sysinternals.
Thanks. Also just FYI for anyone else who reads this thread, the 64/32 bit weirdness appears to be a bug in the new version 2.3 of PsExec. At the moment it seems that you have to use the 64 bit version for 64 bit targets, and the 32 bit version for 32 bit targets. We believe this is not a “feature” but rather is a bug, so we are anticipating a fix/update from Microsoft/Sysinternals.
Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.
Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.
Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe does not have the same issue. I would suggest you try psexec64.exe. Please let me know what happens.
Looks like on January 11 2021 PsExec version 2.3 was released. However, we don’t know at the moment if it fixes the issue, though we assume there is a good chance that it does. Also, in our initial test, and confirmed by one other user, PsExec 2.3 seems to not work properly. In BP it produces ‘Error 1611:233 Failure’. We don’t know yet if all BP users would experience this or only some. We are investigating. Not yet sure what to make of it.
Looks like on January 11 2021 PsExec version 2.3 was released. However, we don’t know at the moment if it fixes the issue, though we assume there is a good chance that it does. Also, in our initial test, and confirmed by one other user, PsExec 2.3 seems to not work properly. In BP it produces ‘Error 1611:233 Failure’. We don’t know yet if all BP users would experience this or only some. We are investigating. Not yet sure what to make of it.
Thanks. Please do let me know if your 2.2 version works too.
Additionally… a while after writing the above response to you, I noticed that Microsoft had released a new version of PsExec today (version 2.3), and so I downloaded it to give it a try, and lo and behold I got the same ‘Error 1611:233 Failure’ that you got. It seems evident that something changed in between PsExec versions, though I don’t yet have a guess as to what. We are investigating.
Please see: BatchPatch Troubleshooting Guide
This is an indication that PsExec is not able to successfully complete its operations. The 233 is a Windows system error code:
ERROR_PIPE_NOT_CONNECTED 233 (0xE9) No process is on the other end of the pipe.If I’m understanding you correctly, you are experiencing this from one BatchPatch computer to any/all target computers. This would indicate that the issue is likely something related to the BP computer, so as a start it would be a good idea to test running BP from a different computer. If it works from a different computer, then you might just use that different computer until/unless you can locate the source of the issue on the original computer.
Presumably before you purchased a license you were running the evaluation version successfully, so what changed in between then and now? Were you using a different BP source computer when testing the eval vs now?
Another thing that you can try is under ‘Tools > Settings > Remote Execution’ if you enable the option to ‘Use PsExec -r switch to specify remote service name’. You can put any name there that you want, such as BatchPatchExeSvc. When PsExec is being blocked due to security restriction, it can cause the “No process is on the other end of the pipe” error. The setting mentioned above can sometimes bypass this type of issue.
If no luck, I would next 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, as mentioned previously.
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 for whatever reason. From a security perspective, using an older version of PsExec, indefinitely, is not optimal, especially if using ‘alternate credentials’ because those are passed in plain text over the network, whereas PsExec version 2.1 and newer encrypts credentials over the network. Note, this is only relevant for when you specify “alternate credentials” in BatchPatch. If using “integrated security” then credentials are not ever sent across the network regardless of the version of PsExec. More on this topic here.
Another option is to try PaExec (a free and open source clone of PsExec), and see if it works in place of PsExec. PaExec obfuscates but does not encrypt credentials sent across the network, so it’s similar to older versions of PsExec in that regard and isn’t optimal as compared to PsExec new versions (though older versions of PsExec don’t even obfuscate the credentials like PaExec does). To use PaExec then you would go to ‘Tools > Settings > Remote Execution’ and change the ‘Use psexec.exe custom filepath’ to point to the PaExec.exe on your computer.
We have only heard of the 233 error a handful of times over the past many years, so it’s rather obscure and doesn’t usually seem to have a definitive cause/solution.
What OS is the BatchPatch computer running on in your case?
What OS are your target computers?
-Doug
If you use the real-time operation (not scheduled, not job queue, not email notification): ‘Actions > Get info > Check if file exists’, the result will be reported in blue text if the file exists, red text if does not exist. So, in this way it’s easy to select an entire grid of hosts and run the check in a single operation against all hosts, and then you have your result immediately visible with red and blue coloring of the text in the ‘All Messages’ column. This will take just several seconds to execute across a large number of hosts, so there is no need to kick it off and walk away. However, you would not be able to sort the rows/results based on the colored text though. It will only sort alphabetically. As a workaround to this you could select/highlight each desired row and move them into a different grid (Actions > move). This would enable you to get all of the hosts that found the file (or that didn’t find the file) into their own grid, which might be helpful to you. Not sure. You could also manually move the rows up and down in the grid to group them. This would be somewhat annoying in a large grid, but I’m just mentioning it so that you’re aware that it’s an option, in case it helps. To move a row or a group of rows up or down, highlight/select them in the grid and then use ‘ctrl-shift-plus’ or ‘ctrl-shift-minus’.
I understand, in general, why someone might want to schedule tasks vs run things in real-time. Obviously we have the scheduler for that purpose. However, it isn’t/wasn’t immediately clear to me why you would want to specifically check for the existence of a file, triggered by a scheduled task. What I mean is that it’s very clear when someone wants to run, for example, a Windows update installation in the middle of the night via scheduled task. This is because you might have a certain time window where a machine can be updated/rebooted, and you want to be asleep during that process because it’s at 2AM or something like that, and then you would like to wake up and just check your email to make sure everything went ok with no major alarms. However, in the case of checking for a file’s existence (or application’s existence) normally that’s the type of task that a sysadmin would be doing in real-time during the workday, while sitting in front of the computer, not scheduled in the middle of the night. So, it helps for us to understand the ways that our customers are using the app, especially when they are not expected or typical ways. This is why I was trying to learn from you more about what you’re doing and why you’re doing it… so that we could then assess if it might make sense to update the app to accommodate some unexpected type of usage. Also because frquently we have someone who is doing something one way simply because they don’t realize that there is another better or different way. And in those cases it helps us to know what the actual end goal is, as opposed to what the specific action is that someone is running. That is to say, sometimes a user will be focused on “I’m trying to do X”. And I’ll want to understand WHY he/she is trying to do X so that I can suggest a Y alternative that might be better (if there is such an alternative available), rather than focusing on getting X to function in a way that it was not really designed to do… like trying to put a square peg in a round hole when we actually have a round peg available in the app that the user was not aware of.
If you use the job queue operation to check if a file exists, then you’re correct that it would be more difficult to parse the results of the ‘All Messages’ column in that case. So, using the job queue branching to set the row colors makes sense in this case in order to make the results easier to see. However, if your sole purpose of the job queue is to check if the file exists (and not actually be executing some other action based on whether or not the file exists), then using the job queue doens’t really make sense here, and instead it makes more sense to just use the ‘Actions > Get info > Check if file exists’ option, I think, unless I’m misunderstanding your needs. That said, this ‘check if file exist’ option is not schedulable on its own. So if it must be executed as a scheduled task, then it would have to be executed inside of the job queue, so in that case you would be back to coloring the rows with goto labels like you were doing. But of course then if you email the grid, you won’t see those row colors. The row colors will only be visible in the BatchPatch grid, not the HTML export/report/email. In the current release of BP you cannot sort by row color, but in the next version that should be coming out pretty soon, you will be able to sort by row color. Coincidentally this is something we added last month to the code… it just has not yet been published.
Yes, $grid sends the entire grid, and $row sends just the row. So yes, if you are trying to just send a single email for the entire grid, then you would use $grid. But in the case where you are having each individual row’s job queue send an email, in that case probably you want to set each row’s email notification to $row.
Lastly, with regard to “data collection” through email notifications… Note also that you can save each grid to its own .bps file, which I think would be much better for retaining data than sorting through old HTML email notifications. Also, the .bps file will, of course, retain all of the row colors, unlike the HTML email notifications. We’ll consider adding row colors to the email notifications in a future build.
I hope this helps.
FYI: details of how the local privilege escalation is accomplished are here.
The simplest thing you can do right now to mitigate this issue is under ‘Tools > Settings > Remote Execution‘ set a value for ‘Use PsExec -r switch‘. When you enter a custom value in this field, the PsExec remote service and named pipe are created with that custom name instead of the default name, PSEXESVC. In this way a malicious user pipe squatting on your target servers as \PSEXESVC won’t have any impact on you because your pipe will be created as \YourCustomName. The malicious user would have to know/guess your custom pipe name in advance in order to cause trouble, which would be highly unlikely and require the attack to be targeted at you specifically instead of just a generic attack. Additionally, note that this is a local privilege escalation, which means that your machine would *already* have to be compromised by a malicious user in order to perform it. It would allow the attacker to gain higher level privileges on the computer, but the computer would already have to be compromised with lower level privileges, so the threat level of this attack is realistically not very high in most cases.
That said, we don’t know at this time when Microsoft will address the issue directly in the PsExec code (they apparently did suggest that they will release an update to PsExec to resolve this, though it’s unclear when), so we will be publishing an additional safety measure to BP soon that will enable you to add a pseudorandom number/string to your custom name so that every single action would get a unique remote service and pipe name. This would virtually eliminate any possibility for exploitation by making the pipe name even more unguessable, thus further reducing the possibility of any pipe squatting on that name. And we will additionally be considering other possibilities moving forward as well.
The HTML email report does not have the row colors that the grid has. That said, if your queue is only sending the email when the file is not found, then what purpose does the color even serve? If you receive the email, then you know that the file was not found for that row, right? It sounds like maybe you are using $grid for your email notification, but perhaps you should be using $row instead… this would then instruct the email to send the contents of just the row that sent the email, not the entire grid’s rows.
And so yes, if you use the “Automatically Trigger an Email Notification for an Entire Grid Only After All Targets’ Actions Have Completed” you will not see the row colors. Those colors exist only in the grid and not in the HTML report, as mentioned above. I’m not sure if we would modify this behavior, but we’ll consider it.
All that said… I don’t really understand why this is being setup for email. I mean… if you want to see if a bunch of computers have a particular file on them… why not just run a single BP task (at any time you want, when you are sitting in front of your BP installation) where you select all rows and then execute ‘Actions > Get info > Check if file exists’ at which point you will instantly know for any number of computers whether or not they have the file or not.
You can use the job queue… there is a special item “If specified file exists, goto label:X” as well as “If specified file does not exist, goto label:X”. Then specify a label to goto and use the “Set row color” special item and/or “send email notification.”