Forum Replies Created
-
AuthorPosts
-
dougModerator
Thanks, Jason!
dougModeratorCurrently you’d have to change the registry entry on the target computer that controls where it receives updates from, then run BatchPatch, then change the reg key back to what it was before. However, we plan to release built-in functionality for this in a future build, likely to be published in early summer.
-Doug
dougModeratorThanks. If you have new build notifications enabled in Tools > Settings, then you will see this information automatically when a new build is released. If you don’t have “automatically check for updates” enabled, then you can see this info under Help > Check for updates at any time.
-Doug
dougModeratorI don’t understand what you are asking for. What are “regular patchnotes?”
-Doug
dougModeratorThanks for the suggestion, Tomas. We will plan on adding this soon.
-Doug
dougModeratorYou’re welcome Andi. I’m real happy to hear that you like the tool!
-Doug
dougModeratorHi Andi – you found a bug, which is now fixed in the 2013.3.21.20.10 build I just published a few minutes ago.
However, even though there was a bug in the software, you might still consider an alternate way of accomplishing what you’re trying to do.
In the way you’ve described doing this, you would end up copying the file from a network file share, down through your computer running BatchPatch, and then up to the target computer location. This will work fine, but for large files it might not be ideal to have your computer act as a middle-man for the file transfer, especially if you’re trying to do this for many target computers at once.
Instead you might consider using the “Remote Script/Process” with a command like this:
xcopy \someNetworkSharefolderfile.txt c:folderOnTargetComputer
This will execute the xcopy command on the target computer instead of the local computer running BatchPatch. So, the target computer will then directly reach out to the network share and copy the file back to itself, without the file ever having to be pulled through the computer running BatchPatch.
Hope this helps.
-Doug
dougModeratordougModeratordougModeratorThanks, Xenophane. This is coming in a future build. In the meantime you can use the WSUS_ConsoleAppQueryTool.exe, which is packaged in the batchpatch.zip file that we publish on our website at the BatchPatch Download Page, to retrieve this information for all computers.
The WSUS_ConsoleAppQueryTool allows you to query your WSUS server directly to find out which machines are pending reboot, which machines have downloaded updates waiting to be installed, and which machines haven’t checked-in with your WSUS server in X days.
-Doug
dougModeratorWe’ll consider this for a future build.
Thanks,
Doug
dougModeratorI emailed you directly so we can trade screenshots.
-Doug
dougModeratorI’m trying to decipher what you’ve written. Are you saying that there is a problem on one particular target host? Or are you saying that all target hosts have a problem? On the target host can you look in the remote working directory (typically c:program filesbatchpatch) to see if there is anything more detailed in the batchpatch error log or the batchpatch.log ?
-Doug
dougModeratorThanks for the suggestion, pausen! We plan on adding this in a future build.
-Doug
dougModeratorMiguel – You can do this under Tools > Options > Remote Agent Settings.
-Doug
dougModeratorLaurie – thanks for your business. As you can imagine, BP was originally designed with specific requirements. It was to be a real-time tool that was portable and could be launched many times in one session. These fundamental requirements are not particularly compatible with running it as a service. However, we have been toying with some clever ways to make running it as a service an option. And while it likely won’t happen in the very near future, we might move in this direction at some point down the road.
-Doug
January 17, 2013 at 6:09 pm in reply to: Scheduler Enabled and Row execution interval persistant? #9492dougModeratorThe current build of BatchPatch does not support this, but we can look to add it in a future build. Thanks for the suggestion.
-Doug
dougModeratorInteresting. I’m glad you got it working!
-Doug
dougModeratorInteresting behavior… Not sure what to make if it at the moment but thx for letting me know.
Yes, BP needs to be running in order for the task scheduler to operate.
-Doig
dougModeratorYes, BP has to create the folder. However, it’s unclear to me why you’d be able to “check for available updates” in BP when the computer is online, but if you wake it up and then try to “check for available updates” in a single job queue, it gets access denied. Sounds like odd behavior. I wonder what would happen if you put a few additional commands in the job queue, in between the wait 15 min and the “check for available updates.” So for example if you did something like:
1. wake on lan
2. wait 15 min
3. get last boot time
4. get c drive space
5. get stopped automatic services
6. wuauclt.exe /resetauthorization /detectnow
7. download available updates
What happens? Does every step fail with access denied? Or does the first one fail with subsequent ones working?
dougModeratorveix – I’m surprised that you’re able to get psexec to work in the way that you specified without having to use cmd.exe /C because I’m not able to get that to work. Additionally, I’m not able to get it to work even WITH the cmd.exe unless I specify the -u and -p switches to pass credentials to the other computer. This is expected behavior, due to how impersonation works. If I’m on computer A, and I want to run a .bat on computer B, but the .bat file is located on computer C, then this can only be done if I first pass credentials from computer A to computer B, where computer B then uses those credentials to access the .bat file on computer C. If I don’t pass credentials and instead rely on integrated security, computer A can access computer B, but on computer B there is no network access to connect to computer C. This is simply a fact of how impersonation works.
All that said, the BatchPatch code has not changed for the “remote script process” functionality, so I’m unsure how you would have had anything different work in an older version of BatchPatch.
Regarding your 2 questions…
1. Yes, alternate credentials are not ideal because they are passed in clear text to the remote computer. However, in a modern switched network environment, this is generally not necessarily all that big of a deal because the network traffic and clear text password will not be exposed to other computers on the network. Regardless of whether or not it’s ideal, it’s the only way to accomplish exactly what you’re describing, as far as I’m aware.
HOWEVER, as I suggested in the previous posting, you can use BatchPatch’s “Patch Deployment” feature, which will do exactly what you want and will NOT require alternate credentials. BatchPatch will reach out to the network share and get the .bat file, and then BatchPatch will copy that .bat file to the target computer and execute it. This scenario does NOT require alternate credentials because there is only a single hop (no double hop as in the first example).
I hope this helps.
-Doug
dougModeratorHi Laurie, it sounds like maybe 5 minutes simply isn’t enough time for the computer to come online after the wake on LAN packet is sent. Have you tried waiting longer… Maybe 10 or 15 min instead of 5?
-Doug
dougModeratorHi veix –
1. You’ll need to specify alternate credentials for this work. This is because when you connect to the target computer with integrated security, the target computer then tries to connect to a different network location but doesn’t have network access because it’s impersonating. So, if you specify alternate credentials, those credentials are first passed to the target system where they can be used natively without impersonating, and in that case they will have access to the network share.
2.
To PsExec a .bat file from the command line you’d have to do the following:
psexec \targetServer -u domainusername -p password cmd.exe /C "\networksharesomebatfile.bat"
To do the equivalent in BatchPatch, enter the following into the “Remote script/process” window:
cmd.exe /C "\networksharesomebatfile.bat"
Alternatively you could actually use the “Patch Deployment” feature in BatchPatch to do this. Just specify the .bat file as your “Installer file” in the “Patch Deployment” window, and then BatchPatch will take care of the rest. In this case you would not have to use alternate credentials because BatchPatch will actually copy the .bat file directly to the target machine and execute it there. I hope this helps.
-Doug
dougModeratorOk, thanks for the detailed info. I was able to track down the problem. It has now been fixed and published. The first fixed build is 2013.1.16.21.22
-Doug
dougModeratorXenophane – Thanks for posting. I have some questions.
1. What version of BatchPatch are you using? Check Help > About
2. Does the target machine have any room on its C drive or is it 100% out of space?
Thanks,
Doug
dougModeratorThanks for the suggestion. We’ll consider this for a future build.
-Doug
dougModeratorThanks! Im really happy to hear that you like the app. Unfortunately the current build doesn’t allow you to leave the files on the target. We can look into adding this option in a future build although I’d need a bit more info from you because right now it gets copied to a temp sub directory in the remote working directory, and this temp folder would not be a safe long term location. For the time being your best bet would be to have a separate script (you could use BP for this too) that copies the Msi back to the target after the installation is complete. However, I also then wonder where the Msi needs to be located in order to be found by the application that’s looking for it. Presumably it marks the original file location in some way so that it might actually require it to live in the temp BP working directory if that’s where it was originally installed from? Not sure.
-Doug
December 20, 2012 at 1:12 pm in reply to: Issue with location of PSExec when running .bps file #9472dougModeratorThanks for the information. We’ll update this to work as expected in a future build. However, in either case, the immediate solution and the recommended way to avoid any issues, in general, is to put PsExec in your Windows PATH. So, for example you can just drop PsExec.exe in the C:Windows or C:WindowsSystem32 folder, and then you’ll never have an issue again. Or simply set the PATH to wherever you have the PsExec.exe – https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/path.mspx?mfr=true
We have heard of a few cases where a user has put psexec.exe in the PATH but for some reason has still had trouble, but then after moving psexec to the same location as the BatchPatch.exe, the problem disappeared. It’s not exactly clear why for some users the behavior is different. However, in either case we will address this in a future build so that it’s possible to hardcode into BatchPatch the location of psexec.
dougModeratoredpa – this isn’t going to work, unfortunately.
-Doug
dougModeratorHi Mark – thanks for the suggestion. Could you explain to me how this would be useful? What I mean is that I don’t see why anyone would need to regularly run this command in his/her environment. It seems like something that someone would only need to run every once in a great while, or never, or only for a particular misbehaving machine. What am I missing here? Also, I assume you are now running this command manually in BP but you’re asking for it to be hardcoded so that you don’t have to manually type it in, yes? Thanks.
-Doug
-
AuthorPosts