Here’s how to use BatchPatch to push the .NET framework to remote hosts that don’t already have it installed.  You can easily modify this example to push Adobe updates, Java updates, or just about anything else to remote hosts.

When the remote host is XP/2003:

1.  Add your remote host(s) to the BatchPatch grid, highlight the row(s), and then choose “Create/modify patch deployment”

2.  Select the .NET installer and add “/q /norestart” to the parameters field

3.  Choose “Execute patch deployment” to begin the process.  The installer file will be copied to the remote host and executed.

4.  After a few minutes, we see “Exit code: 0,” which signifies success.  If you receive a different exit code, you should Google it to find out what it means.  Windows installers can return a host of different numbers to indicate various things like “reboot required,” for example.

When the remote host is Windows 2008:

Windows 2008 makes .NET a “feature” that you can install from the command line, so we simply have to execute the proper command on the remote host(s)

1.  Add your remote host(s) to the BatchPatch grid, highlight the row(s), and then choose “Create/modify custom PsExec command”

2.  Type “servermanagercmd -install net-framework” with no quotes, of course, in the field.

3.  Choose “Execute custom PsExec command” to begin the process.

4.  After a few minutes, we see “Exit code: 0,” which signifies success.  If you receive a different exit code, you should Google it to find out what it means.  Windows installers can return a host of different numbers to indicate various things like “reboot required,” for example.

BatchPatch uses a combination of Windows Management Instrumentation (WMI) and PsExec to access remote computers, plus ICMP for pinging.  If you need to use BatchPatch in an environment where your remote computers have Windows Firewall enabled, here’s what you need to do to make everything work.

It is sufficient to use Group Policy to allow “Remote Administration” and “File and Printer Sharing” on the remote computers.

However, if Group Policy is not an option and you instead need to manually adjust the remote computer settings, here’s how:

When the remote system is Windows 2008:

Go to Control Panel > Windows Firewall > Change Settings >Exceptions > check the box for “File and Printer Sharing” and “Remote Administration” and then click “Apply” or “OK.”

When the remote system is Windows 2003:

1. Go to Control Panel > Windows Firewall >Exceptions > check the box for “File and Printer Sharing” and then click “OK.”

2. Open a command prompt and type:

netsh firewall set service type = remoteadmin mode =  enable

Installing Windows Updates Remotely with BatchPatch:

Installing Applications or Patches Remotely with BatchPatch:

News!
I’m excited to announce that we’re in the final stages of testing for the new release of BatchPatch, expected to “drop” in August. We’ve got all sorts of new features lined up plus lots of other little enhancements, as well as bug fixes. Some of the new features are listed below.

—————————————————————————————————————————-
—————————————————————————————————————————-

Tabbed Interface
The new tabbed interface is great for those folks who are dealing with lots of hosts or lots of host groupings. This should make it much easier to manage your BatchPatch grids to be even more efficient with your patching.

Multi-grid Interface
The new multi-grid interface gives you an alternate view of your tabs, allowing you to look at them all simultaneously, tiled inside the main BatchPatch window. You can easily switch between the multi-grid and regular tabbed interfaces.

Custom User-defined Commands
You can now create and save as many commands as you want, allowing you to easily execute and view the result of any command on a target host with just a single click. This option allows you to fully customize BatchPatch, making your own custom commands appear hard-coded into the menu.

Remote Console Output
There are now plenty of ways for you to view all the console output of commands that are executed remotely.

Improved Deployment Options
Deploying software and patches or standalone updates like MSI, MSU, MSP files has never been easier. BatchPatch can remotely deploy/execute just about any type of file, including EXE, VBS, REG, BAT, CMD, PS1, etc. If you need to install software or run a package on many computers simultaneously, you can do it with BatchPatch’s Deployment feature and just a few clicks.

Update and Reboot Cycle
BatchPatch now gives you an easier, automated way to execute a patch and boot cycle on your computers. For example, let’s say you want to install Windows updates on a list of computers, then reboot, then download and install any new Windows updates, then reboot again. It’s extremely easy to do this with BatchPatch. If you need the cycle to repeat 3 times, 4 times, or 10 times, no problem! It only takes a few clicks to customize the cycle to suit your needs.

Improved Scrollable ToolTip
The primary tooltip that is displayed when you middle-click on any cell is now scrollable, resizable, and moveable with right-click-drag or middle-click-drag. It also supports ctrl-c to copy text to the clipboard.

Concurrent Thread Maximum
The new concurrent thread maximum setting gives you more control over performance when patching. As you choose more actions to run they are added to the queue, to be executed only when there is a free thread available.

Scheduler
The scheduler now supports a new option to execute a task immediately upon detecting a target computer online, rather than having to set a specific date/time. This makes it easy when deploying to a large group of users who do not always have their computers on the network. BatchPatch will simply wait until the computer is available on the network before executing the desired task.

Start and Stop Services by Name
Just as it sounds, the new version enables you to start and/or stop individual services on target computers

Kill Remote Processes by Name or PID
Kill any remote process on target computers by specifying either the process name or the process ID.

More Features Coming Soon!
We have more features planned, so please stay tuned. And of course, as always, if you’d like to request a feature or submit a bug, please either post in the forum or contact us directly.

New PDF administrator’s guide. You can download it here:

Download: BatchPatch_Admin_Guide

Hey everyone – I just wanted to take a few minutes to blog about some of the new features that we’ve added to BatchPatch over the past several months. We’ve been able to get a lot of good functionality added, and there is still a plenty more to come in the new year. The list of features below only covers the more significant additions.  There have also been a ton of minor updates and improvements made in the past months.

Download and/or Install Specific Windows Updates by Name

Not only can you easily download and install all available Windows Updates, but now it’s also very easy to choose specifically which Windows Updates you want to download and/or install on target computers simply by inputting a list of KB numbers or update titles.  See Actions > Windows Updates > Create/modify list of specific updates for download / installation.

Hide / Unhide Windows Updates

If you’re not using a WSUS server, you might find that you want or need to hide updates that you don’t want to install in order to prevent them from constantly re-appearing in the list of available Windows Updates on your network of computers.  BatchPatch lets you easily choose which updates to hide or unhide.  See Actions > Windows Updates > Hide / Unhide updates.

Bypass the Default/Managed Update Server and Use Microsoft Update Instead

If you are using WSUS or SCCM in your environment, there are times where you may still want to have computers check-in with Microsoft Update instead of your own managed update server.  BatchPatch now has an option to bypass your managed server so that you can search, download, and install available updates from Microsoft Update instead.  See Tools > Settings > Remote Agent (or Tools > Settings > Windows Update Agent).

New PDF BatchPatch Administrator’s Guide

It’s now much easier to get help with the new searchable PDF Administrator’s manual.  The support forum is, of course, still available, and you can always email us too.  See Help > BatchPatch Admin Guide.

Emulate Microsoft’s Delivery of “Important” and “Recommended” Updates

BatchPatch now has search options that allow you to search only for Important updates or Important + Recommended updates.  See Tools > Settings > Remote Agent (or Tools > Settings > Windows Update Agent).

View BatchPatch.log and WindowsUpdate.log Files in the System Default Viewer Instead of the BatchPatch Built-In Log Viewer

If you have a log file viewer that you prefer to use, such as CMTrace, you are now able to have BatchPatch launch log files in that viewer rather than in the built-in viewer.  See Tools > Settings > General.

Email Notifications

BatchPatch now includes functionality to send email notifications either in a BatchPatch Job Queue or as a BatchPatch Scheduled Task.  Notifications may be sent per-row, per-grid, or per-all-grids in a given instance of BatchPatch.

Export BatchPatch Grids to HTML

Use the File > Export grid option to save a grid or grids at HTML files.  This option gives you a nice view of a BatchPatch grid and all the cell contents in an easy to digest format.

Retrieve the Pending Reboot Status of Target Computers

There is no longer any need to question if your computers are waiting to be rebooted.  BatchPatch can reach out to target machines and check all of the places that Windows stores pending reboot information, so that you can know exactly what the status of your machines are.

BatchPatch makes it very simple to deploy not only Windows Updates but also software, scripts, registry keys, MSIs, EXEs… you name it.  Today we’re going to be discussing how to deploy software to computers on your network.  In this case we’ll use Firefox as an example. (Scroll to the bottom for a video demonstration)

1.  Launch BatchPatch and right click on the empty grid.  Choose “Add hosts…” (NOTE, you may also add hosts directly from Active Directory or from a .TXT or .CSV file).

2.  Add the computer names or IP addresses of the machines that you want to deploy to.  Then click OK.

3.  After clicking OK, you’ll see the hosts listed in the BatchPatch grid.

4.  Select Actions > Deploy software/patch/script/regkey etc > Create/modify deployment

5.  At this point you should be looking at the Deployment form.

6.  Browse to the location of the Firefox setup file on your computer by clicking the “…” button to the right of the textbox at the top of the Deployment form.  In order to deploy any software EXE, MSI, MSP, or MSU, we must also make sure that when the file is executed remotely on the target computers, it will be executed silently or quietly.  This means that it will not prompt the user to select any installation options or click OK or Next etc.  We need the installer package to run on its own without any user interaction whatsoever.  If the installer prompts for user interaction, it will hang indefinitely on the target computer.  This is because the installer will be executed hidden, and any popups will not be visible to users and will just wait indefinitely for someone to interact with them and click OK or Next etc.  So, we add the /S switch to the Parameters field.  Remember that different installer files will have different silent/quiet parameters.  Some use /S or /s while others use /Q or /q.  Others may use a different parameter or parameters altogether.  It’s important to first determine what switch to use either by checking with the vendor, googling, or by running the installer at the command line with a /? or ? parameter to see what options the particular installer has.  Click OK to close the Deployment form.

7.  You should now have a command in the Deployment column for each host that you intend to deploy to.  You are ready to execute the deployment.

8.  All that’s left to do is execute the deployment.  Go to Actions > Deploy software/patch/script/regkey etc > Execute deployment.  When you do this, the firefox_setup_26.0.exe file will be copied to the target systems, and then the “firefox_setup_26.0.exe /S” command will be executed on each target.  BatchPatch will report Exit Code 0 if all was successful.

Video – Deploying Software to Multiple Computers with BatchPatch:

One of the questions we commonly receive is what is the best way to use BatchPatch in conjunction with a WSUS server?

First, let me say that we *DO* recommend using BatchPatch in conjunction with WSUS.  However, it is *NOT* a requirement since BatchPatch will work beautifully without WSUS, but since WSUS is free and extremely simple to setup, there’s little reason to not have it.  You can typically get WSUS installed and running in only 30 minutes. If you aren’t familiar with WSUS, I would encourage you to install it on a spare VM. It requires very little processing power, though at a minimum you’ll want to allocate a 20GB data partition to it to store all of the updates. Download it for free from Microsoft: http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx

A few advantages to using a WSUS server

• Reduced bandwidth consumption: Your WSUS server will download updates from Microsoft, and then your clients will download updates from your WSUS server. Without WSUS, your clients would all directly retrieve updates from Microsoft.
• Easily approve or decline which updates will be seen by client machines: You can have WSUS automatically approve updates for you, but if there’s a specific update you want to make sure your machines don’t get, it’s easy to simply decline it.
• Reporting: WSUS will give you some basic reporting functionality

Our recommended approach to using BatchPatch with WSUS

1. Use Group Policy to have your client machines automatically download updates from the WSUS:
   • Create/edit a group policy that is linked to the OU containing your computers
   • In Group Policy editor (gpedit.msc) go to Computer Configuration > Administrative Templates > Windows Components > Windows Update and make sure to enable the Specify intranet Microsoft update service location setting with your WSUS server as the target
   • In the same location, set the Automatic Updates detection frequency to an interval of 1 hour, which will ensure that your machines retrieve updates soon after they are available
   • In the same location, set the Configure Automatic Updates setting to 3 = (Default setting) Download the updates automatically and notify when they are ready to be installed

    
   

2. When your maintenance windows begins, use BatchPatch Actions > Windows Updates > Install downloaded updates, which will tell your client machines to install updates that they have already downloaded. They will not reach out to your WSUS unless you instead select BatchPatch Actions > Windows Updates > Download and install updates. However, the whole purpose of using group policy setting number “3″ (specified above) is to have your machines download available updates before your maintenance window begins. This way when you are actually ready to install updates on your machines, you can minimize the total time the process takes by having the updates already downloaded. Of course you are welcome to use BatchPatch to initiate the download portion if that’s your preference, but for maximum time savings, we like to have the clients pre-download any available updates. This will also prevent any potential bottlenecks on the WSUS server.

Hey folks! – We published a new build earlier today, and I would like to take a moment to share with you some of the new features.

Read remote event log entries

It’s now super-easy and convenient to use BatchPatch to help diagnose problems on your computers. We’ve added direct support to query the Windows event log on remote computers. This feature should come in very handy.
Select Actions > Get Information > Get event log entries
 

Read remote registry keys directly

Using BatchPatch to query remote registry keys has been possible for a long time. However, in this most recent release we’ve added direct support for this functionality to make it easier for you to utilize.
Select Actions > Get Information > Get reg key/value
 

Send custom messages to the logged-on users of your computers

It’s now very simple to notify logged-on users of any actions you are about to perform, especially if those actions will cause them to be booted off
Select Actions > Send message to logged-on users
 

Optionally append DNS suffix to host names when importing hosts from Active Directory

If you prefer to import host names including the FQDN, this is now just a check-box away.
 

This video demonstrates how to deploy software to multiple computers quickly and easily. It only takes a few clicks and a few seconds. In this instance we push install Notepad++ to 5 computers on our network.
 

A systems administrator frequently needs to update the Windows Registry of every computer on his/her network. Did you know that you can use BatchPatch to accomplish this task extremely rapidly? BatchPatch provides administrators with a very simple way of getting registry keys to remote computers on a network.

1. Create a .reg file for deployment. To do this you simply launch regedit.exe and highlight the key that you want to deploy to your target computers, and then choose File > Export. The registry editor application will create a .reg file for you. If you look at that reg file in a text editor, you’ll see it contains a line for each value in the key that you are creating/modifying. In the below screenshot you can see a .reg file for a FileZilla configuration that contains a single DWORD value in the HKLM\SOFTWARE\FileZilla key.
    
   
2. Now that you have your .reg file prepared, highlight the hosts in BatchPatch that you want to deploy it to, and select Actions > Deploy software/patch/script/regkey > Create/modify deployment
    
   
3. Browse to the location of your .reg file. After you select the file and click OK, you’ll see that BatchPatch displays the Command to execute:
   regedit.exe /s "yourRegFile.reg"
    
   
4. The last thing you need to do is actually execute the deployment. You can do this by highlighting the hosts you are deploying to, and then select em>Actions > Deploy software/patch/script/regkey > Execute deployment. Upon successful completion of the deployment you should see Exit Code: 0 in the All Messages column.
    
   

Here’s a video demonstration of registry key deployment with BatchPatch:

Registry key deployment to numerous remote computers using BatchPatch – Video Demo:

Did you know that BatchPatch provides functionality to control Windows services on remote computers? For example, maybe you want to remotely reboot a large number of computers, but after they come online you also want to make sure that all services that are set to automatic are started. Fortunately you can do that pretty easily with BatchPatch. There are built-in scripts that enable you to perform the following actions on your network of computers. Best part is that you can perform these actions on many computers, simultaneously:

• List all services
• List automatic services
• List manual services
• List disabled services
• List automatic services that are currently in a stopped state
• Start automatic services that are currently in a stopped state
• Start a specific service, by name
• Stop a specific service, by name

To get a list of the services that are set to Automatic but currently in a stopped state, highlight your host(s) and select Actions > Services / Processes > List stopped automatic services

Notice that our stopped automatic services are listed in red:

If we want to issue a start command to all of the Automatic services that are currently stopped, no problem. We just select Actions > Services / Processes > Start stopped automatic services

A confirmation dialog appears asking us to click OK to continue with the operation. The script that will be executed on the highlighted hosts is displayed.

After clicking OK, BatchPatch will reach out to all of the target hosts that are currently highlighted in the grid, and it will execute the command to start all stopped automatic services. Upon completion we will see Exit code 0 in the All Messages column. We can then confirm that all of the services were sent start commands by looking at the contents of the Remote command output log column:

Did you know that you can deploy Windows Service Packs with BatchPatch? It’s actually very simple, just like deploying software or patches. BatchPatch gives you a simple way to push a service pack installer file to target computers, execute the service pack installation across all the target machines at the same time, and then reboot them with ping monitoring.

Before getting started, there are two items that we should address to help things go as smoothly as possible.

• First, let’s take a look at the Concurrent File-Copy Operations Maximum setting, which can be viewed by clicking Tools > Settings > General. The purpose of this setting is to prevent the network connection from being overloaded when BatchPatch is in the process of copying the service pack installer file (or any file that is being deployed) to target computers. So, let’s say you execute the service pack deployment across 100 machines. Without this maximum setting enabled, BatchPatch would try to copy the 500+ megabyte executable file to all 100 computers simultaneously. For the sake of performance, this probably isn’t the greatest idea. It would make much more sense to copy the file to only one or a few machines at a time.
   
  Note, if you wanted to you could actually use the Concurrent Thread Maximum setting to limit the number of active deployment execution threads in BatchPatch. However, since an individual service pack installation can take quite a while to complete, your overall time needed to deploy a service pack to 100 computers would be significantly increased since only X deployments would execute simultaneously, where X is the Concurrent Thread Maximum value that you specify in Tools > Settings.

  So, instead of lowering the maximum number of concurrent threads, BatchPatch provides you with the ability to limit just the number of active file-copy operations that BatchPatch will perform. This means that if you execute a deployment simultaneously across 100 target machines, BatchPatch will only attempt to copy the installer file to X number of machines at a time, where X is the number you specify for the Concurrent File-Copy Operations Maximum setting. However, as the file copy completes for each machine, there will be no delay in the execution process as there would be with the Concurrent Thread Maximum setting.
   
  For a large service pack installer file, I recommend keeping the Concurrent File-Copy Operations Maximum setting quite low, possibly even as low as 1, depending on your preference. Somewhere between 1 and 4 is probably a sweet spot, but feel free to use your own judgement. If you were manually going to copy a large file to multiple computers, how many transfer streams would you want to run at one time? As always, testing gives you the most information to make an educated decision, but there is no wrong answer here. It just depends on what you want and what you think will work well.

• The second item we need to address is the location of the service pack installer file. Put it somewhere on the same machine that you’re using to run BatchPatch. Avoid deploying the service pack from a different computer’s shared directory. The reason for this is because for each target host that BatchPatch is deploying to, BatchPatch will end up pulling the file down from the network location through the computer that is running BatchPatch, and then finally on to the target host. This will double the amount of data that the BatchPatch computer has to transfer. However, if you start with the exe on the BatchPatch computer, then it can just push it directly to the target hosts.

OK, so let’s get started with the actual deployment. For this example we are deploying Windows 7 Service Pack 1.

1. First we need to determine what is the quiet/silent installation switch for the service pack exe. To do this we open a command prompt (Start > Run > cmd.exe) and type C:\deploymentFiles\windows6.1-KB976932-X86.exe /? where ‘deploymentFiles’ is the location of your service pack installer file. The /? will show us the command line switches that the exe supports. We will use /quiet /nodialog

2. Now, in the BatchPatch grid highlight the hosts that you want to deploy the service pack to, and then click on Actions > Deploy software/patch/script etc > Create/modify deployment. We need to select the location of the installer exe, and then we need to add /quiet /nodialog to the parameters field.

3. After clicking OK we can see that each row has a Deployment command populated. Now all we need to do is execute the deployment. Highlight the rows and select Actions > Deploy software/patch/script etc > Execute deployment. Click OK to confirm deployment. That’s it! Now we wait for execution to complete.

4. If installation completes successfully we will see Exit Code: 3010, which is a typical exit code for Windows installer files that means the installation was successful but reboot is required to complete it. However, since we didn’t specify the /norestart switch, Windows will actually automatically initiate the reboot for us anyway.

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.

1. 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.
2. 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
3. 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.
4. 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.
   
5. 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.
   
6. Soon enough when the installation completes successfully, we see Exit Code: 0 (SUCCESS)
   

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.

1. 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.
2. 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.
   
3. 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"
   
4. 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.
   
5. Finally, select Actions > Deploy software/patch/script/regkey etc > Execute deployment
   
6. 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.
   

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:

1. Go to Tools > Settings > Email Notifications
   
2. 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.
3. 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:

1. Highlight the host(s) that you want to override, and then select Actions > Email Notification > Override default email notification settings
   
2. 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:

1. Highlight the rows you wish to act on, and then select Actions > Create/modify job queue
   
2. 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.

1. 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.
2. Highlight the row and then create a scheduled task for the row by clicking Actions > Task Scheduler > Create/modify scheduled task
   
3. 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).
4. Create a scheduled task that will perform the Send email notification action, as shown in the screenshot above.
5. 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:

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.

1. Select Actions > Get information > Create/modify user-defined commands
2. 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.
3. 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