Blog | Page 32

Remotely Install Windows Updates – A Guide To Updating Your Computers Remotely

By Scott | Published: May 29, 2014

It’s not necessarily as straightforward as it seems like it might be to remotely install Windows updates. Windows Server Update Services (WSUS) provides a significant amount of help with this process, but there are still a number of important considerations to keep in mind.

The great news about WSUS is that it’s free to use and easy to install and configure. With this step-by-step guide, the entire installation and configuration process can be completed in about 30 minutes.

The purpose that WSUS serves is to download from Microsoft all of the updates that your network of computers requires. Your computers are then able to retrieve updates from your local WSUS server rather than each individual computer having to connect directly to Microsoft. Aside from saving bandwidth, this means that your computers do not need direct access to the internet, so long as the WSUS has access. In more and more environments where security is important, disabling internet access for servers is becoming increasingly common. Additionally, WSUS gives you the ability to more easily approve or decline specific updates or groups of updates for your entire environment, thereby simplifying the overall management process. Lastly, WSUS provides some reporting functionality to help you stay up to date and keep in compliance with the security guidelines your organization follows.

The typical way that WSUS is used is with Group Policy. An administrator can configure Group Policy to control how often computers check for updates, download new updates, and install updates. The Windows Update section of the Group Policy Editor is pictured below.

The WSUS model can be seen as a kind-of “pull” model, whereby the individual machines check-in with the WSUS at a set interval (also configured in Group Policy) to retrieve and/or install available updates. Unfortunately there isn’t a way to use WSUS without a 3rd-party product to remotely install Windows updates on-demand at the click of a button.

What if you need a higher degree of control in your environment? What if the “pull” model isn’t enough for you, and in order for you to effectively do your job you need on-demand “push-install” capability for remotely installing Windows updates with real-time monitoring? That’s where BatchPatch shines! BatchPatch is an agentless application designed to be extremely simple and effective for administrators to remotely install Windows updates in their environments on any number of computers, whether it be just 50 hosts or as many as 1000. BatchPatch provides administrators with real-time control over the Windows update process. Install Windows updates remotely, on-demand, at the touch of a button, on all of your computers simultaneously. You can watch their progress in real-time as they search for, then download, then install available updates. And of course we all know that virtually every Windows update requires a reboot to complete the installation. Don’t worry, BatchPatch handles that too, automatically. Not only are you able to optionally include an automated reboot or shutdown, but you also have the ability to filter which updates are installed, install individual update packages instead of groups of updates, install third party software, wake on LAN, remotely execute scripts, and retrieve all sorts of information from target computers like registry values or configuration settings. The possibilities are virtually limitless.

The best news of all is that BatchPatch is free to try. The evaluation version is fully functional, only limiting the number of hosts that can be acted upon simultaneously. Even if you don’t have need to remotely install Windows updates, BatchPatch offers plenty more features. If you’re looking for a tool to help manage your entire network of computers, I would encourage you to give it a try. We are confident that once you test it out you’ll wonder how you ever got along without it. More and more sysadmins are adding BatchPatch to their collection of must-have systems management applications.

Posted in Blog, General, Tutorials | Tagged psexec, push windows updates, remote windows updates, remotely install windows updates, Windows Updates | Comments closed

PsExec v2.1 – All Network Communication Is Now Encrypted

By Scott | Published: May 19, 2014

Hey Everyone – I just wanted to take a moment to announce to anyone who hasn’t already heard that PsExec, starting with version 2.1, which was released on March 7, 2014, now encrypts all communication between local and remote systems. No more passwords sent in the clear!

In previous versions of PsExec, if you specified credentials with the -u and -p parameters, those credentials would be transferred to the remote systems in clear, unencrypted text. Note that this did NOT apply to cases where Integrated Security was used (remember that with Integrated Security, the security context of the logged on user is used, so no separate credentials are specified). It only applied to the cases where you supplied alternate credentials.

BatchPatch supports the latest PsExec v2.11, so please go ahead and make sure you update your copy. You can download PsExec from http://msdn.microsoft.com/en-us/library/bb897553.aspx

Additional Information About Hubs, Switches, and Encrypted Network Communications

While it’s definitely great news that PsExec now encrypts its network communications, for those of you who might not fully understand the ramifications of what this means, I’ll explain in a bit more detail. Sending passwords over the network in clear text sounds pretty bad, doesn’t it? Well, it’s actually not necessarily all that bad, in reality. It all depends on the details of your network setup. To be clear, I’m not saying that you shouldn’t have *any* concern about clear text credentials on your network. I’m just saying that you should understand exactly what the possible risks are so that you can determine if they are or are not a major concern for your situation. For the most part, while it’s definitely always better to encrypt credentials whenever possible, there are many situations where a clear text credential traversing a LAN is not the end of the world. There are other cases where a clear text credential traversing a LAN should be avoided at all costs.

First let’s clarify the difference between a hub and a switch. This is critical to understanding the security ramifications of sending data over the network without encrypting it.

HUB: A hub is essentially a network repeater. It’s not an “intelligent” device, per se. Any data that is sent from any port on the hub is then repeated to all other ports on the hub. This means that every port on the hub will receive (see) the same data that all the other ports see. Aside from being very inefficient, it also doesn’t provide any degree of security for the data that moves through it.

Imagine a 24-port hub with your computer connected to port 1, your target server connected to port 24, and then 22 other computers connected to the other ports on the hub. If your computer sends data to the target server on port 24, all other computers will see that data. In the event that you send a plain-text password to the target computer, if the machine plugged into port 7, for example, is setup to capture all of the data that it sees on its port, it will actually capture your password, even though your password is intended for the server on port 24.

SWITCH: Unlike a hub, a switch is a smart device. The switch actually learns what devices are connected to each of its ports, and it maintains a table to keep track of this information. When data is sent through the switch, the switch looks at the individual packets, and it forwards each packet only to the port or ports that the data is destined for. Not only is this much more efficient, but it also provides some security for the actual data.

Imagine a 24-port switch with your computer connected to port 1, your target server connected to port 24, and then 22 other computers connected to the other ports on the switch. If your computer sends data to the target server on port 24, NO other computers attached to the switch will see that data. In the event that you send a plain-text password to the target computer, if the machine plugged into port 7, for example, is setup to capture all of the data that it sees on its port, it will NOT capture your password. This is because a switch will send your data directly to port 24 without broadcasting it to all the other ports on the switch.

CONCLUSION: Since it’s now 2014, the very large majority of networks are built on switches, with very little or no use of hubs whatsoever. With regard to credentials being sent across a network in clear text, it’s not necessarily all that big of a deal when you’re dealing with a modern switched network. To be clear, I’m not saying that lack of encryption is good! I’m just saying that in relative terms, it might not be nearly as bad as it sounds. A malicious user wouldn’t simply be able to plug a device into an open port on the switch in order to be able to capture the data sent to all other ports on the switch. We generally recommend using encryption whenever possible. However, the point is that it’s always important to understand the nature of the problem you have so that you can best determine how to solve it or work around it. The clear-text credentials problem on a switched network is, for many network administrators, not necessarily the biggest problem. It depends on the particular network’s physical setup, the security requirements of the company that operates the network, as well as numerous other factors.

Posted in Blog, General | Tagged alternate credentials, encryption, psexec | Comments closed

Getting Started with BatchPatch

By Scott | Published: May 13, 2014

If you just downloaded BatchPatch for the first time, let’s go through the things that you need to have in place for the software to function properly.

PsExec: Download PsExec from Microsoft

PsExec needs to be placed in the Windows PATH of the computer that is running BatchPatch (target computers do *NOT* need psexec). The PATH is an environment variable that controls where Windows searches for an executable that is specified at the command line. We recommend that you simply put PsExec.exe in C:\Windows because the Windows directory is included in the PATH when Windows is installed. You can read more about the PATH here: http://en.wikipedia.org/wiki/PATH_%28variable%29.
If you have trouble you can alternatively specify a custom filepath for PsExec.exe in BatchPatch by going to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’.
Open a command prompt (start > run > cmd) and launch PsExec one time by typing ‘psexec’ without the quotes, and then press enter. Accept the End-User License Agreement for PsExec.
Make sure the PsExec.exe is not blocked by Windows. Right click on PsExec.exe and select ‘Properties’ and then click on the ‘General’ tab. If you see the ‘Unblock’ checkbox as shown in the image below, check the box and click OK.

Permissions: In order for BatchPatch to work properly, you must have access to a user account that is in the local administrators group on the target computers that you will be working with. In your environment, this might be as simple as logging on to your computer as a domain administrator, and then simply running BatchPatch. However, if you’re using local accounts with no domain, there are some additional configuration steps, so if you have any issues whatsoever with authentication with or without a domain, please first consult this link and read through it entirely to make sure you have everything setup properly: BatchPatch Authentication in Domain and Workgroup (Non-Domain) Environments
Firewalls: In order for BatchPatch to communicate with target computers, firewall software on the target computers either needs to be disabled altogether (not recommended), or it needs to be configured to allow the appropriate services to be able to communicate (recommended). For more information as well as instructions on configuring Windows Firewall for use with BatchPatch, please see this link: Using BatchPatch with Windows Firewall. For specific information about port requirements, please see BatchPatch Port Requirements. After that, verify on target computers that the following items are working:

The Workstation service is running (check using services.msc by going to start > run > services.msc)
The Server service is running (check using services.msc)
The Remote Procedure Call (RPC) service is running (check using services.msc)
The Windows Management Instrumentation (WMI) service is running (check using services.msc)
The Admin$ share is available (go to start > run > \\targetComputer\admin$ to test this connection)
‘File and Printer Sharing is enabled (no need to actually share anything)

Lastly, if you are using WSUS, here are some guidelines for Group Policy settings that you might want to incorporate to get the most out of BatchPatch. WSUS is NOT required to use BatchPatch. Additionally, if you DO use WSUS, no special configuration is required. BatchPatch will work with your existing WSUS environment. Additional guidelines for integrating WSUS and Group Policy for BatchPatch
Once you have everything in place, you can simply launch BatchPatch and add some computers to the grid!
Troubleshooting Common Errors: If you run into any problems, this link explains how to resolve the most common errors that might occur: Troubleshooting Common Errors in BatchPatch

Posted in Blog, General, Tutorials | Tagged getting started, prerequisites, requirements | Comments closed

BatchPatch May 2014 – New Build Released

By Scott | Published: May 2, 2014

Hey everyone! I’m happy to announce that we just published a new build. Listed below are some of the new features:

Host Status Audio and Email Alerts

BatchPatch will now produce optional audible alerts and/or email alerts when hosts go offline or come online. Alerts are only triggered while a host is actively being pinged in BatchPatch.

((NOTE: In case you forgot or weren’t already aware, BatchPatch’s Task Scheduler is capable of performing an action or sending you an email when a host comes online, and this functionality is independent of the pinger. So, if you have users who rarely seem to have their laptops online and you want to catch them with a quick Windows Update or software deployment as soon as they put their laptops on the network, use the Task Scheduler feature instead of the Pinger’s Host Status Alerts feature.))

For the Pinger Host Status Alerts, you may select your own .WAV files or just use the built-in sounds. Additionally, while you can configure a default setting for all new rows, you still have the ability to control each host’s alert settings in the event that you only want some hosts to create alerts. There’s a new image column to show the configuration of each row, and of course there are a couple new forms to actually configure the per-row and default settings.

Host Status ‘Online’ and ‘Offline’ Status Logging

BatchPatch now conveniently logs changes in a host’s status to the ‘All Messages’ column. The host must be actively pinged in BatchPatch in order for this logging to occur. So, for example if you select a handful of computers to remotely install Windows Updates and reboot automatically, it will be easy to determine from the ‘All Messages’ column exactly what time the hosts go offline and come back online.

New BatchPatch Template (.bpt) and BatchPatch Project (.bpp) File Types

The original BatchPatch file extension is .bps (BatchPatch State). This is the type of file that you get when you save a BatchPatch grid. A lot of our users need the ability to easily load multiple grids that contain the same information. With the new BatchPatch Template (.bpt) format, you can create a single .bpt file and then load it multiple times to create multiple identical tabs in an instance of BatchPatch. BatchPatch won’t let you save over a template file, so when you click the save button you’ll be prompted to save a new .bps file for the grid. You can create your own .bpt files by simply renaming existing .bps files, or you can use the File > Generate template file (.bpt) menu option to create a .bpt file from a BatchPatch grid.

BatchPatch Project (.bpp) files are simple text files that can be used to launch multiple .bps or .bpt files simultaneously. Instead of launching BatchPatch and dragging 5 .bps files onto the grid, you can now alternatively create a single .bpp file that contains the full filepath of each .bps or .bpt file that you want to load. For example, you might have a 4-line .bpt file with contents that look like this:
C:\myBpsFiles\computerList1.bps C:\myBpsFiles\computerList2.bps C:\myBptFiles\templateList1.bps C:\myBptFiles\templateList2.bps

As long as the file is saved with a .bpp extension (instead of .txt), BatchPatch will treat it as a BatchPatch Project file. Any time you launch a .bpp file, all filepaths in the .bpp file will be launched in the same BatchPatch instance. You can create your own .bpp files, or you can have BatchPatch create them for you with the File > Generate project (.bpp) menu item.

Load Previous Session’s Tabs on Launch

Many of you have asked for the ability to automatically load the previous session’s tabs when launching a new instance of BatchPatch. This is now available under Tools > Settings > General > Startup Options.

Opt-in to or Opt-out of Microsoft Update (for receiving other non-Windows Microsoft products through Windows Update in unmanaged environments)

For computers that are not managed by a WSUS or other update server, selecting this action is equivalent to launching the Windows Update GUI on a target computer and clicking the option to Get updates for other Microsoft products. This action only needs to be performed one time. Once completed, the Windows Update GUI will display a label that says You receive updates: For Windows and other products from Microsoft Update.

Grid Performance Improvements

Just as it sounds, grid performance is greatly improved now when dealing with large amounts of data in each cell. In particular, the ‘Remote Agent Log’,’All Messages’, and ‘Event Log Viewer’ columns can sometimes contain significant amounts of data relative to the other columns. In previous versions of BatchPatch when any/all of these 3 columns contained a lot of data, scrolling around and highlighting rows in the grid would be sluggish. That problem has been fixed and shouldn’t occur anymore.

Force Pinger to Use IPv4 Addresses

You no longer have to suffer with seeing IPv6 pings! Previous versions of BatchPatch would ping whatever address could be obtained for a given host, with no preference given to IPv4 over IPv6. In some environments this created a bit of pain, so you can now force BatchPatch to use IPv4 addresses. This setting is available under Tools > Settings > General.

Bug Fixes and Other Minor Updates

And of course a software update wouldn’t be a software update if it didn’t contain bug fixes!! 🙂 There are a number of minor bug fixes in this month’s release along with other tweaks, changes, and updates not mentioned above.

Posted in Blog, General | Comments closed

Using BatchPatch to Execute a Custom Script to Retrieve the Count of CPU Sockets, Cores, and Logical Processors from Remote Computers

By Scott | Published: April 28, 2014

One of the cool things about BatchPatch is that you can use it with your own scripts to retrieve information from many target computers. For the sake of this blog posting, let’s look at an example where an administrator wants to retrieve the count of CPU cores from his/her target machines.

Let’s start with the script. In this case I’ve written a vbscript to retrieve the count of CPUs by socket, core, and logical processor. First let’s take a look at the script, and then below I’ll show you how to execute the script from within BatchPatch.

Here is a what it looks like when we run the script manually from the command line:

Here is the actual script:

Download CPUCoreCount.vbs

'Gets the number of CPU Sockets, Cores, and Logical Processors.  Cocobolo Software LLC April 2014.
'usage: cscript.exe CPUCoreCount.vbs COMPUTERNAME

strComputer = WScript.Arguments(0)
 
on error resume next
Err.Clear
 
'strComputer = TextBox.value 'InputBox("Enter the Computer Name or IP address")
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
 
'Get OS Version for CPU info
Set colOperatingSystems = objWMIService.ExecQuery("Select * from Win32_OperatingSystem")
		For Each objOperatingSystem in colOperatingSystems
			OSVersion = objOperatingSystem.Caption
		Next
 
'Get Processor Info (note: it can take a long time to pull info from this class)	
Sockets = 0	
Cores = 0
LogicalProcessors = 0
WMISupport = 1
 
If InStr(OSVersion,"2003") or InStr(OSVersion,"XP") or InStr(OSVersion,"2000") Then
	WMISupport = 0
End If
 
Set colProc = objWMIService.ExecQuery("Select * from Win32_Processor")
	For Each objProc in colProc 
		ProcessorName = objProc.Name
		Sockets = Sockets + 1
		Cores = Cores + objProc.NumberOfCores
		If Err.Number <> 0 Then
			Cores = Err.Description
			Err.Clear
		End If
		LogicalProcessors = LogicalProcessors + objProc.NumberOfLogicalProcessors
	Next
 
If WMISupport = 0 Then
	LogicalProcessors = Sockets
	Sockets = "Property is not supported for this OS"
	Cores = "Property is not supported for this OS"
End If	
 
wscript.echo("Sockets: " & Sockets & vbCrLf & "Cores: " & Cores & vbCrLf & "Logical Procs: " & LogicalProcessors)

Using ‘Local process/command’ vs ‘Remote process/command’

BatchPatch has the ability to execute scripts locally on the computer that runs BatchPatch, or remotely on the target computers themselves. Depending on the needs in a particular situation, we decide which option makes more sense. In this particular case, if you take a look at the above vbscript, you can see that the script actually takes a target computer name as an argument. Since this script is able to give us information about remote computers without having to run it directly on remote computers, we will simply choose to execute it locally on the machine that runs BatchPatch, and we’ll pass our target computer names to the script so that we can retrieve information about those target computers. However, if the script were only able to retrieve information about the local computer without having the built-in capability of querying remote computers, then we would instead use BatchPatch to execute the script remotely on the target computers.

So, to be very clear…

If a script has built-in capability to query remote computers, then the script should be run on the local computer that runs BatchPatch using Actions > Local process/command.
If the script does NOT have built-in capability to query remote computers and it can ONLY retrieve information about the local computer that its being executed on, then the script must be executed remotely on each target computer using Actions > Remote process/command.

To execute the CPUCoreCount.vbs script using BatchPatch:

In BatchPatch, highlight the target computers and select Actions > Local process/command > Create/modify local command 1
Enter the actual local command/process. Note that because our script accepts a computer name as the first/only argument, we specify the $computer as our argument. When BatchPatch sees $computer it knows to substitute the actual computer name from the Hosts column. This way we are able to execute the local script one time for each machine in the grid.
Now to execute the script, highlight the target computers and select Actions > Local process/command > Execute local command 1
Finally, let’s examine the output. We have the option to either look at each computer’s result individually by middle-clicking on the cell that contains the output, or we could export an HTML report (File > Export), or we could even just copy and paste the grid contents into a spreadsheet program such as Microsoft Excel if it needs to be customized before presenting.

Posted in Blog, General, Tutorials | Comments closed

BatchPatch Authentication in Domain and Workgroup (non-domain) Environments

By Scott | Published: April 16, 2014

When we set out to create BatchPatch, one of our primary concerns was to ensure that the software would be as easy to use as possible. We believe we were successful in that endeavor. However, since every network environment is unique, there are a few things that need to be understood about the BatchPatch authentication process in order to maximize your odds of smooth patching. In particular, the requirements to make BatchPatch work in a Windows workgroup environment are slightly different than the requirements for a domain environment.

If you’re currently seeing the following error message or something similar, you’ve come to the right place. Please see below for more information on resolving/rectifying the issue:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

BatchPatch Runner Account Must Be A Member Of The Local Administrators Group On All Target Computers

One of the most common use cases of BatchPatch is to remotely trigger the download and/or installation of Windows Updates on a network of computers. In order to do this, the account that you use to initiate the BatchPatch process must have local administrator privileges on the the target computers. To add a user to the local administrators group on a group of computers you must either log on to each computer individually to add the account, or you may use Group Policy (recommended) to apply the appropriate group membership to all computers at the same time.

You have three options for executing BatchPatch actions under the security context of the selected user account. Any of these options will work, but we recommend option number 1. Use option 1 unless you have a strong reason not to. If option 1 isn’t viable in your environment, use option 2. If option 2 also isn’t viable or convenient in your environment, then use option 3.

Option 1:

Recommended Method: Log on to the computer that you will use to run BatchPatch with the user account that you have added to the local administrators group on the target computers

Option 2:

Launch BatchPatch using right-click run-as to run BatchPatch with the user account that you added to the local administrators group on the target computers. This method can be used in cases where you are not logged on to Windows with the user account that you have setup to use with BatchPatch.

Option 3:

Launch BatchPatch with any account, and then inside of BatchPatch enter ‘alternate credentials’ for each of the hosts that you add to the BatchPatch grid. The ‘alternate credentials’ that you specify will, of course, be the user account that you previously added to the local administrators group on the target computers.

Additional BatchPatch Authentication Details:

IMPORTANT: In the sections below that describe how to use local accounts for authentication, we highlight registry entries/changes that you might need to make in your environment if you desire to use local accounts for authentication. These registry modifications come with their own security implications. You can read more about those registry values and remote UAC filtering here:

User Account Control and WMI
Description of User Account Control and remote restrictions
User Account Control Group Policy and registry key settings

Using Integrated Security with a Domain Account:

The domain account that you use to launch BatchPatch must be a member of the local administrators group on the target computer.

Using Integrated Security with a Local Account:

The local account that you use to launch BatchPatch must also exist on the target computers, defined with the exact same username and password that is defined on the computer running BatchPatch.

If the local account you are using to run BatchPatch is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. If the DWORD does not exist, then you must create it. When this DWORD is set to 0, the built-in administrator account is set to full-token mode, and BatchPatch will work properly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most BatchPatch actions from completing successfully for those target computers:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets)

If the local account you are using to run BatchPatch is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then the following registry DWORD must be set to 1 on the target computers. If the DWORD does not exist, then you must create it:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy
(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets)

Using Alternate Credentials with a Domain Account:

The account that you specify must be a member of the local administrators group on the target computers.

Using Alternate Credentials with a Local Account:

The account that you specify must be a member of the local administrators group on the target computers.

If the local account that you specify is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. If the DWORD does not exist, then you must create it. When this DWORD is set to 0, the built-in administrator account is set to full-token mode, and BatchPatch will work properly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most BatchPatch actions from completing successfully for those target computers:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken
(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets)

If the local account that you specify is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then the following registry DWORD must be set to 1 on the target computers. If the DWORD does not exist, then you must create it:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy
(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets)

Further Troubleshooting:

There is a bug that Microsoft acknowledged that exists only in Windows 10 version 1803 where if your BatchPatch computer is running this specific OS version, you may experience ‘Access Denied’ when using alternate credentials with a local account to connect to target computers of any OS, even if you have properly created the registry values as described in the previous section above. At the time of this writing the issue exists only when the BatchPatch computer is running Windows 10 version 1803. All earlier and later versions of Windows do *not* exhibit this issue.

Another issue exists where if your BatchPatch computer is at a patch level earlier than August/September/October 2021 (specific month is dependent on the particular version of Windows you are running), but your target computers are at a patch level of June 2022 or newer, then even if you are doing everything else properly according to the instructions provided in the document above, you would still see ‘Access is denied’ in BatchPatch. Please see this posting for a full explanation and resolution.

If you continue to have problems with ‘Access Denied’ I would suggest that you look at Microsoft’s more in-depth WMI Troubleshooting article.

Posted in Blog, General, Tutorials | Tagged alternate credentials, authentication | Comments closed

How to Hard-Code Your Own Custom Commands in the BatchPatch Actions Menu

By Scott | Published: April 8, 2014

We have done our best to make sure that all of the typical commands a Systems Administrator might need to run on computers in his/her network have been included in BatchPatch, so that it’s very easy to get information from remote computers with just a couple of clicks. That said, if there is a command that you would like to be in the menu that isn’t currently in the menu, we’ve provided a way for you to add your own commands to BatchPatch such that they will appear in the Actions menu, just like the factory-commands that we have included. If you believe that we should add a command (or feature) that isn’t already included in the default setup, please contact us or post in the forum with your request, and we will respond as soon as possible. However, if you simply want to add your own custom commands that might be unique to your environment, see below for steps on how to do that.

What Types of Custom Commands Can You Add to BatchPatch?

Virtually any command that you would run at the command line is a command that you can incorporate into BatchPatch. Maybe you need to get some information from a remote computer, or maybe you want to start or stop a service, or perhaps you need to kill a process. BatchPatch does provide built-in menu options for starting/stopping services as well as killing processes, but maybe you regularly have to start/stop a very specific service, and you don’t want to keep typing in the name of the service every time you need to restart it. In this case it would be very convenient to simply add the specific command to BatchPatch. Here are a list of examples. These are just some of the many commands that someone could add to BatchPatch, if he/she was so inclined:

WMIC SERVICE list brief
WMIC SERVICE where caption=’DNS Client’ CALL startservice
WMIC SERVICE where caption=’DNS Client’ CALL stopservice
WMIC SERVICE where state=’running’ GET name, displayname, pathname, processID
WMIC SERVICE where (state=’stopped’ and startmode=’auto’) GET displayname, name
WMIC SERVICE where (state=’stopped’ and startmode=’auto’) CALL startservice
WMIC SERVICE where (DisplayName=’DNS Client’) CALL ChangeStartMode Manual
WMIC PROCESS list brief
WMIC PROCESS where name=’hungProcess.exe’ call terminate
WMIC PROCESS where name=’hungProcess.exe’ delete
WMIC USERACCOUNT list brief
WMIC CPU get name, caption, maxclockspeed, systemname
WMIC OS GET caption,servicepackmajorversion,version
WMIC PATH Win32_ComputerSystem GET model
WMIC PATH Win32_BIOS GET caption
WMIC PATH Win32_ComputerSystem GET systemtype
WMIC PATH Win32_DiskDrive where “model like ‘%OCZ%'” GET deviceID, model
WMIC PATH Win32_DiskDrive where “not model like ‘%OCZ%'” GET deviceID, model
WMIC PATH Win32_LogicalDisk where “drivetype=3” GET deviceid, volumename, freespace, size
TASKLIST
TASKKILL /F /IM “hungProcess.exe”
PATHPING google.com
REG QUERY “HKLM\Software\Microsoft”
REG QUERY “HKLM\Software\Microsoft\.NETFramework” /v InstallRoot

3 Different Locations in BatchPatch to Incorporate Custom Commands

You can add your own commands under any of the 3 following menus:

Get Information
Remote Process/command
Local Process/command

There is only one subtle difference to be aware of when deciding where to add your commands. If you choose to add a command under the Get Information, then when you actually execute that command, it will not prompt you to confirm the execution. It will simply execute straight-away, right after you click the command in the menu. However, for both the Remote Process/command and Local Process/command menus, any commands stored in these menus will require you to confirm “Yes” or “No” after clicking on the command to execute.

How to Add Your Custom Commands to the BatchPatch Menu

The process for actually hard-coding your custom commands into the BatchPatch menu is very simple. We’ll use the Get Information menu for this example.

Select Actions > Get information > Create/modify user-defined commands

In the dialog that appears, in the left-hand column add the name/title of the command (this name/title is what will appear in the BatchPatch menu), and in the right-hand column add the corresponding command to execute. There is no limit to the number of commands that you can add. Simply create a new row for each command that you want to appear hard-coded in the BatchPatch menu.

Finally, when you’re ready to execute the command, simply highlight the hosts that you want to send the command to, and then select Actions > Get Information > Execute user-defined commands and then select the specific command that you want to execute

Posted in Blog, General, Tutorials | Tagged custom commands, execute remote commands, user-defined commands | Comments closed

How To Send Email Notifications In BatchPatch

By Scott | Published: March 31, 2014

We confess… The BatchPatch email notifications feature is not the most intuitive aspect of BatchPatch. However, it’s actually very simple to use, and my goal with this posting is to illustrate how to use email notifications in BatchPatch.

The original design of BatchPatch was focused on real-time patching, with the idea that any action a user chooses to perform will be done while the user is operating the BatchPatch console but not at some later time when the user is no longer in front of the computer. If you’re sitting in front of the BatchPatch console while it’s doing work, there isn’t really much purpose to sending email notifications since everything that BatchPatch is doing is being monitored.

It didn’t take long before we added scheduling options to BatchPatch, so that the operator could choose to run actions in the middle of the night without having to be in front of the computer. This is where the email notifications become more important. If you setup a BatchPatch grid to remotely install Windows Updates and reboot a set of computers at 3AM, you might desire to see the status of that grid when you first wake up in the morning without having to log on to your computer. Wouldn’t it be nice if you could simply take a look through your email to see how things went during the unattended 3AM actions? Fortunately, with the BatchPatch email notifications feature, you can do this quite easily. BatchPatch enables you to send the contents of any grid or individual row in an HTML formatted attachment to any email address or set of email addresses.

The email notifications in BatchPatch are designed to run in two ways. You can setup an email notification to be sent either during a Job Queue or as a Scheduled Task.

Configuring the Default Email Notification Settings:

Go to Tools > Settings > Email Notifications
Fill out the fields in the Email Notification settings form, and use the Send test email button to verify that your settings are correct and actually work. If the Send test email doesn’t complete successfully, you’ll need to adjust your settings until your test email is sent without errors.
For the subject body format, you have a few options. The subject field can be populated with any text you wish. If you include “$host” in the subject line, then when an email notification is sent, the host name in the BatchPatch row that initiated the email notification will be included in the subject line. The body text field has 4 special “keywords” that you can use. The “$host” keyword will behave the same in the body as it does in the subject line. However, to have the email notification actually include information about the grid, you will want to use use one of the other 3 keywords ($row, $grid, $allGrids).

$row: If you specify “$row” in the body, the entire contents of the BatchPatch row that initiates the email notification will be included with any email notification that is sent.
$grid: If you specify “$grid” in the body, the entire contents of the grid that contains the row that initiates the email notification will be included with any email notification that is sent
$allgrids: If you specify “$allgrids” in the body, the entire contents of the all the grids in the entire BatchPatch instance that contains the row that initiates the email notification will be included with any email notification that is sent.

Overriding the Default Email Notification Settings for an Individual Row:

Highlight the host(s) that you want to override, and then select Actions > Email Notification > Override default email notification settings
As you can see, the Override settings allow you to modify the Recipients, Subject, and Body, on a per-row basis. The rules for these fields are the same as described above for the Default Email Notification Settings, but in this case your settings will be for a given row, rather than applying to all rows that have not been overridden.

Using the Job Queue to Send Email Notifications:

Highlight the rows you wish to act on, and then select Actions > Create/modify job queue
In the Job Queue form, one of the actions that you may select to add to a queue is “Send email notification.” So, for any action(s) that you want to perform, you may put the “Send email notification” option as the very last item in the queue. When the job queue for that row is executed (either manually or by a scheduled task), the last action in the job queue will send the email notification. The email notification will be sent using the settings defined in Tools > Settings > Email Notifications unless you have overridden the particular row’s email notification settings, in which case the overridden settings for that row will be applied. Note that for the per-row email notification that we describe here, it probably makes the most sense for the “Body” field for your email notifications to be set as “$row” so that each row’s email notification sends the contents of its own row in the body of the email.

Using the Task Scheduler to Send Email Notifications:

For many users it doesn’t make a lot of sense to have each row send its own email notification at the end of a task. Often times it makes more sense to only send one email notification at the end of a series of tasks. For this, we prefer to use a scheduled task to send an email notification at a specific date/time. For example, if you are running a series of tasks at 2AM for a set of hosts, you could setup a single email notification to run for the entire grid (or all grids in the BatchPatch instance) at, say, 3AM. When 3AM comes, an HTML export of the entire grid (or all grids, if using $allgrids in the body text) will be sent to the specified email address(s). At 7AM when your alarm wakes you up out of a wonderful slumber, just pop open your smart phone email application to check out the grid status at 3AM without needing to get out of bed. You’ll be able to see exactly what happened during the 2AM actions by examining the HTML attachment email notification that was sent at 3AM.

Create a “dummy” row in a BatchPatch grid. The reason this is a “dummy” row is because it’s not going to be used to perform an action on a specific host. Instead it will be used by BatchPatch strictly for sending an email notification at a specific date/time. You may use any “dummy” host name you like for the row.
Highlight the row and then create a scheduled task for the row by clicking Actions > Task Scheduler > Create/modify scheduled task
Set any email notification overrides that you want for the particular row by highlighting the row and selecting Actions > Email Notification > Override default email notification settings. We recommend to use “$grid” or “$allgrids” in the body text field so that when the email notification is actually sent at the scheduled time, it will include the grid contents for the entire grid ($grid) or all grids in the BatchPatch instance ($allgrids).
Create a scheduled task that will perform the Send email notification action, as shown in the screenshot above.
Make sure to ENABLE THE TASK SCHEDULER by clicking on the small clock icon in the upper right corner of the BatchPatch window.

You can view a sample BatchPatch email notification (HTML export) here:

Posted in Blog, General, Tutorials | Tagged email notifications | Comments closed

Removing Adobe Shockwave from Multiple Computers

By Scott | Published: March 19, 2014

From time to time we get asked how to use BatchPatch to uninstall Adobe Shockwave from a group of computers. The good news is that it’s relatively simple and straightforward.

The first thing we need to do is locate the uninstall string in the registry on a computer that has Adobe Shockwave installed. Launch the Registry Editor by going to Start > Run > Regedit.
Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and look for the Shockwave key. For older versions of Shockwave you’ll be searching through the many GUIDs that you see (ex: FF2A5498-4EFE-430F-A138-7EB365DBEBAD) for the REG_SZ called DisplayName. The DisplayNamevalue would contain a string that says something like Adobe Shockwave Player 11.1.

However, newer versions of Shockwave actually appear under their own Adobe Shockwave Player key instead of a GUID key. In the screenshot below you can see that we have located the appropriate key.
At this point we need to identify the UninstallString value, which in this case for version 12.1.0.150 is "C:\Windows\system32\Adobe\Shockwave12\uninstaller.exe"
Now let’s find that “uninstaller.exe” and copy it to our BatchPatch computer. For the sake of clarity in this example I have renamed the exe to shockwave_uninstaller.exe. We are going to deploy it to the target computers and then execute it remotely to uninstall shockwave on our targets. Once you have a local copy of the uninstaller.exe, select the hosts in BatchPatch and choose Actions > Deploy software/patch/script/regkey etc. Select the uninstaller as shown in the screenshot below, and then click OK.
Finally, select Actions > Deploy software/patch/script/regkey etc > Execute deployment
We can see that we were successful when we receive Exit Code: 0 (SUCCESS). And of course if we look at the target machines, we will find that Adobe Shockwave has been successfully removed.

Posted in Blog, General, Tutorials | Tagged software removal, software uninstallation | Comments closed

Deploy Java to Multiple Computers

By Scott | Published: March 10, 2014

We have a more recent tutorial posted here: Remotely Install Java 8 On Numerous Computers Simultaneously

The tutorial below utilizes an installation method that appears to no longer be necessary to remotely deploy Java. The new tutorial linked above should be all that is required at this time to perform the deployment. However, if you are installing an older version of Java and are having problems with the new method outlined in the tutorial above, you may want to try the old method outlined below.

Despite the fact that the Java Runtime Environment (JRE) has continued to be the source of repeated security vulnerabilities both in corporate environments as well as on home computers, we know that Systems Administrators are still frequently tasked with installing, updating, reconfiguring, and uninstalling Java in their environments.

At the time of this writing there seems to be a general consensus in the security community that if you do not need Java, you should uninstall it. However, if you *do* need it, at the very least when you install it you should make sure that it’s disabled in web browsers because that’s where the primary vector for attack lies. Unless you know definitively that you need Java running in your web browser, you probably don’t!

In this posting we’ll address how to remotely install Java to your entire network of computers using BatchPatch. In a future posting we’ll discuss how to remotely disable Java in web browsers.

Download the Java offline installer package. At the time of this writing you can retrieve this file from the following page: https://www.java.com/en/download/help/windows_offline_download.xml. However, if this link breaks at some point in the future, simply use Google to search for the Java offline installation download location.
For this example we are going to install Java version 7 update 51. The Java installer comes as a .EXE file, which unfortunately doesn’t support any silent or quiet installation parameters. The trick here is that you actually have to extract the contents of the .EXE in order to get a .MSI file that you can then use in a silent installation with BatchPatch. To extract the .EXE, doubleclick on it to launch it, but instead of completing the installation, after the installation dialog pops up, go ahead and cancel out of it. Then browse to the following location on your computer to find the .MSI file with a Data1.cab: C:\Users\yourUsername\AppData\LocalLow\Sun\Java\jre1.7.0_51
Before proceeding to install Java, one important thing to keep in mind is that the Java installer typically needs web browsers to be closed. Failing to close any web browsers before installing or uninstalling Java could cause the process to hang or not complete or it might simply require a reboot in order to complete the process. Consider killing all browser sessions with Actions > Services/Processes > Kill specific running process by name to kill firefox.exe, chrome.exe, and iexplore.exe on target computers.
Now that we have the .MSI and .CAB files extracted from the .EXE, we can setup the deployment in BatchPatch. Highlight the computers you want to push Java to, then select Actions > Deploy software/patch/script/regkey etc > Create/modify deployment.
In the BatchPatch Deployment window select the directory that contains the Java .MSI and .CAB files, and choose the actual .MSI file to appear in the MSI field in the Deployment window. Finally, tick the box to Copy entire directory in addition to the specified file. The reason we tick this box is because this installation requires the presence of BOTH the .MSI as well as the .CAB file. By ticking the box we are telling BatchPatch to copy all the files in that directory, which in this case is just those 2 files, to the target computers. We also verify the installation parameters, which in this case are /q /norestart.
After clicking OK on the Deployment window you can see that each of our target hosts contains the appropriate command that will be executed after the Java installation files are copied. Highlight the hosts that you are deploying Java to, and then select Actions > Deploy software/patch/script/regkey etc > Execute deployment. Click OK to begin the deployment.
Soon enough when the installation completes successfully, we see Exit Code: 0 (SUCCESS)

Posted in Blog, General, Tutorials | Tagged deploy java remotely, deploy software, remotely install java | Comments closed