Forum Replies Created
-
Posts
-
Colleen – The BatchPatch command you are executing is executing successfully. So, if it’s not doing what you want to do, then it’s not a BatchPatch issue but rather an issue with the command that you’re executing.
I would suggest the following steps:
1. Determine the uninstall command for the desired software.
2. Run that command at the command line (*not* using BP) of a computer to test that it works.
3. Verify that the command worked by checking to see if the software was successfully removed. If it wasn’t, go back to step 1 and repeat until you determine the appropriate command are able to get it working at the command line *without* BP.
4. Once you have determined the proper command and have tested it and can get it to work at the command line *without* BP, then you can go ahead and run that command in BP.
P.S. – You said that after you remotely reboot the server, the software is installed. You should also make sure that the software isn’t reinstalling on reboot due to a policy or script that is setup in your environment. Make sure the command has done what you want before you reboot the machine. If the software is gone and you reboot the machine and it comes back, then you’ll know that you have an automated process that is reinstalling it.
Not currently. However, perhaps a better approach for what you’re doing would be to send just a single email report of the entire grid after all rows are complete, rather than sending one email per row. This way you can simply review one email at the end to see how the entire process went.
Probably within a few weeks.
-Doug
Matt – BP does not have any built-in disk-cleanup tasks. The act of downloading and installing updates requires disk space, as you know, so I’m not quite sure what you would expect to clean up on disk after patching. If you have a specific routine that you do or specific things that you delete, then presumably it could be scripted and we could execute the script with BP. However, I would imagine anything like this would be customized per-environment because you might want to delete files/folders that other users wouldn’t feel comfortable with, though I don’t really know as I’m only guessing.
-Doug
To *really* know for sure I would still install the OS from scratch on the updated system. Aside from that, unfortunately I don’t have any other suggestions at the moment since I’m not able to reproduce your issue, and it seems to be related to a specific hardware type, which is peculiar, as you’ve noted since the problem is occurring/manifesting in software, not hardware. I believe the problem is software-related, not hardware, but your guess is as good as mine right now since you have the actual systems in front of you. It certainly doesn’t make much sense that the same OS could be installed on two different systems, but then the systems behave differently. This does imply, as you originally stated, that the issue might be related to hardware specific drivers or applications. However, it’s nearly impossible at the moment for me to guess at what, specifically, is making the problems occur. I’ll think on this some more.
-Doug
SamelCamel – The date filter has already been coded in the next release, which will be published some time in the next handful of weeks.
Thanks,
Doug
It’s certainly peculiar that you only experience this issue on your Lenova Yoga2Pro devices. I agree with your assessment that it seems like it would be something related to Lenovo specific drivers or applications. Coincidentally there was recently a bit of security related news regarding Lenovo practices, where essentially it was discovered that they are using some technology to have the BIOS download/install/inject their own utilities even when performing a clean installation of Windows. It’s the “Lenovo Service Engine” (LSE), and it sounds like this could definitely be your culprit. And so now they have said “Lenovo’s use of LSE was not consistent with Microsoft’s guidelines. As a result, LSE is no longer being installed on Lenovo systems. It is strongly recommended that customers update their systems with the new BIOS firmware which disables and/or removes this feature.”
Here is just one of many articles on the subject:
If I were you I would update the BIOS on one of the Lenovo systems and then do a fresh install of Windows 10 and see what happens then. I have a feeling all will work fine for you then.
Keep me posted.
Thanks,
Doug
Thanks. I believe this new/second error occurred only because the first issue was occurring. If/when we are able to fix the first issue, the second one should disappear.
Separately, I’m pretty confident that if you run BP as a service on a different machine that is not your WSUS server, you will not encounter either error, though we will still plan to have another look at this problem before next the version is released. Hopefully we can eliminate it altogether.
-Doug
What kind of server are you experiencing this behavior on? Is it a web server? Is it running a non-standard edition of Windows? Is it your WSUS server?
I can confirm that this issue can only occur when the bps file is loaded into the service instance, and then the main BP instance tries to retrieve the data from the service instance in order to present the grid to you in the service instance viewer.
One other user had reported this, but it only occurred on one particular machine he was using, so he ended up using a different one. From our perspective it’s unclear why this is occurring, because we already set the value to be much larger than 8192. Additionally, the actual size of the XML data is generally going to be *much* smaller than that except in cases where the grid contains a *very* large amount of data. So, it’s unclear what causes this. We have so far simply not been able to reproduce the behavior. In theory, based on the error that is occurring, if you were to create just a single row .bps file as a test and then add it to service mode, that .bps file would be so small that it would not trigger the error. However, I suspect that in your case the error will still get triggered, and it’s unclear why. (Feel free to please test this and let me know what happens).
The bps file will continue to run the schedule while in service mode even if this error is occurring. The issue only occurs when BatchPatch tries to display the contents of the grid to you. However, removing the grid from service mode will certainly stop the error from occurring. Also, I suspect that if you run BP as a service on a different computer you will not see this error occur.
We will see what else can be done to prevent this from occurring.
-Doug
Perfect! Glad you worked it out. Thanks for posting an update.
Take care,
Doug
msuskin confirmed that this turned out to be a WSUS issue in his environment.
-Doug
Thanks! I’m glad it’s working for you! We really appreciate the support.
-Doug
Yes, you should be able to do this.
First create the custom remote commands (you’ll create the commands under ‘Actions > Execute remote process/command > Create/modify remote commands) :
Hardcode commands in BatchPatch
Once the commands have been created and tested, then go ahead and create the job queue. In the job queue after the ‘net stop service_01’ command add the special command called ‘Stop queue execution if previous action fails/errors.’
That’s pretty much all there is to it. If the service stop command doesn’t return 0 (success), then the queue will terminate.
-Doug
Thanks for confirming. We have plenty of other users using Windows 10 without issue. Additionally, we have no issues using Windows 10 in our lab. That said, at the moment I’m not quite sure what the issue is that you’re encountering. I will email you to troubleshoot further.
-Doug
And what happens when you try to use/run Windows Update manually on the target computer WITHOUT using BatchPatch? Does Windows Update work normally or does it throw the same (or different) error too?
Excellent. Glad you got it working!
-Doug
Looks like that’s a bug. I’m seeing now that it only saves the field when you “Apply deployment to row” or “Execute now.” We’ll get that fixed. Glad you highlighted it.
Thanks,
Doug
OK, that’s the problem.
Tools > Settings > Remote working directory default config is C:Program FilesBatchPatch
Actions > Deployment > Target working directory default config is C:Program FilesBatchPatchDeployment
The ‘Target working directory’ is not staging area on the server but rather is the staging area on the target computers, so the drive must exist. This is why you’re experiencing the error.
In the meantime, we will modify the error text so that it explains to look at the ‘Actions > Deployment > Create/modify > Target working directory’ instead of ‘Tools > Settings > Remote working directory.’
Thanks,
Doug
That’s peculiar. Thanks for confirming.
I know you wrote the error in your original posting, but can you confirm that is the *exact* message? Is there no error code or HRESULT included? Is the error definitely “The name cannot be found” as opposed to “The network name cannot be found” ?
Also, what is the deployment working directory path that you have set under ‘Actions > Deployment > Target working directory’
Thanks,
Doug
DJ – Thanks for the heads-up. Yes, we can add that. In the meantime you can also easily add this to your own instance of BP.
I hear what you’re saying that it seems like it shouldn’t be a DNS issue if those other things work, but I’m not sure that’s definitely the case because DNS is not always used. NetBIOS might be used in some cases, for example. Nevertheless, it’s simple enough to just try the IP address instead of the name, which will answer the question right away.
Let me know how it goes.
Thanks.
Sounds like it’s a DNS issue of some kind. I would suggest trying the FQDN instead of just the NetBIOS name. If that doesn’t work, try the IP instead of the name. It might be the case that there’s just an issue with the DNS cache on the BP computer not containing an entry for the target computer. You might be able to simply restart the DNS client service on the BP computer or restart the computer altogether. Or perhaps the issue is that there is simply no entry for the target computer on the DNS server.
Thanks for explaining. That is definitely helpful. We’ll consider this for a future build. In the meantime, if you want to accomplish this you can use something the following script with BatchPatch to check for multiple running processes. This script is setup to loop until the processes are not found, but it could be easily modified. The link below not only includes the script but also shows how to integrate it with BatchPatch. I hope this helps:
Advanced Script Integration with BatchPatch – Check for running processes on target systems
Another example of script integration plus a sample script:
Currently you have to do them one at a time. I’d be curious to understand how/why you plan to use this feature. Your thoughts might help us improve it.
Thanks,
Doug
Tools > Export…
Tools > Import…
abbypatch –
First, regarding the error you are experiencing, let me refer you to these two other threads. Please review them carefully, and let me know if you have any luck with the suggestions. Essentially, this issue has been reported by only a very small number of users, and it’s always only happening on just one or two of their servers. We have not so far been able to reproduce the problem.
error-2-hresult-2147024894-could-not-find-file
error-2-very-often-server-2012-r2-on-domain-controllers
The fact that you don’t receive the error with every run is peculiar, and I’m not quite sure what, if anything, to make of it.
Second, with regard to adding “Check for available updates” to the job queue, we will consider this. Thank you for the suggestion. In the meantime I have two suggestions for you that I think will probably both work instead of running ‘Check for available updates.’
1: Instead of using ‘Check for available updates’ the job queue does have the ‘wuauclt.exe /resetauthorization /detectnow’ command included, and I believe this will do what you need if you run it before you run the /reportnow command. It should solve the problem. However, if it does not, please try option 2.
2: Instead of using ‘Check for available updates’ you could try ‘Download available updates’ which essentially runs a ‘Check for available updates’ as part of the download process. Since there won’t be any updates to download, it will just check for available updates and find none to download. However, it will solve your problem of needing to run the ‘Check for available updates’ from within the job queue.
I hope this helps.
-Doug
It was already posted last week on 2015-08-21.
Thanks,
Doug
Sounds good.
Thanks,
Doug
Please try running Windows Update manually on the target computer (*without* using BatchPatch). Do you encounter the same error when using Windows Update manually? This might not be a BatchPatch issue at all.
-Doug
Excellent! I’m glad you got it figured out. Thank you for sharing your findings.
-Doug