[doug]

Thanks 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

[doug]

The 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

[doug]

Ajo – 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

[doug]

A 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

[doug]

I will get back to you on this soon…

[doug]

Unfortunately 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

[doug]

Thanks! We appreciate the kind words and your business.

-Doug

[doug]

Thanks for the suggestion, Andrew. We’ll look at doing this in a future build.

-Doug

[doug]

Thanks for the suggestion. We’ll look into adding this in a future build.

-Doug

[doug]

Thanks for sharing. That’s very helpful.

-Doug

[doug]

Hey jagablack – I’m really glad to hear you like the tool!

BatchPatch port requirements are as follows:

Remote connections are established in a couple different ways, depending on the action selected in the software. Most of the Windows Update and Remote Patch/Software/Script Deployment actions use PsExec in one way or another plus remote fileshare access. These will generally require ports 135 and 445. The reboot, shutdown, and most “Get Information” actions use WMI, which has different and more complicated port requirements explained below. However, you’ll also notice that there are alternate reboot and shutdown methods in BatchPatch, which use a shutdown.exe instead of WMI. In these cases shutdown.exe is initiated with PsExec and so has the same port requirements of 135 and 445 mentioned above.

With regard to WMI, it uses dynamic ports, which makes it more difficult to setup proper ACLs in an enterprise firewall. There are lots of articles about WMI ports on the web and Microsoft’s site, so feel free to take a look around at some of those for more info. It is theoretically possible to set static WMI ports, but in practice I’m not sure this is ever really feasible, and we also haven’t tested it at the time of this writing. See here for more info: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219447%28v=vs.85%29.aspx

Hope this helps.

-Doug

[doug]

twoj – thanks for the comments.

You can see what hotfix is currently being installed by middle-clicking on the progress bar field. We’ve been considering better/other ways to display this information, but for now this is the cleanest way that we’ve been satisfied with.

We’ve been considering categories or tabbing functionality for a while in order to be able to group machines in a single batchpatch.exe process, but we’re not yet sure if this is something we’ll implement. In the meantime, we strongly recommend categorizing by using different batchpatch.exe processes. Launch one instance of BatchPatch for each category you want. This has the advantage of providing insulation between the processes, so that you don’t have all your eggs in one basket, so to speak.

-Doug

[doug]

Thanks, Don for posting the solution: http://batchpatch.com/forum/topic/error-1-here-also

---

“I saw the other posts but no resolution. psexec EULA accepted. No log file created. I do see the remote agent getting copied however. Running it as a DA.

I’d REALLY like for this to work and would purchase ASAP if this issue could be explained/resolved.

Thanks!

Solved – saw another post regarding the log not being found, it indicated that the version of psexec might be too old – downloaded the newest version and it seems to be working now.”

[doug]

First, make sure you have the latest version of BatchPatch. Then take a look at the following links posted below. Before you can deploy software or run any exe remotely you need to determine what command line switches are required to perform a silent installation. If you don’t, then the exe will get copied to the remote machines, but when it’s executed it will hang indefinitely while waiting for user input to click through the installer prompts, but the installer won’t be visible anywhere.

How to Push .NET to Remote Hosts

Remotely Installing Software Patches, Hotfixes, or Updates with BatchPatch

[doug]

You don’t have to configure BatchPatch in any special way. All you’ll want to do is setup a group policy to control how your computers receive updates. See http://technet.microsoft.com/en-us/library/cc708536(v=ws.10).aspx We recommend choosing the option to have your computers download but NOT install updates automatically. Then use BatchPatch to initiate the installation and reboot process.

-Doug

[doug]

Most of our customers use a WSUS server to filter which updates get applied to computers. However, in the absence of a WSUS server, you may use the filtering options that BatchPatch provides in “Tools > Settings > Remote Agent Settings” to control which updates get applied to the machine. These options allow you to filter by “Update Classification.” If you first run “Actions > Windows Updates > Check For Available Updates” you’ll be able to see which update classification the packs fall under, and then you can exclude that particular classification. Unfortunately Microsoft does not publish a classification called “Language Packs.” Instead the Language Packs are classified in one of the other groups. Currently BatchPatch does not allow you to exclude specific update packages by name, although we are considering this for a future build.

I hope this helps. Let me know how it goes. Note, you can setup a WSUS server for free in under 30 minutes on a low-powered machine or virtual machine, so that’s going to be the best bet for the most granularity when it comes to filtering. You only approve the updates that you want to be applied to your machines, and then you can use BatchPatch to initiate the installation.

Thanks,

Doug

[doug]

We’ll consider this for a future build.

Thanks,

Doug

[doug]

Andrew – I just published a new build that has a “Recursive Search” option in the Active Directory picker. This will give you what you’re looking for.

-Doug

[doug]

Andrew – I understand your dilemma. For right this minute, you’ll need to do as you described. However, we should be able to combine the functionality of the old picker with the new one to get the best of both worlds. I’ll try to get a new build posted with this update within the next couple of days. Sorry for the inconvenience.

-Doug

[doug]

What type of machine are you running BatchPatch on? Are you able to successfully run a Windows Update action in BatchPatch against any machines? Is it just one problematic target hosts or all they all having the same issue? Are the machines all part of the same domain? Are you using any anti-virus software?

When you run “Windows Updates > Check for available updates” against a target host, BatchPatch first attempts to copy some files to the remote working directory (Default is C:Program FilesBatchPatch), then BatchPatch executes the remote agent process, and monitors for completion before it finally deletes the files in the remote working directory. So, what I’d like for you to do is launch “Check for available updates” against a target host WHILE watching the target host’s remote working directory. Do you see files get copied there? Also on the target host, watch the active processes. Do you see the psexecsvc.exe ? Do you see the BatchPatchRemoteAgent.exe ? When the process completes, are any files left in the remote working directory? If yes, which ones? Could you post the contents of any of the files that are left?

As a first step, what happens if you then manually install the Windows Updates on the target host. Does that work? If yes, after you reboot it, can you then try BatchPatch > Check For Available updates against that same target host. Any luck?

-Doug

[doug]

I’m not sure I understand what you’re asking for. Currently there is already an option under “Get Information > Get C: Disk Space” to retrieve the available disk space in megabytes (MB). Please explain in more detail so that I can understand what is different about your request from what is already there.

Thanks,

Doug

[doug]

Could you post the contents of any log files found on the remote machine in c:program filesbatchpatch ?

I believe this is an issue on the remote 2008 server, not the 2012 machine where you’re running BP, but please try running BP from a non-2012 machine to verify that it’s not the cause. On the remote 2008 server, please make sure it has the latest version of the Windows Update Agent. Error -1 can typically be resolved by running Windows Update manually one time on the remote 2008 machine and rebooting it. Then try BP again and let me know what happens.

Thanks,

Doug

[doug]

The active directory picker has been updated in the latest build (published today, 20120808). You can now view the entire tree and add computers from containers, OUs, and groups.

-Doug

[doug]

I believe the issue you’re having is explained here:

http://support.microsoft.com/kb/900935

You’re successful when you manually go to the Windows update site is because in that case the proxy discovery mechanism is actually not the same as when the service handles it.

According to the link above:

The Automatic Updates service can only discover a proxy server by using ONE of the following methods:

The proxy server is manually configured by using the Proxycfg.exe tool for Windows XP and Windows Server 2003. For Windows Vista and newer OS, Netsh command is available to manually configure the proxy server. For more information about how to use the Proxycfg.exe tool, click the following article number to view the article in the Microsoft Knowledge Base:

http://support.microsoft.com/kb/289481

OR

Web Proxy Auto Detect (WPAD) settings are configured in either of the following locations in the network environment:

The Domain Name System (DNS) options

The Dynamic Host Configuration Protocol (DHCP) options

For more information about a related topic, click the following article number to view the article in the Microsoft Knowledge Base:

http://support.microsoft.com/kb/816320

Let me know how it goes.

Thanks,

Doug

[doug]

firewind –

-2147012867 ERROR_INTERNET_CANNOT_CONNECT

This error would occur when the target computers are not able to contact the update server. If you’re using WSUS, make sure that the WSUS server is online and that the machines can connect to it. Also make sure that they are configured to connect to the WSUS server you’re expecting them to connect to and not some other machine. If you’re using Windows Update instead of WSUS, make sure the machines have access to the internet so that they can communicate with Microsoft’s servers.

As a starting point you can look at the “Actions > Get information > Get Windows update configuration” to confirm how the target computers are configured to receive updates. This action looks for the presence of the following key, which would get created if you’re using Group Policy to configure the WSUS location/settings on the target computers.

HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdateWUServer

Additionally, please take a look at C:WindowsWindowsUpdate.log on the target machines for additional information that might help find the culprit.

Lastly, are you using any sort of proxy configuration on the target computers?

Let me know how it goes.

-Doug

[doug]

This has been implemented.

-Doug

[doug]

twoj – hang in there. At the moment you’ll have to workaround it by temporarily modifying the remote log path just for that single server and then changing it back. The %systemdrive% variable option is not viable in BatchPatch for various reasons, but having BP fallback to the windows path might work or changing the setting from global to per-host would work too. It’s on the to-do list.

-Doug

[doug]

Thanks Hohum. We’ll consider this for a future build.

-Doug

[doug]

Thanks Travis. It’s on the list for a future build.

-Doug

[doug]

jakey – this is just a first-run implementation, so there is definitely room for improvement. We’ll consider your suggestions.

However, right now it should auto populate the current domain. So like:

DC=myDomain,DC=com

If you want you can then pre-pend an OU like:

OU=HRComputers,OU=allComputers,DC=myDomain,DC=com

What I don’t understand is how you would want to use group membership. Wouldn’t you have user objects in a security group? Not computer objects, right? Am I missing something here?

Thanks,

Doug

[Author]

Posts