[doug]

🙂

You’re very welcome.

[doug]

Create a ‘remote command (logged output)’ with the following syntax:

time /T

[doug]

The update reboot cycle was deprecated a few years ago. We finally removed it from the software in this most recent release. Please use the job queue instead. It’s much more powerful and flexible. You can create a custom job queue called “update reboot cycle” if you want. Then just use that in your task.

-Doug

[doug]

You’re very welcome! 🙂

[doug]

Sorry to hear that. If you are a licensed customer and want to work through this with us, I would encourage you to contact us directly so that we can have a better look at what might be happening. There’s a good chance that we’ll be able to help you get it working when we can see exactly what you’re doing with screenshots etc. It’s unclear to me at the moment where things might be going wrong. BatchPatch contact form

Thanks,
Doug

[doug]

When you say the first command was successful– I assume that means you did the first command successfully using ‘Deploy’, not using ‘Remote command’, yes? If yes, I’m thinking that the issue with the second command is probably the quotation marks. Try single quotation marks around the path instead of double quotation marks. Like this:

\\server\vs2019\vs_enteprise.exe update --installPath 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional' --quiet --wait

Let me know how it goes.

[doug]

For what you are trying to accomplish… where you want the actual logged-on user to perform a task, I think the primary ways to do this are as follows:

1. If you want to use BatchPatch, then in BatchPatch you can get the list of users who are logged-on to the target computer by using ‘Actions > Get info > Get logged on users’. You could then manually take this information and input it into the ‘Notes’ column in BatchPatch in the format that you need/want it to be. And then you could send $notes as a parameter in your deployment configuration so that $notes gets passed into your script that runs on the target computer. In your script you could then handle the parameter in whatever way you want.

2. Instead of using BatchPatch for this task you could setup your script to run as an active directory logon script for the end-user so that when he/she logs on to the computer, the script runs in the context of his/her logon account.

3. Another option if you want to use BatchPatch is you could incorporate into your script the ability for the script to get the logged-on users directly with your own code, so that you could then use that information in your script to accomplish your end-goal. In this case you would either need to know for sure that there is only a single user who will ever be logged-on to the computer, or you would have to have logic that makes a determination for what to do when multiple logged-on users are detected. Furthermore, you would have to decide how you would obtain the list of logged-on users in the first place. There is not one set way to accomplish this task. Different methods have different advantages and disadvantages.

———————-

The idea that BatchPatch should have a %username% variable is not so straightforward as you imply. For one thing, there can be multiple users logged-on to a computer, so who is %username% in that case? Additionally, something like the $computer variable that BatchPatch currently supports along with $notes, $notes2, $description, $category, and $location… these are variables for use inside of BatchPatch … where these values exist or are inputted by you into the corresponding BatchPatch columns… such that you can then send them as parameters into your scripts/commands that you execute from/in BatchPatch. However, it’s very different for BatchPatch to see that you have used $username inside of a script that will be run remotely (or even just as a parameter sending into the command/script), and then have BatchPatch on-the-fly make a remote connection to the target computer, figure out the logged-on user, then insert that into your command (or modify your script and replace the value for you), and then execute your command/script remotely in a separate action. While this is theoretically possible to do, it’s a very customized kind of action, and it’s applicability would need to be tweaked on a per-use basis, depending on the specific need of the administrator for any particular given task. We try to make BatchPatch as flexible as possible for administrators to then be able to customize for their own needs, so that when they have particular tasks that they need to perform as part of their job, they can get something up and running with minimal effort. However, there are some tasks, such as what you are trying to accomplish, that don’t lend themselves well to having us pre-build in complete end-to-end functionality to accomplish due to the fact that they are quite specific… your exact need will not be identical to someone else’s exact need.

[doug]

OK that’s very helpful! So now it looks like we have the reason why it isn’t working, which is that there is no preparation step occurring. What I don’t know is why or how that could be getting skipped. I’ve just emailed you to request a HTML grid export for further, closer review. Let’s switch to email for now. Then I’ll come back and update this thread after we (hopefully) get to the bottom of what’s going on.

-Doug

[doug]

Weird, thanks. In your ‘All Messages’ column after the download/install, but before the reboot, you should have a line that says: “Windows Update: Feature update preparation complete.” Can you confirm that you do see this? Or did it fail? If it failed it would say “Windows Update: Feature update preparation failed: someExitCodeHere”.

Assuming that the preparation process completed without failing, my hunch is that the issue is still being caused by a GPO, though I’m not sure which one. We can’t reproduce it at the moment, and we have no other reports of it as of yet. I’ll let you know if we come up with any other ideas. Please also report back if you test anything else, such as removing *all* Windows Update GPOs before trying again.

And do keep in mind that at least as a workaround, if needed/desired, that you can always deploy the update using the BP deployment feature instead of the BP Windows Update feature, per the link noted a few postings above ( Deploying Windows Feature Upgrades Remotely to Multiple Computers )

[doug]

Just to confirm… after you modified the GPO and applied it, you ran the download/install/reboot from BP again? And then after the target machine rebooted, it didn’t automatically start the installation? Or did you not try the reboot? I ask because the reboot is necessary before it will proceed with the actual installation, so I just want to confirm that I understood what you did. Thanks.

[doug]

Authentication to a remote location can be different when going over two hops instead of one. So instead of making a single remote connection, you are effectively making a remote connection to the target computer and then asking it to make a remote connection to the network share, so it’s not an identical procedure. I would suggest you try a couple of things:

1. Try entering ‘Alternate credentials’ in BatchPatch (Actions > Specify alternate logon credentials). See if that makes a difference as compared to when you just use ‘integrated security’.

2. Maybe you can use the BatchPatch action “Copy file/folder” to accomplish your goal?

3. Maybe you can use a BatchPatch local command to accomplish your goal? In this case instead of running the script remotely, you could have a script that runs on the BatchPatch computer (Actions > Execute local process/command), and then there won’t be two hops of authentication, in case the two hops is what is causing the problem.

Also one more thing to note that I’m not sure if you are considering or not… the credentials that you are using to connect BatchPatch to the remote machine (whether that is with integrated security or with ‘alternate credentials’) is not necessarily the account name that you want to be inserted into %username% is it? Because the %username% variable will be the account that is running the script, which I suspect is not the account that you are wanting it to be, though I’m unsure because I don’t know the exact details of what you are trying to accomplish. I just figured I’d mention it here in case that helps at all.

Also, in cases where you use SYSTEM, I don’t think it will ever work properly because SYSTEM only has local privileges, so you would need to use ‘Elevated token’ I think to have a chance at it working properly.

-Doug

[doug]

Thanks. I suspect your issue is arising due to your group policy settings. Most likely it would be from the use of either the “No auto-restart with logged on users” policy OR possibly the use of option 4 setting in the “Configure automatic updates” policy OR possibly the combination of the two. I would suggest removing the “No auto-restart with logged on users” setting and also changing the “Configure automatic updates” setting from 4 to 3. After the machine has received the new/updated policy settings, try once again to run the feature update process from BP (you’ll probably need to run it again from scratch as if you had never run it previously). I think there is a good chance that the feature update will now apply without prompting you to schedule it. Let me know how it goes.

[doug]

If you’re interested in solving this I would ask you to please review my posting above about group policy objects, and please then let me know the answer to that question, as it might be what we need to figure out what is going on. Thanks.

[doug]

I just realized I never asked you which version of BatchPatch you’re using. Are you using a version of BP that was released prior to 20200425 ? If yes, that’s your problem. The ability to install Win 10 feature updates through the normal Windows Update actions in BatchPatch only arrived in 20200425.

If you’re already using 20200425 or newer, then I’m sorry to say at the moment I’m just not sure what is causing your issue. If you’re already using 20200425 or newer, then for now your best workaround is to instead just deploy the feature update with the method outlined here:

Deploying Windows Feature Upgrades Remotely to Multiple Computers

[doug]

@bweddell – .msu files can be installed remotely by BatchPatch. We do it all the time, and we have numerous tutorials posted on our website that demonstrate how to create a deployment for .msu files. It’s unclear to me what could be causing you to get an exit code 5 for your .msu deployment. I would suggest trying to install the .msu manually at the command prompt of the desired computer. Then see if it spits out a more useful error text that explains why it won’t install. Most likely if you can’t install it with BP, then it will also fail to install when you try to deploy it manually at the command prompt without using BatchPatch. It could be something like the .msu file that you are trying to deploy to the target is not compatible with the OS version or architecture.

[doug]

Can you check your group policy settings?

Which policies are enabled under these locations?

Computer Configuration > Administrative Templates > Windows Components > Windows Update

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business

I’m especially wondering if you have configured “Select when Preview Builds and Feature Updates are received” and if you have the item inside that policy, “Pause Preview Builds or Feature Updates starting:“, configured with a date? However, I’d still also be interested to know which other policies are configured too in addition to this particular one. Thanks.

[doug]

Thanks for the additional info and screenshot. At the moment I don’t know if something has changed in 1909 as compared to the previous Win 10 versions, or if there is something specific to your environment that is causing this. We’ll do some testing here with 1909 to see what we come up with.

What is the version of Win 10 that is on the machines now? I know you are upgrading to 1909, but which version is running before 1909 is applied?

Also, which Windows Update group policies do you currently have applied to these targets?

-Doug

[doug]

Laurie – I’m actually not quite sure what you’re describing. When you use BatchPatch to download/install the feature update by selecting the ‘include upgrades’ option, it initiates the download/install process. The process does require a reboot before Windows will actually perform and complete the installation, so I’m not sure if you simply didn’t ever initiate the reboot or if you’re describing something different. Under normal circumstances when installing the feature updates with BP you would make sure that the update is showing in the “Check for available updates” and then you would select the “include upgrades” option to get BatchPatch to initiate the download/install when you select the BP action to ‘Download and install updates plus reboot if required’. Then upon reboot, the computer would complete the installation. And of course you can review the ‘Remote Agent Log’ column to ensure that BatchPatch executed the download/install of the feature update (or you can use ‘Actions > Windows Update > View BatchPatch.log’). If you don’t see the feature update in the list of updates that BP downloaded/installed, that would explain why you are not seeing it be installed by BP. I’m confused and unsure about what you are doing/experiencing.

The other way that you can use BatchPatch to deploy feature updates is described here: Deploying Windows Feature Upgrades Remotely to Multiple Computers

[doug]

This is peculiar. I don’t know anything about Baramundi, but if it’s installing a Windows KB, Windows would/should log it to Win32_QuickFixEngineering. Perhaps the behavior is different in Windows 8.1, but I would expect that to be due to Microsoft, not due to Baramundi. Also, it still almost seems like the update is not even installed because BP really should be able to uninstall it with one of the uninstall commands. Between the fact that you don’t see it in Wind32_QuickFixEngineering and that you can’t uninstall it with the default uninstall command in BP, I have to question if it’s truly even installed. I don’t know what to make of it. If you get to the bottom of it, please report back here what you learned and how you resolved it.

Thanks.

[doug]

How are you determining that the KB is, in fact, installed on the client?

BatchPatch has two methods for checking the update history on targets:

Generate consolidated report of update history (Windows Update Agent)
Generate consolidated report of update history (Win32_QuickFixEngineering)

Neither of the above actions show the KB that you say is installed on the targets?

And neither of the ‘Uninstall individual update’ commands in BatchPatch works successfully?

I’m sorry to say I don’t know what to suggest to you. It’s not clear to me what could be happening here. It seems like maybe the update is not actually installed despite the GUI appearing to indicate that it is installed. But if it is installed and BatchPatch is not able to uninstall it with the default uninstall commands, then I would suggest you either manually uninstall the update on each desired target computer, or write your own command to perform the uninstallation. Once you have a a command that works at the cmd prompt of a computer to remove the desired KB, you could port that command into a BatchPatch ‘remote command’ to then execute across the remaining targets.

-Doug

[doug]

Recurrence is not available for the multiple tasks schedule. It is only available for singular scheduled tasks. You have two options for accomplishing your goal:

1. Manually schedule in the multiple tasks schedule all of the desired run dates/times.

2. Add a new/separate row for each task that you want to be recurring. Create a singular scheduled task with recurrence for each row.

If you have a grid synchronization task that is being used to remove other rows, you can prevent desired rows from being removed by either using ‘Synchronize grid with directory (add hosts only)’ so that your synch task never removes any hosts, or if you want to remove hosts but just don’t want to remove particular hosts then use the ‘Exclude hosts from synchronizations’ option that is available in the lower right corner of the Grid Synchronization Settings window.

[doug]

Thanks, Rich. Please do reply to this thread if/when you have more info. I’m very curious to know if purchasing ESU does the trick.

-Doug

[doug]

Hi DJ –

1. We do usually post some notes on the website in a blog posting with each new version, depending on the nature of the particular release. We plan to post something this week for the version released on Friday. It just hasn’t been published yet. Usually the blog posting will follow the actual release of the new build by several days up to about a week.

2. We don’t publish file hashes. We *do* sign the BatchPatch.exe, which is superior to just publishing file hashes. Scott just wrote a posting, which is now also linked off of the download page, that explains why digitally signing a file is superior to publishing a file hash. You can see it here if you’re curious:

Verifying the Authenticity and Integrity of BatchPatch.exe

[doug]

I wouldn’t be surprised if certificates is one of the methods that Microsoft uses to prevent people who didn’t pay for ESU. I found a wsusscn2.cab from July 2019, and I was able to use it successfully to search for updates on a Windows 7 target. However, when I use the current wsusscn2.cab from Sept 2020, I get the same certificate error that you got.

0x800B0109 -2146762487 CERT_E_UNTRUSTEDROOT

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

I think there is a pretty good chance that if/when you pay for ESU, the first thing they do is give you an update that updates your certificate store so that you’re able to continue updating the OS. This is just an educated guess. I can’t say for sure.

[doug]

I don’t know if any of the client triggers will do what you want or not. We don’t use SCCM. We implemented all of the available SCCM client triggers as a convenience to SCCM users, but the details of what the client triggers actually do etc has nothing to do with BatchPatch, so it’s not something that we can provide support for.

[doug]

Triggering ConfigMgr (SCCM) Client Actions Remotely

[doug]

If they are fine when connected to the LAN and are only not working when using DirectAccess, then it seems pretty clear that the issue is with your DirectAccess configuration. I don’t have experience with DirectAccess, so I’m not able to provide much guidance, but based on some very quick and minimal research it appears you have to configure “Manage Out” capability for DirectAccess in order to be able to remotely manage clients from within the LAN. I wouldn’t be surprised if you also have to configure firewall rules specifically for when using DirectAccess.

Troubleshooting Common Errors in BatchPatch

[doug]

Please see this link:

Review the section under ‘Error -102: Failed to execute the search. HRESULT: -2147012867‘

[doug]

We’ll see what we can do.

[doug]

In that case then you should just keep the deployment files on the BP computer or in the same network as the BP computer so that when BP copies the files to target computers it only copies the files in one direction. There is not currently a better or more efficient option available.

[Author]

Posts