Forum Replies Created
-
AuthorPosts
-
dougModerator
We’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
dougModeratorThanks for the suggestion. We’ll consider hardcoding this into a future build. In the meantime you can still accomplish this in BatchPatch by hardcoding your own commands in the “user-defined” commands section (see Actions > Remote Process > Create/modify user-defined commands).
You would want to create the following two commands:
WMIC SERVICE where (DisplayName='Windows Update') CALL ChangeStartMode Automatic
WMIC SERVICE where caption='Windows Update' CALL startservice
-Doug
dougModeratorThe user list is reported below the first line. So either middle click on the cell to see the entire list of users or doubleclick/expand the entire row.
-Doug
dougModeratorAjo – we will consider this for a future build, but I cannot make any guarantees. We’ll need to think through the pros and cons.
Thanks,
Doug
dougModeratorA normal reboot via WMI is initiated first. If it fails, then a force reboot via WMI is initiated. This is the same as the “reboot (force, if required) option.”
-Doug
dougModeratorI will get back to you on this soon…
November 15, 2012 at 1:00 am in reply to: BatchPatch compatibility with Windows 7 64bit and Windows Updates via SCCM 2007 #9459dougModeratorUnfortunately I don’t believe the issue has anything to do with 32 vs 64. There’s something else that SCCM is doing with the target WSUS server, that I believe is the source of this problem. In SCCM 2007, I believe that SCCM essentially takes over the WSUS server that it’s linked to, and this is the cause for WUA searches returning no results. For example, if you look at HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate on a machine that you’re trying to patch with BatchPatch, you’ll see the WUServer and WUStatusServer registry entries, which will be populated with the update server that SCCM is configured to use. If you have a separate WSUS server that is not linked to SCCM, you can manually change these reg keys to point to the unlinked WSUS server, and then you’ll see that BatchPatch finds updates to download/install.
-Doug
dougModeratorThanks! We appreciate the kind words and your business.
-Doug
dougModeratorThanks for the suggestion, Andrew. We’ll look at doing this in a future build.
-Doug
dougModeratorThanks for the suggestion. We’ll look into adding this in a future build.
-Doug
dougModeratorThanks for sharing. That’s very helpful.
-Doug
-
AuthorPosts