[doug]

I’m not really sure what you’re suggesting. The reason that the ‘Download offline updates repository’ action does not obey the setting ‘Do not download newest wsusscn2.cab if any version is already cached’ is because it was not coded to obey that setting. In that sense it’s not really a “bug” per se but rather by design. However, it makes sense that it ought to obey that setting just like the normal Windows Update actions do, so we’ll look at changing it in a future build.

[doug]

Thanks. We have confirmed that the ‘Download offline updates repository’ action does not obey the checkbox ‘Do not download newest wsusscn2.cab if any version is already cached’. We’ll look at fixing this for a future build.

[doug]

I understand that you have ticked the box ‘Do not download newest wsusscn2.cab if any version is already cached’, but which action are you using in the app that is not obeying that checkbox?

[doug]

If you have the command line syntax to perform your desired operation on a single computer without using BatchPatch, then generally you can use BatchPatch to run that command on multiple target systems to accomplish your goal.

-Doug

[doug]

Yeah unfortunately I don’t think there is a better way to do what you’re trying to accomplish. Good luck.

[doug]

Hello – The entire purpose of the advanced multi-row queue sequence is to create a sequence where groups of computers are inter-dependent. It is designed intentionally to have one group only begin when the previous group is 100% done. From what you’re describing, it sounds like you don’t actually want to be using the advanced multi-row queue sequence at all. It sounds like you should be using scheduled tasks that kick off your groups at the specific times desired. So if you want the first 100 machines to start processing at 10PM, and then you want then next 100 to start processing at 10:10PM, followed by the next 100 at 10:20PM, then you should not use the advanced multi-row queue sequence. Instead create a scheduled task for each row to run that row at the desired time. Or… if you still really want to use the advanced multi-row queue sequence, you could create a separate sequence for each group of 100. Then have each sequence only contain a single position for that entire group of 100. In this way, each group of 100 is not dependent on any other group of 100. In this case you won’t actually be creating a “sequence” in the sense that nothing will be happening sequentially. But you’d be using the advanced multi-row queue sequence feature as just another way to schedule a group of 100 targets without applying the scheduled task to all 100 targets. Instead you would apply the scheduled task to the dummy row that starts the sequence, and it would then be responsible for launching the 100 members in the group. But each 100 members would be part of its own advanced multi-row queue sequence, and each 100 would get started independently of the others because each advanced multi-row queue sequence would have its own scheduled task to launch it at the desired time.

[doug]

Ok great. Glad that works. Thanks.

-Doug

[doug]

First I would note that the MAC gets logged in the ‘All Messages’ column, so you’ll have the entire history there. I would think that alone should be sufficient because even if the MAC column/field is overwritten with an error or blank, the previous query results are still contained in the ‘All Messages’ field.

However, as a way to accomplish exactly what you want to do, you could have your task check to see if the target computer is online first before trying to obtain the MAC. This way the MAC field will not be overwritten with an error when the machine is offline.

In the current version of BP there is no “Get MAC” option in the job queue, but we will consider adding it. In the meantime you can create a custom remote command (logged output) with the following syntax:

WMIC PATH Win32_NetworkAdapterConfiguration WHERE "IPEnabled=True" GET MacAddress

Then create a job queue that looks like this:

Step 1: Wait for host to be detected online
Step 2: Execute your custom command to get the MAC

Or this queue below actually probably works better for your needs since you want to just run the task periodically:

Step 1: If host is offline, goto label:X
Step 2: Execute your custom command to get the MAC
Step 3: Label:X

Then create a scheduled task that executes the job queue at the desired time.

—————

With all of that said, I really don’t understand at all what your actual need is here. I mean to say that I don’t understand why it would ever make sense to continually/repeatedly query a target computer for its MAC address, when MAC addresses do not ever change. Perhaps you could fill me in on more details. The better I understand your actual need, the more likely we would be able to address it sufficiently, if we were to add something to the software for this purpose. However, at the moment I simply don’t understand why you’re repeatedly querying targets for their MACs. On the surface this just doesn’t make sense to me. Thanks.

[doug]

1602 is returned by the MSI installer. It’s not a BatchPatch error per se. BatchPach just passes through the MSI return code to you.

MSI 1602 exit code means “User cancelled installation.” My best guess is that you have something, perhaps anti-virus software or similar, that is killing the installation. You might be able to get more info by adding the following to your parameters in the deployment.

/log c:\msi_installer_log.txt

See screenshot for illustration/example:

Alternatively you might be able to get more info by running the msiexec command at the cmd prompt manually on a target machine instead of through BatchPatch. So for example if you put the MSI file directly on the target computer and then you ran this command:

msiexec.exe /i "C:\someFolder\someInstaller.msi" /q

You should see it output more detail to the cmd prompt that might help you figure out what is happening.

[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.

[Author]

Posts