Forum Replies Created
-
Posts
-
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.”
Hi Aaron – It is not currently possible to change the columns that are sent via email. The email will include any/all visible columns in the grid. However, we are considering possibilities for customization in a future version.
Thanks,
DougThe same consolidated update history report that you linked an image to above has a column for ‘Result’, which will show failures. That said, I’m unsure how useful this would end up being.
If you use BatchPatch to perform an update installation, BatchPatch will report in the ‘Remote Agent Log’ for that task the details of each update installation (success, failure, etc). The ‘Remote Agent Log’ column in BatchPatch is also saved automatically to the remote agent log file that is stored on the target computer (default location on target is C:\Program Files\BatchPatch\batchpatch.log). You can use the HTML export feature, mentioned in my previous posting, after an update installation task to review the failures. And of course you can review the batchpatch.log file on a target computer to examine the failures from previous tasks. However, aside from the update history report mentioned at the top of this posting there is not another way to pull a “live report” of updates installation failures that took place in the past.
This is a Windows Upgrade error, not a BatchPatch error.
-1047526908 => C1900204
Migration choice (auto upgrade) not available (probably the wrong SKU or architecture)· 0xC1900204
If you modify a job queue, you would have to re-apply that queue to your grids because the queue information is stored in the grid (to make the grid files portable without having to have the original queue created/existing on the server instance of BP- this was a tradeoff decision we made at design time). That said, we do realize this is not a good user experience, and we have plans for improvement.
As a workaround for now you can re-apply it to just a single grid to start. Then save the bps file for that single grid and open it in a text editor and find the change/update that you made. Then you could use the text editor to find/replace across all of your 53 files. Just make sure to test it because if you introduce an extra space or line break or somehow modify the format etc so that BP can’t understand/read it, it won’t work. And needless to say you’ll want to make a backup of your bps files before modifying them like this.
Hello – Thank you for sharing that posting. 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 very unlikely and require the attack to be targeted at you specifically instead of just a generic attack.
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 are also discussing adding an additional safety measure to BP soon that would 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 casual 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.
One other option you could consider for the time being is you could use PaExec instead of PsExec. We don’t know at the moment if PaExec is technically susceptible to the same kind of pipe squatting attack, but we do know that PaExec already adds a pseudorandom number to its remote service and pipe name, which means that if it were similarly vulnerable, the random pipe name would successfully mitigate the issue by virtue of it being unguessable in a casual attack, as described above. The main downside to PaExec is that if you are specifying alternate credentials for any row in the BP grid, these credentials are *obfuscated* when sent over the network using PaExec but not fully *encrypted* like they are when using PsExec. Realistically, while encryption would certainly be best, lack of encryption in this case is actually not necessarily as bad as it sounds, assuming you are operating on a switched network, but it’s definitely still something to consider if you use alternate credentials. More is explained here about why unencrypted credentials may not be as bad as it sounds, when using a switched network. To be very clear though, we always recommend using encryption whenever possible when passing credentials over a network. The article merely highlights that in some use cases there may be an acceptable risk to the user choosing an unencrypted approach.
Our recommendation is to continue using PsExec but to specify a custom service name as described at the top of this posting. We expect to release an update pretty soon that will further improve upon the custom service name setting by enabling the ability to also append a pseuodrandom number/string to it for each connection, as mentioned previously. However, if you decide you want to use PaExec, then under ‘Tools > Settings > Remote Execution‘ you’ll set a custom path under ‘Use psexec custom filepath‘ and have that filepath point to the location of your paexec.exe. If you choose to use paexec instead of psexec, then you’ll need to uncheck the box for ‘Use PsExec -r switch‘, otherwise it will throw an error when you try to perform any actions that utilize it.
The script generally works for most computers (for example it works on all of the computers we have here without any errors/issues), but if you have a particular machine where the script is not running successfully, then there is something specific to that machine that is causing the issue. You would have to setup some error handling in the script to get to the root of why that particular machine isn’t completing successfully. It could be a transient error with WMI on that computer, and restarting WMI or that computer could possibly resolve it. But it might also be some kind of corruption with the WMI repository or something else altogether. I can’t say for sure.
I provided the script to you as a template to show you an example of the kind of thing that is possible. However, you should customize it for your particular needs/desires:
To get the amount of RAM in use you have to do the calculation TotalVisibleMemorySizeKB – FreePhysicalMemoryKB. You can add this calculation directly in the script.
To get megabyte from kilobyte, you would take the kilobyte value and divide by 1024 or 1000, depending on how you define a MB (as either 1000KB or 1024KB). You can add this calculation directly in the script.
To change the format of the date-time, you’ll need to do some processing of that date-time result, which can also be added to the script. Here is an example: https://stackoverflow.com/questions/29535638/vbscript-how-to-convert-a-date-into-days-and-time
This is not currently possible, but we will consider adding some kind of “append” option for a future build.
In the meantime you would either have turn on the target computer to view the BatchPatch.log to see the history of what BatchPatch did with Windows Updates before the machine was shutdown, or you have two possible workarounds:
1. One option is to use multiple rows per host in the BP grid. So if you put the same “host1” into two separate rows in the grid, and then each row executed a Windows Update action at a different time, you would be able to see the log of both actions in the ‘Remote Agent Log’ column for each row. In this case you would have to take care to ensure that the rows’ executions do not overlap. The ‘advanced multi-row queue sequence’ could be used to ensure that the two rows are executed sequentially. Or you could use scheduled tasks for each row, just making sure that they execute far apart enough in time that they would not ever overlap.
2. Another option is to use “Save current-row HTML export” inside of the job queue. You can run that after each Windows Update action, and then on the BP computer you’ll have the details from the ‘Remote Agent Log’ column for each run saved in those HTML files that are created.
Hello –
1. You can export the grid to delimited file using “File > Export current grid to delimited file”
2. The following command will get the RAM numbers you want (in KB):
WMIC PATH Win32_OperatingSystem GET FreePhysicalMemory, TotalVisibleMemorySize3. We will consider adding the built-in ‘Get RAM usage snapshot’ to the job queue and/or task scheduler so that it can be scheduled to run without a custom command.
4. Below is a script that gets all of the information you asked about. You can incorporate it into BP as a “local command” with the following syntax. BP will pass the target computer name from the ‘Host’ column into the script by using ‘$computer’ as shown here:
Create a local command that looks like this:
cscript "C:\SomeFolderOnBPComputer\Scripts\ScriptSample.vbs" $computerHere is the actual script. Put it in a text editor and save it with a .vbs extension. Modify it as desired to get the results formatted in your preferred way:
'Gets the number of CPU Sockets, Cores, Logical Processors, OSVersion, LastBootUpTime etc. Cocobolo Software LLC December 2020. 'usage: cscript.exe script.vbs COMPUTERNAME strComputer = WScript.Arguments(0) on error resume next Err.Clear 'strComputer = TextBox.value 'InputBox("Enter the Computer Name or IP address") Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") OSVersionCaption = "" 'Get OS Version for CPU info Set colOperatingSystems = objWMIService.ExecQuery("Select * from Win32_OperatingSystem") For Each objOperatingSystem in colOperatingSystems OSVersionCaption = objOperatingSystem.Caption Next 'Get Processor Info (note: it can take a long time to pull info from this class) Sockets = 0 Cores = 0 LogicalProcessors = 0 WMISupport = 1 ProcessorName = "" If InStr(OSVersionCaption,"2003") or InStr(OSVersionCaption,"XP") or InStr(OSVersionCaption,"2000") Then WMISupport = 0 End If Set colProc = objWMIService.ExecQuery("Select * from Win32_Processor") For Each objProc in colProc ProcessorName = objProc.Name Sockets = Sockets + 1 Cores = Cores + objProc.NumberOfCores If Err.Number <> 0 Then Cores = Err.Description Err.Clear End If LogicalProcessors = LogicalProcessors + objProc.NumberOfLogicalProcessors Next If WMISupport = 0 Then LogicalProcessors = Sockets Sockets = "Property is not supported for this OS" Cores = "Property is not supported for this OS" End If OSVersion = "" LastBootUpTime = "" FreePhysicalMemory = "" TotalVisibleMemorySize ="" Set colOS = objWMIService.ExecQuery("Select * from Win32_OperatingSystem") For Each objOS in colOS OSVersion = objOS.Version LastBootUpTime = objOS.LastBootUpTime FreePhysicalMemoryKB = objOS.FreePhysicalMemory TotalVisibleMemorySizeKB = objOS.TotalVisibleMemorySize Next wscript.echo("CPU: " & ProcessorName & vbCrLf & "Sockets: " & Sockets & vbCrLf & "Cores: " & Cores & vbCrLf & "Logical Procs: " & LogicalProcessors & vbCrLf & vbCrLf & "OSVersion: " & OSVersionCaption & " " & OSVersion & vbCrLf & "LastBootUpTime: " & LastBootUpTime & vbCrLf & "FreePhysicalMemoryKB: " & FreePhysicalMemoryKB & vbCrLf & "TotalVisibleMemorySizeKB: " & TotalVisibleMemorySizeKB)The .cab file is extracted by BP into the wsusscn2 folder so that it can be parsed to get the relevant data needed by the “Download offline updates repository” action. What you see in your screenshot is expected/normal. It has nothing to do with why “Download offline updates repository” does not obey “Do not download newest wsusscn2.cab if any version is already cached”. I explained why that’s the case in my previous posting above.
Thanks,
Doug