Forum Replies Created
-
Posts
-
That’s correct. You either need to use the Oct 2024 WsusScn2.cab file or you can manually download the desired update directly from the Microsoft Catalog as a .MSU file, and then use the Deploy feature in BatchPatch to push it to your target computers.
Currently, with a standard scroll wheel mouse you can use the mouse scroll wheel to do a horizontal scroll in the grid by holding down CTRL and then using the standard scroll wheel. Holding down CTRL changes the scroll from vertical to horizontal.
As for your hardware horizontal scroll wheel tilt not working… we will look into fixing this for the next version. Thanks for pointing it out.
Our recommended GPO settings for NO WSUS are here:
recommended-group-policy-settings-for-batchpatch-standalone-usage-with-no-wsus
Configure Automatic Updates should be set to either 2 or 3, depending on your preference.
The other settings are all up to you to decide which are best for your particular needs. We generally do not enable any of the other settings that you have mentioned, but whether or not you choose to enable other policies is of course up to you and your requirements and/or preferences.
The main thing that you seem to be asking about is the Windows Update UI in the OS. Unfortunately usoclient startscan is not supported by Microsoft to guarantee any particular operation, and it does not work consistently/reliably to refresh the UI. From what we have observed, the GPO status does not really matter. usoclient startscan will sometimes perform the refresh but other times will not, regardless of the GPO setting. I think in your case what you observed was that with certain GPO settings the UI is more regularly updated by the OS because those GPO settings were triggering the OS built-in Automatic Updates client to be more active, but of course you also experienced the downside of allowing Automatic Updates to be active, and your machines got updated and rebooted without you initiating it. Unfortunately at this time Microsoft has not provided a way to update the UI reliably/consistently when it’s not up to date, and we do not have another workaround right now. That said, realistically you just need to train your administrators to know that they cannot rely on the status of the OS Windows Update UI when using a third-party update tool like BatchPatch. BatchPatch will still always report the correct status.
I would note that you might be able to use usoclient.exe startinteractivescan to immediately refresh the UI, but the problem with this command is it will also trigger the download and install of any/all updates that are still available (any updates that have not yet actually been downloaded or installed), which is not what you want.
I don’t actually understand what you are describing. Your posting is a bit unclear, so I can’t offer advice for how to resolve your issue unless you can more clearly explain what’s going on, being as specific and detailed as possible about exactly what you are executing and what’s occurring. Or contact us directly to work with us via email and trade screenshots etc to help illustrate.
That said, I can answer your last question, which is that in BatchPatch if you use $computer inside a command, BatchPatch will replace it at the time of execution with the actual host name from that row that performs the execution.
Excellent. I’m glad you got it working. Thanks for the update.
Please see this link. Read carefully through it and check each of the things that it mentions to see if one of those is causing your issue: batchpatch-windows-update-error-1601
If Windows Firewall is truly disabled, the issue could be another firewall (whether that be software or hardware/network). “The RPC server is unavailable” means that the BP computer is not receiving a response from the target computer. Firewalls are the common reason why this occurs, but it could possibly be anti-virus or similar HIPS or other security software, as these software suites sometimes do some degree of firewalling too. Also consider if any network or other hardware firewall could be the culprit.
Considering that you are able to use “Opt-in” successfully but NOT a Windows Update action, this indicates that the blocking is specific to WMI queries. That is, the “Opt-in” action copies a script to the target computer and then uses PsExec to execute it. It does not use WMI at all. However, the Windows Update actions use some WMI queries too, and the WMI query is what’s getting blocked/dropped. WMI queries use dynamic ports, by default, and so it does sometimes happen where the firewall is just not configured properly to allow/enable WMI queries to work. A little bit more on that here: batchpatch-ports
FYI in case there was any confusion I just want to note that a “local command” in BatchPatch will execute on the BatchPatch computer. A “remote command” in BatchPatch will execute on the target computer.
Use $computer as the parameter in the command. When BatchPatch sees $computer in the command, it will replace it with the computer name from the Host column when it executes the command.
A couple of examples of this are shown in the following tutorials:
advanced-script-integration-with-batchpatch
incorporating-custom-scripts-in-batchpatch-get-local-administrators-group-membership
I don’t know enough about your particular setup or AAD to be absolutely 100% certain of what I’m about to say, but I’m pretty confident that you should be able to use BatchPatch as-is with the setup that you described.
In a standard on-premises AD domain, the primary way that BP users authenticate is by logging on to the BatchPatch computer with an account that is a member of the local administrators group on the target computers (or a member of a security group where the security group is a member of the local administrators group on the target computers). This way when the administrator launches BatchPatch, it runs with the permissions that it needs to be able to perform its tasks on target computers without having to manually specify any credentials in the software itself (because the software is already running in the context of the user that has been granted the required permissions on the target computers by having been put into the local administrators group on the target computers). Or if they don’t log on to the BatchPatch computer with the permissioned account, they might log on to the computer with a different account but then use “run-as” to launch BatchPatch in the context of the permissioned account.
I think with an AAD setup you’ll do the exact same thing. You’ll put the AAD account in the local administrators group of all target computers (or you’ll put the AAD account into a security group where the security group has been added to the local administrators group of all target computers). Then you’ll log on to the BatchPatch computer as that AAD account and then launch BatchPatch (or you’ll log on to the BatchPatch computer with a different account but then launch BatchPatch using “run-as” so that it runs in the context of the AAD account that has been granted local administrator permissions on the target computers).
The log info that you included in your posting does not show the entire picture, as the log details are spread across multiple columns. If you’d like help sorting through this, please contact us directly for further assistance. We’ll ask you to send us an HTML grid export so that we can review everything instead of just the tidbits that you’re pasting.
This tutorial demonstrates how you can use BatchPatch to execute a script to modify local group membership on multiple computers:
Using BatchPatch to Modify Local Group Membership on Multiple Remote Computers
You can also use the same concept that is described in the tutorial above to create a local user account first. In the tutorial above we use the following command to add an account to the local administrators group:
net localgroup Administrators USERNAME /addBut you can use this command to first create a local account:
net user USERNAME PASSWORD /addHow are you populating your cache folder in the first place?
Are you using online cached mode or offline cached mode?
Are you using “Download offline updates repository” to populate your cache?
Or are you just executing “Download and install updates” on target computers, and then the BatchPatch computer has access to the internet to download the updates to the cache?
Which scenario at this link describes the method/approach that you are using?
cached-mode-and-offline-updates=============
Since you have already resolved the issue by placing the files into the cache, I’m not sure that there is any value to removing them. It sounds like we might be trying to solve a problem that doesn’t exist. If your goal is to see why they weren’t downloaded in the first place, then start by going through my questions above. At the moment I don’t know enough about what you’re doing to really comment much, as there are multiple ways you could be using BatchPatch, and multiple ways for the cache to get populated etc. I’m not sure the exact method/operation that you’re using. If BatchPatch couldn’t download a file from Microsoft but then you downloaded it yourself, it sounds like the problem is solved.
This ‘Remote Agent Log’ detail that you pasted doesn’t show the download attempt because in ‘cached mode’ the download details appear in the ‘Local Agent Log’ not the ‘Remote Agent Log’ column. If you execute a new “download updates” operation, you’ll be able to see the download attempts and any failure messages. This log that you have here is showing the caching operation failing because the file didn’t exist in the cache. It’s not showing the actual download operation.
When you perform a Windows Update action, the row in the grid will have ‘All Messages’ column, ‘Remote Agent Log’ column, ‘Local Agent Log’ column, which together can be used to see what occurred during an offline update action for a given row. You can/shold always reviews those columns after an action, if you believe something didn’t go as expected, since they will show what occurred. The contents of just the ‘Remote Agent Log’ column are also saved to the remote working directory of the target computer (default is C:\Program Files\BatchPatch\BatchPatch.log). The ‘Local Agent Log’ column is not saved outside of the BatchPatch grid.
The log columns will show exactly what occurred and if a download was skipped or failed etc. If you need help reviewing logs, feel free to contact us.
I suspect that if you try to log on directly to the target computer as the account that you’re using that creating this permission issue, you’ll likely see that same message at logon. As mentioned, this isn’t a BatchPatch issue per se. It’s a Windows permissions issue, so it will need to be troubleshot from that standpoint, not from anything that’s specific to BatchPatch. But ok just keep us posted here. Thanks.
Sorry to hear that you’re having issues. It’s tough for me to say what exactly might be causing the issue. It pretty much has to be a permissions issue of some kind, but it’s weird that upgrading to Win 11 would cause it. My best guess about why the upgrade triggered the problem is because of your Group Policy settings. I’m guessing that you have different policies applied to Win 11 (or not applied), and so after the upgrade the differing policies ended up producing this unexpected result. I would suggest Googling this Windows error:
Logon failure: the user has not been granted the requested logon type at this computerYou’ll see lots of results with various potential causes and resolutions. I’d start working through those one by one to isolate what exactly is happening in your environment since the issue isn’t exactly a BatchPatch issue per se but rather is something to do with your permissions in Windows. It would be great if you could report back here when you isolate the exact cause.
There is no such mode. However, rather than adding allowances in the firewalls on target machines to the public, instead I would recommend that you expose the required services only to the BatchPatch computer on your LAN. This is explained here:
This is the general firewall config required for BatchPatch:
using-batchpatch-with-windows-firewallThis is how to configure the Windows Firewall to expose services to only a specific IP address (this specific IP should be the LAN IP of the BatchPatch computer):
modifying-the-scope-of-windows-firewall-rules-to-allow-connections-only-from-selected-ip-addressesWhen offline mode is enabled, the BP computer will attempt to perform the download itself. If it has access to the internet, it will download the updates to its local cache and then push them to the targets for installation. The targets will not make connections to Windows Update or Microsoft Update as part of this process.
You can read more about how offline mode operates at this link: https://batchpatch.com/cached-mode-and-offline-updates
Your posting was sitting in the spam bin, so I didn’t see this until now. Sorry for the delay. Generally the reason that this happens is due to the OS being out of support with Microsoft. I’m guessing the OS version that your targets are using is no longer supported. Time to upgrade them.
Another thing to consider that we have seen occasionally is where you need to apply the latest servicing stack update. There were some older versions of Win 10 where we saw Microsoft got things out of order somehow where a machine would not be able to use Windows Update to find any available updates until after manually applying the latest service stack update (SSU update). It seems like in these cases they got into a situation where Windows Update couldn’t be used without the latest SSU, but the latest SSU could therefore also not be obtained through Windows Update. So it required a manual intervention to install the latest SSU.
One thing you can try that might work is to try an offline scan in BatchPatch instead of online. To do that, enable offline mode under ‘Tools > Settings’ and then try. This might get you onto a SSU that is late enough to resolve the issue.
Another thing that you can do is manually download the desired monthly cumulative update and/or latest SSU directly from the Microsoft Update Catalog. Then use the ‘Deploy’ feature in BatchPatch to deploy it to your target computers all at once with just a few clicks.
Under ‘Tools > Settings > Grid Preferences’ look at the “Hosts are considered offline after X ping timeouts.” The default value is 3. However, if you’re having a problem where your VMs are rebooting within just several seconds (the timespan of 3 ping timeouts), then try changing it to 2. That will usually resolve it. I don’t recommend changing it to 1 because if any machine has just a single ping timeout then BP will think that machine went offline, so you’ll get consistent false alerts if the value is set to 1. However, 2 is usually a good middle ground option that should work well in most situations.
==========================
The other option is don’t even use ‘Wait for host to go offline and come back online’. Instead do something like this:
-Step where reboot occurs
-Wait 10 minutes
-Wait for host to be detected onlineThis will generally give you a good middle ground option. In many situations a 5 min wait will work fine instead of 10, but 10 minutes should ensure that you don’t run into any issues where a machine is taking a very long time to complete the initial shutdown sequence. If you set the wait time too low, then BP will get to ‘Wait for host to be detected online’ and will find that the machine is online but not because it rebooted already but rather because it hadn’t yet actually shutdown and was still online and working to complete the initial shutdown sequence.
In order to evaluate your queue and provide guidance/assistance, I would need to see a copy of the exact/actual queue that you setup.
The conditional operations in the job queue for ‘If this step is executed between DayOfWeekBEGIN and DayOfWeekEND’ require that job queue step to be executed inside of that time/day window in order for anything to occur. Typically these special queue items would be used inside of a loop in your job queue so that each time the job queue loops/runs, it tests to see if that step is running between DayOfWeekBEGIN and DayOfWeekEND, and then it can act accordingly.
For what you’re describing you should probably just use the task scheduler to schedule your desired job to run at your desired time.
Windows uses the following locations to determine which apps are started automatically on a given computer:
Folders:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\StartupRegistry:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunBatchPatch does not contain functionality for directly manipulating these folders and registry values, but you could optionally write a custom script to do that, which you could then deploy to each target computer by using the ‘deploy’ feature in BatchPatch.
You have two options:
1. Switch the update classification to ‘Include “Upgrades”‘, then perform the desired upgrades, then switch it back after completion so that when your scheduled tasks execute they’ll be using the desired/correct settings.
2. Perform the upgrade with the ‘Alternate Deployment’ method described at this link starting about halfway down the page: Remotely Deploying Windows Feature Update Version 23H2 to Numerous Computers
We’ll consider other options for a future version.
Regarding Explorer… Yes, we are experiencing the same prompt for user credentials. This is expected behavior. We will consider a custom file explorer/browser, but to your point, there already exist custom file explorer apps on the market, and you already have such an app.
Regarding ++… As described in my previous posting, BP does *not* have an issue with + symbols. The issue that you are encountering is from the *space* character in your filepath, not from the + symbol. As mentioned in the previous posting, we will have that issue/bug fixed for the next release. However, for the time being until the next version is released, a workaround would be to install your explorer++.exe into a filepath that does not have any space characters. e.g. Instead of C:\Program Files\Explorer++\explorer++.exe, install it to something like C:\ProgramFiles\Explorer++\explorer++.exe
First, I would note that we do not encounter the same issue here. I can log on to the computer as userA, and then I can run BatchPatch with run-as under userB logon account, and inside of BatchPatch I can call the following local command successfully without any issues to launch Explorer
explorer \\$computer\c$For me it returns exit code 1 but still launches Explorer to the proper location. I believe the reason you cannot do this even though I can do this is likely because the user that you have running BatchPatch does not have local administrator permissions on the BatchPatch computer.
================
With regard to the ++ issue… BatchPatch does not have an issue with ++. The bug you are encountering is BP failing to parse the space properly in ‘Program Files’. Thank you for highlighting this issue. We will have it fixed in the next release.
================
For the time being until the next version of BP is released, it seems like your easiest workaround is to just launch a separate instance of BP in the correct user account to be able to launch Explorer without issues without needing to run-as a different user. Alternatively, put your Explorer++ in a location that does not contain a space in the filepath.
In that case probably the best option for you would be to launch a second instance of BP in the other user account, which you can use for the sole purpose of launching the Explorer C$ windows.
Or another option might be to NOT run a second instance but instead just modify the command so that it launches as the correct user. Something like this:
runas /noprofile /user:mymachine\administrator explorer \\$computer\c$or
runas /user:mymachine\administrator explorer \\$computer\c$Try this:
1. Go to Actions > Execute local process/command > Create/modify local commands
2. Create a new command with the following syntax:
explorer \\$computer\c$3. Save that command. It will appear under Actions > Execute local process/command > Execute saved local commands
4. Execute the command for a row. When you execute the above command for a given row in the grid, BatchPatch will automatically substitute $computer for the actual/real computer name from the Host column.
I’d want to view an HTML grid export (File > Export grid to HTML) in order to see what might be happening, along with a screenshot of your job queue settings. Feel free to contact support directly since we can’t look at these things on the forum here.
You should definitely NOT use offline mode unless the machines actually do not have access to the internet or to a WSUS. If you switch to online mode, you’ll be able to get all of the available updates, but whether or not this is an identical reflection of your WSUS or not will depend on the search settings and the WSUS settings. Generally speaking, I think it will give you what you’re looking for. However, in all cases it doesn’t make a ton of sense to compare your results to your local WSUS if you’re not going to actually use the WSUS to distribute the updates.
Just FYI with regard to WSUS… 30 servers in a 3-hour window is nothing. WSUS can generally handle thousands in a much smaller window. While I don’t know the details of your WSUS setup or what type of issues you are encountering with it, what I *can* tell you is that a properly functioning WSUS server will not have any issues with 30 machines. I can also give you another tip, which is that you can have group policy handle downloading the updates to the computers from the WSUS in advance of the maintenance window so that when maintenance time comes the machines are not having to download updates from the WSUS since they will have already done that. We have some instructions on WSUS GPO setup for pre-downloading updates here: batchpatch-integration-with-wsus-and-group-policy
–Offline mode contains only a subset of updates– primarily security updates. Microsoft controls which updates are distributed through each channel. Not every update that is available from Microsoft or through your WSUS server will appear in offline mode scans.
–If you have a local WSUS server, why would you be using offline mode? You should just use your local WSUS server, which gives you full control over which updates are presented to target computers.
–This link explains all of the possible reasons why you might not be seeing updates that you expect to see when scanning for available updates in BatchPatch:
batchpatch-and-the-windows-update-control-panel-report-a-different-number-of-available-updates