Configuring Ping Status Alerts in BatchPatch

By Scott | Published: May 27, 2015

You probably didn’t know that you can use BatchPatch to notify you when a host goes offline or comes online. BatchPatch can be configured to only produce an audible alert, or it can be configured to send an email alert (or both). Maybe you want to deploy software to a particular computer that isn’t currently online because the user is out of the office with his/her laptop. One option is to create a scheduled task that will automatically execute the deployment as soon as the computer is detected online. However, perhaps you don’t want to automatically execute the deployment and instead you only want to be notified when the computer comes online. At that point you can either execute the deployment manually or you can touch base with the user about something else altogether, if needed. Here’s how to do it.

Email settings: Open the email settings window by selecting Tools > Settings > Email Notifications. Fill out the notification settings, and then make sure to test that the configuration is working by using the Test email settings button, which will send a test email notification to the recipients you included.
Default alerts: Select Tools > Settings > Ping Status Alerts. When you add new rows to a grid, those new rows will use the settings that are configured in the Global default alert settings for NEW rows panel. Note, once a host has been added to a grid, you can easily change that host’s settings, which I will describe how to do below. Finish configuring the desired default settings, and then click OK to close the settings window.
Configure individual host alert settings: Once a host has been added to a grid, you may configure it to behave differently from the default configuration, if you wish. For example, some hosts can be setup to send email notifications when they come online, while for other hosts you might only want to generate audio alerts when they go offline. Select any hosts for which you want to change alert settings, and then select Actions > Ping status alerts. In the image below I have configured some of the computers to have no audible alerts and to only send email notifications when the computers come online. The other hosts are configured to generate audible notifications when they come online or go offline.
Override email recipients on a per-computer basis: (Optional) If you would like to modify specific hosts in the tab so that they email particular people rather than using the default email recipients, you can override the default configuration for any or all row(s). Select the row(s) and then click on Actions > Email notification > Override default email notification settings. You can see in the image below that 6 of the rows are configured with just one email recipient as their only target for email notifications.
Start pinging: The last thing you need to do is start pinging the computers in the grid. Select the rows and then click Actions > Start pinging. Note, a row will only produce audio alerts and/or send email notifications when they are actively being pinged in a grid. When a given computer’s ping reply changes from ‘TimedOut’ to ‘Reply from…’ you’ll receive an email notification or hear an audio alert, depending on the settings you configured for the row.

Posted in Blog, General, Tutorials | Tagged audible alerts, audio alerts, email alerts, email notifications, ping alerts | Comments closed

Windows Update Installation Filters

By Scott | Published: May 21, 2015

When installing Windows Updates, you have a number of options to select from in order to determine where the updates are retrieved from and which updates are downloaded and installed. Let’s take a moment to go through everything.

Start by taking a look at the Windows Update settings screen under Tools > Settings > Windows Update.

Server Selection:
The Server Selection radio buttons control where target computers will retrieve updates from. When BatchPatch is operating with cached mode disabled (it is disabled, by default), all target computers will retrieve their updates from either a managed WSUS server, Windows Update, or Microsoft Update.

Default / Managed: BatchPatch instructs each target computer to use its existing configuration to determine where to search for updates. A computer’s existing configuration would either come from group policy or manual configuration at the console. In either case, when ‘Default/Managed’ is selected, it just means that BatchPatch will use the target’s configuration. This is frequently what the administrator wants. However, in some cases the administrator might specifically want to instruct computers to bypass their own WSUS server in order to search Windows Update or Microsoft Update instead.

Windows Update: BatchPatch instructs each target computer to bypass its own configuration and search for updates on Microsoft’s public server. This includes only Windows updates.

Microsoft Update: BatchPatch instructs each target computer to bypass its own configuration and search for updates on Microsoft’s public server. This includes Windows updates AND updates for other Microsoft products. However, before using Microsoft Update, target servers must be opted-in to the service, otherwise they will throw an exception when the search for available updates is executed. See Actions > Windows Updates > Opt-in…

Search Preferences: When a search for updates is initiated, BatchPatch uses the Search Preferences to determine what search query is used.

Software and Drivers: When both the ‘Software’ and ‘Drivers’ boxes are checked, BatchPatch instructs target machines to search for *all* available updates. This is the most expansive search allowed. However, if only one of these boxes is checked, the search scope is limited to include only the checked option, while excluding the unchecked option.

Important and Recommended: As you might have noticed when looking at the regular control panel Windows Update interface on any given computer, Microsoft makes its own determination of what updates are considered ‘Important’ vs ‘Recommended’ vs ‘Optional.’ BatchPatch provides you with capability to mimic this behavior, so if you want your computers to only find updates that are ‘Important’ and/or ‘Recommended,’ you are able to do so. If both checkboxes are checked, then the search scope is limited to include important and recommended updates while excluding ones that Microsoft considers optional.

Update Classification Filtering: During the download and/or installation process you are able to further refine which updates are downloaded and/or installed on target computers by checking/unchecking different classification filter options. Every Windows Update that Microsoft publishes is categorized into one of the following groups:

Critical Updates
Security Updates
Definition Updates
Updates
Update Rollups
Service Packs
Feature Packs
Drivers
Tools

If you want to ensure that a service pack or a driver is never installed on your target computers, then leave the Service Packs and Drivers checkboxes unchecked at all times.

For environments that use a WSUS server, we recommend setting the ‘Search Preferences’ to include both software and drivers. Then check every box in the ‘Update Classifications’ section. In this case BatchPatch will *not* restrict or limit the updates that are seen by or installed on target computers. Instead, it’s the approval settings on your WSUS server that will control which updates are available to computers. When BatchPatch is used in this case, generally the administrator wants BatchPatch to detect all updates that have been approved by the WSUS, rather than having BatchPatch restrict which updates are downloaded/installed.

For environments that do *not* use a WSUS server, we recommend checking both the ‘Important’ and ‘Recommended’ checkboxes, so that BatchPatch installs all the updates that Microsoft deems important and recommended. Optional updates will not be installed.

EULA Behavior: Every once in a great while, Microsoft will release an update that requires the user to agree to a EULA (End User License Agreement) before the update is able to be installed. Generally speaking I don’t see a reason to ever uncheck this box as I have only ever seen this feature be used for an update to Internet Explorer. 99.9% of updates will install with no EULA. If an update *does* require a EULA to be accepted (this is exceedingly rare), then if this checkbox is *not* checked, BatchPatch will skip the update without installing it.

Cached Mode / Offline Updates:‘Cached mode’ turns BatchPatch into a central distribution point that will cache Windows Updates and act as a conduit for the cached updates to be applied to target computers. ‘Offline mode’ provides a facility to apply Windows Updates to computers that do not have access to the internet or a WSUS server. For more information on either of these features, please visit Cached Mode and Offline Updates

Posted in Blog, General, Tutorials | Comments closed

Using Alternate Logon Credentials in BatchPatch

By Scott | Published: May 5, 2015

You have a few different options for initiating actions on target computers with the account that you have set aside for administrative actions. Most actions in BatchPatch must be executed with an account that has local administrator permissions on the target computer. However, in some cases a BatchPatch administrator might not be logged on to the BatchPatch computer with the same account that has been granted local administrator privileges on the target computers. Below are the different methods available to the administrator.

3 methods for specifying credentials:

(Integrated Security Option 1 – Recommended) Logon to the BatchPatch computer with the same account that has been granted local administrator permission on the target computers. This is the recommended method for operating BatchPatch. Whenever possible, we encourage you to simply log on to the computer that runs BatchPatch with the same account that you have designated to exist in the local administrators group on the target computers. When you launch and operate BatchPatch, it will run under the security context of that same account, and so it will automatically have the appropriate permissions to connect to target computers.

(Integrated Security Option 2 – Recommended when option 1 is not possible) Launch BatchPatch using “run-as,” by right-clicking on the BatchPatch.exe and choosing “run-as” so that you may enter different credentials for launching the application. In this case you might be logged on to your computer with one account, but you are then able to launch and run BatchPatch under a different account, with that different account also being a member of the local administrators group on the target computers. NOTE: Generally, in order for this to work properly you must have logged on to the computer at least one time with the run-as account. If you are trying to use a run-as account that has never been used to log on to the computer, you will most likely experience an error.

(Alternate Credentials – Less Secure) Launch BatchPatch normally, but input row-specific credentials for each host in the BatchPatch grid. With this option you are able to specify a different logon account to use for each target host listed in the BatchPatch grid. If your target hosts are setup such that you must use a different logon account to obtain administrative privileges on each of the target computers, then this method is your best bet: ‘Actions > Specify alternate logon credentials’.

Why is using ‘Alternate Credentials’ less secure than using ‘Integrated Security’? Generally any time you are dealing with passwords you are creating a new potential exposure for those passwords to be seen or captured by malicious actors. For many users, the use of alternate credentials in BatchPatch probably won’t be a major concern, but for some users it might be a deal-breaker, so it’s important to understand what’s happening under the hood so that you can make an educated decision about how to use the software in your environment.

**BatchPatch enables you to specify alternate logon credentials for a given host/row at any time, but in order for this to be possible the credentials will necessarily appear at times in the BatchPatch computer’s RAM (Random Access Memory) as plain, unencrypted, text. While the passwords are generally stored encrypted in memory to whatever extent possible, conversion from plain text to encrypted text and from encrypted text to plain text in memory by the application is still required in order to make use of those passwords, thereby causing those passwords to still appear in RAM in plain text and sometimes to also linger in memory in plain text for longer periods of time than we would like. If a malicious actor has gained access to the BatchPatch computer, it could be possible for him/her to dump the contents of memory and retrieve passwords. However, it’s also the case that if a malicious actor has gained access to the BatchPatch computer that it may already be too late in a sense, regardless of whether or not he/she is able to capture passwords from RAM. That is, the machine is compromised, and whether or not the malicious actor gains access to credentials from RAM may not matter because he/she may already have more than enough access to wreak havoc on the network.

**Furthermore, alternate credentials in BatchPatch will also be used during the execution of certain command line queries and scripts during some BatchPatch actions that you initiate. If you have systems in place that are logging command line activity on all computers (some organizations do this as standard practice), then passwords could/would end up in your logs. Similarly, these passwords could be captured by a malicious user who has gained access to the system.

**Lastly, if you save a BatchPatch grid (File > Save) to a .bps file, any alternate credentials that were entered for a row in the grid will be stored in the .bps file. It’s important to protect files containing credentials, so please see ‘File > Protection options’ to review/modify the grid file encryption settings available. We also always recommend that you employ additional encryption measures whenever possible to further protect such files, and that you restrict access to such files to whatever extent possible, or avoid saving grid files altogether. Of course if you can avoid alternate credentials altogether and instead only ever use integrated security so that no credentials ever have to be involved at all, that’s still the best option.

Domain environments:

In typical domain environments, there isn’t much else that you have to be aware of when it comes to logon accounts. As long as the logon account that you are using to run BatchPatch (or the logon account that you have specified per-row in the ‘alternate credentials’ dialog) is in the local administrators group on the target computers, you should be ok when it comes to permissions and authentication.

Non-domain (workgroup) environments:

IMPORTANT: In workgroup / non-domain environments, there are a couple of extra items that you need to be aware of in order to get authentication working properly with BatchPatch. 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

In non-domain environments you will be launching BatchPatch under the security context of a local account instead of a domain account OR you will be specifying alternate credentials in each row of the BatchPatch grid. In order for these methods to work, the local account that you’re using to launch BatchPatch or the local account that you are specifying in each row of the BatchPatch grid must also exist on the target computers, defined with the exact same username and password that is defined on the computer running BatchPatch. This user account must also be a member of the local administrators group on the target computers.

Once you’ve got your accounts all setup on the target computers with the same username and password that is used for the account on the computer that is running BatchPatch, and you’ve made sure that each target computer’s local administrators group contains the local account that you just created on each target computer, there is still one more element to configure.

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

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets):
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken

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:

(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets):
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

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

Advanced Script Integration with BatchPatch

By Scott | Published: April 27, 2015

In BatchPatch we’ve tried to integrate numerous features to help an administrator perform his/her duties. However, no matter how much we provide out-of-the-box, there will always be unique situations in every environment, and it might be the case that you want BatchPatch to do something that it doesn’t already do. Of course in these instances you are welcomed to send us an email describing what you’d like to see added to the software. But if you’re looking to accomplish something non-standard that’s not currently available on the BatchPatch menu, it’s very possible that this can already be done using BatchPatch, if you’re willing to do a bit of scripting.

For example, let’s say that you want to use BatchPatch to install Windows Updates and reboot a group of computers, but you want to ensure that the process does not begin until each computer is no longer running a certain process or processes. You’d like to be able to tell BatchPatch to update and reboot your computers as soon as a certain set of processes is no longer running. How could you accomplish this task? One way to do it would be to write a simple script that runs indefinitely in a loop, checking for the existence of specific running processes. If the processes are found to be running on the system, then the script sleeps for a minute before checking again. This goes on indefinitely until the script does not detect the specified processes, at which point it exits. Using a simple script like this, you could integrate it into a BatchPatch job queue, such that as soon as the script ends, your Windows Update and reboot process begins. Here’s how it can be done:

Sample script:

Download ProcessComparison.vbs

'Gets the list of running processes on a computer.  If a running process matches a pre-defined list of executables, the script sleeps for a minute and then checks again.  If there is no match, the script exits.  Cocobolo Software LLC April 2015.
'usage: cscript.exe ProcessComparison.vbs COMPUTERNAME

'the first argument from the command line is assigned to strComputer
strComputer = WScript.Arguments(0)
 
'create an array containing the list of process names that we want to ensure are no longer running
publishedAppsArray = Array("MyProcess1.exe","MyProcess2.exe","MyProcess3.exe")
 
Do
 
	strRunningProcessesList = ""
	boolIsProcessRunning = 0
 
	on error resume next
	Err.Clear
 
	Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
 
	'Get list of running processes
	Set colProcess = objWMIService.ExecQuery("Select * from Win32_Process")
			For Each objProcess in colProcess
				strRunningProcessesList = strRunningProcessesList & " " & objProcess.Name
			Next
 
	'loop through our list of exes to see if there is a running process on the computer that matches an entry in the list 
	For Each strPublishedProcessName in publishedAppsArray
 
		'this If statement will return 0 if the strPublishedProcessName is NOT found in strRunningProcessesList
		If InStr(LCase(strRunningProcessesList),LCase(strPublishedProcessName)) = 0 Then
			boolIsProcessRunning = 0
		Else
			boolIsProcessRunning = 1
		End If
	Next 	
 
	'If there are no published apps running then the Do loop is exited and the script subsequently exits, else the script waits a minute before looping and checking again
	If boolIsProcessRunning = 0 Then
		Exit Do
	End If
 
	'sleep 60 seconds
	WScript.Sleep 60000
 
Loop

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

BatchPatch is capable of executing scripts locally on the same computer that runs BatchPatch.exe, or remotely on target hosts. In some situations it might be easier or make more sense to use one option over the other. In this particular case, in the vbscript posted above, we are actually able to pass a computer name into the script as an argument. This script is able to operate on remote computers without having to run directly on the actual remote computers, so in this case we are able to execute it using ‘Local process/command’ in BatchPatch. However, if the script didn’t have the ability to query remote computers and was instead written to operate on the computer that was executing it, then we would instead use ‘Remote process/command’ in BatchPatch to perform the execution.

Remember…

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 it’s being executed on, then the script must be executed remotely on each target computer using Actions > Remote process/command.

To integrate the ProcessComparison.vbs script into a Job Queue using BatchPatch:

First we need to create the ‘Local process/command’ that we’ll use later in the Job Queue. Select Actions > Execute local process/command > Create/modify local commands.
In ‘Local Process’ window we’ll add the command to execute our script.
We’re able to use $computer as a parameter, which will tell BatchPatch to send the host name from the row that executes the script. This is the key to how we use a local script to accomplish a task on a remote computer.

Next we’ll create the Job Queue that utilizes the script. The goal with this job queue is to only download and install Windows Updates on target computers *after* the script exits, which will indicate that none of the pre-defined processes that we hard-coded into the script are running on the target computers when the Windows Update action is triggered. Select Actions > Job Queue > Create/modify job queue.
In the Job Queue window, locate the ‘Local Command’ you just created, and then insert it into the queue before the ‘Download and install updates + reboot if required’ action. Then save the queue by clicking the >> button.
Finally we’re ready to execute the queue. Select Actions > Job Queue > Execute saved job queues > Wait for pre-defined processes to end…

BatchPatch will now wait until a target computer no longer has the running processes specified in our script. Then it will execute the Windows Update + reboot if required. That’s all there is to it!

Posted in Blog, General, Tutorials | Tagged custom scripting, job queue, local command, local process, remote script execution, Windows Updates | Comments closed

Using BatchPatch to Deploy Adobe Flash to Numerous Computers (.MSI format)

By Scott | Published: April 23, 2015

I thought I’d spend a few minutes today to demonstrate how to install the Adobe Flash plugin to numerous computers, simultaneously, in just a few clicks.

Obtain the installation media. In this example we’re going to use the .msi installer file that Adobe makes available. I recently tried to use the .exe that they publish, but at least at the time of this writing it doesn’t seem to support a quiet/silent command line installation, despite their documentation saying that it does. Adobe has a specific distribution license agreement that you are likely required to agree to before you may distribute Adobe Flash in your environment. The following link has more information about that, and of course it’s your responsibility to make sure you are properly licensed before proceeding with a deployment: Adobe Flash Player Distribution.
Once you have obtained the .msi installer file, the process for deploying it to your computers is very straightforward. Add your hosts to the BatchPatch grid, highlight them, and then select Actions > Deploy software/patch/script/regkey etc > Create/modify deployment
In the deployment window, click on the […] browse button to browse for the .msi file that you obtained from Adobe. You’ll be prompted to select a Normal (singular) deployment or a Multiple update file deployment. Choose the ‘Normal (singular)’ option, and then browse to the location of your ‘install_flash_player_17_plugin.msi’ file.
You’re now ready to execute the deployment. Your deployment window should look something like mine does in the screenshot below. You can simply click “Execute now” to deploy the .msi file to all the highlighted computers in your grid. You may optionally first save the deployment by clicking the >> button. This would enable you to easily execute the deployment at a later date/time, if you so desired.
When execution of the deployment is complete you should see Deployment: Exit Code: 0 appear in the All Messages column. That’s all there is to it! Pretty simple, right?

Posted in Blog, General, Tutorials | Tagged .msi, adobe, adobe flash, deploy adobe flash, deploy flash, deploy software, deployment, flash, software deployment | Comments closed

Importing Hosts and Other Information into a BatchPatch Grid

By Scott | Published: April 7, 2015

In the April 2015 release of BatchPatch we updated the method responsible for importing computers so that you can now import other items in addition to computer names and IP addresses.

The allowed values are:

1	# MAC \| NOTES \|\| NOTES2 \|\|\| DESCRIPTION \|\|\|\| LOCATION \|U\| USERNAME \|P\| PASSWORD \|D\| DOMAIN

As long as you preserve the overall order of items listed above, you can enter as few or as many of them as you want when you import host names. It doesn’t matter whether you’re importing host names by using the “File > Add hosts” option or if you have a text file that you’re simply dragging and dropping on to the grid. The format rules will apply in either case. Below are some common examples of how one might choose to enter host names or IP addresses into the grid with additional information.

For example, if you only want to enter host names into a grid, the required format is as follows:

host1
host2
host3
host4
host5

However, if you want to add host names with MAC addresses, use the following syntax:

host1#CCDDEECCDDEE
host2#DDEECCDDEECC
host3#EECCDDEECCDD
host4#CCDDCCDDEEEE
host5#CCDDEEEECCDD

If you want to add host names, MAC addresses, and location information, use the following syntax:

host1#CCDDEECCDDEE||||3rd Floor Office
host2#DDEECCDDEECC||||Server room
host3#EECCDDEECCDD||||Data center
host4#CCDDCCDDEEEE||||4th Floor Office
host5#CCDDEEEECCDD||||4th Floor Office

If you want to add host names, MAC addresses, usernames, and passwords, use the following syntax:

host1#CCDDEECCDDEE||||3rd Floor Office|U|username|P|password
host2#DDEECCDDEECC||||Server room|U|username|P|password
host3#EECCDDEECCDD||||Data center|U|username|P|password
host4#CCDDCCDDEEEE||||4th Floor Office|U|username|P|password
host5#CCDDEEEECCDD||||4th Floor Office|U|username|P|password

If you want to add host names, MAC addresses, special notes, descriptions, usernames, and passwords, use the following syntax:

host1#CCDDEECCDDEE|Don't Reboot Unless host 23 is powered off|||host1 is responsible for video monitoring||||3rd Floor Office|U|username|P|password
host2#DDEECCDDEECC|Don't Reboot Unless host 24 is powered off|||host2 is responsible for intranet website monitoring||||Server room|U|username|P|password
host3#EECCDDEECCDD||||Data center|U|username|P|password
host4#CCDDCCDDEEEE||||4th Floor Office|U|username|P|password
host5#CCDDEEEECCDD||||4th Floor Office|U|username|P|password

If you want to add host names and notes, use the following syntax:

host1|special notes for host1
host2|special notes for host2
host3|special notes for host3
host4|special notes for host4
host5|special notes for host5

Posted in Blog, General, Tutorials | Tagged import | Comments closed

Remotely Install Multiple .MSU Files (or .MSI and .MSP files) to Numerous Computers

By Scott | Published: April 2, 2015

In the latest version of BatchPatch (April 2015) we added a macro to automatically configure a deployment of multiple .MSU files (.MSI and .MSP also allowed). Deploying and then remotely installing an entire folder’s worth of patches / updates to numerous computers has never been easier. Note, if you’re using a pre-April-2015 version of BatchPatch, you can still accomplish this task, but it requires an extra manual step. Please take a look at this tutorial for pre-April-2015 versions of BatchPatch: Remote Script Deployment – Install Multiple .msu Files In A Single Action On Remote Computers. However, if you’re using the April 2015 (or newer) version of BatchPatch, here’s how it works:

Place all the .MSU files that you plan to install into a single folder. There should be nothing else in that folder. You can use this method to install .MSU, .MSP, or .MSI files, but since Microsoft seems to now have mostly standardized on .MSU files for individual Windows update packages, in this example we’re just using .MSU files.

Once all of your installation package files are in a single folder, launch BatchPatch and highlight the hosts that you want to include in the deployment. Then select ‘Actions > Deploy software/patch/script > Create/modify deployment.’
In the ‘Deployment’ window that appears, click the folder browser button.
Select the ‘Multiple update file deployment’ radio button, and then click OK.
A message box pops up explaining to place all .msi, .msp, and .msu files to be deployed into a single folder. Click OK and then select the folder.
After we select the folder, BatchPatch scans the folder for .msi, .msp, and .msu files. BatchPatch then creates a .cmd script file in the folder. The .cmd file contains the commands that will be used during execution to install the .msu files.
When we click OK on the final message box, BatchPatch automatically inserts the correct/appropriate deployment configuration options into the ‘Deployment’ form. The configuration is setup so that when you execute the deployment, the .cmd file that BatchPatch created along with the entire folder of .msu files will be copied to the target computers. Once copied to the target computers, BatchPatch will execute the .cmd script, which will handle installing each .msu file, sequentially.
That’s all there is to it. You can now save and/or execute the deployment!

Posted in Blog, General, Tutorials | Tagged deploy, deploy .msi, deploy .msp, deploy .msu, deploy multiple files, remotely deploy | Comments closed

Virtual Machine Guest + Host Update and Reboot Sequence Automation

By Scott | Published: March 23, 2015

Today I want to take some time to address a common scenario for administrators of virtual machine environments. In the most recent release of BatchPatch we added a new feature called the ‘Advanced multi-row queue sequence,’ which allows the BatchPatch administrator to create more complex update and reboot sequences than were previously possible. One example of where this can really come in handy is for virtual machine environments.

Imagine for a moment that you have a Hyper-V host with a dozen virtual machine guests running on it. When Microsoft ‘Patch Tuesday’ arrives, you want an easy way to update all of the virtual machines and then update the physical VM host, and then finally reboot the VM host. Not only that, but you want to do it by launching a single task that will take care of the entire process so that you don’t have to pay attention to each step along the way. The new ‘Advanced multi-row queue sequence’ in BatchPatch let’s you do exactly that.

For this example, we’ll use the BatchPatch ‘Advanced multi-row queue sequence’ to create and then execute a sequence to download and install Windows Updates on all of the virtual machine guests on a particular virtual machine host. And then as soon as the updates have been installed on all guests, the host will be automatically triggered to download and install updates plus reboot.

To get started let’s select all of the VM guests on Hyper-V_HOST1.
Next select ‘Actions > Job Queue > Create/modify advanced multi-row queue sequence.’ In the ‘Advanced Multi-Row Queue’ window we have to now choose a name for our sequence, and we have to specify the position number of each host/guest that will participate in it. In the screenshot below you can see that I’ve called the sequence ‘Hyper-V_Sequence1’ and I’ve applied position number 1 value to all of the VM guests, with the VM host getting position number 2. What this means is that when we eventually execute the sequence, all position number 1 rows will execute simultaneously, and then BatchPatch will wait for them to complete. Once all position 1 rows are done, the position 2 row will begin execution. The sequence name is used to determine which rows are participating in a given sequence. If you apply the same sequence name to all rows, then all rows will be included in the same sequence. If you want to have multiple different sequences in a single grid, no problem. To do that you simply need to apply a different sequence name along with appropriate position numbers to each group of hosts.
Now that we’ve set the sequence name and position numbers, we have to configure the actual action that each row will execute when the sequence is launched. To do this, we select all of the VM guest rows and then go to ‘Actions > Job Queue > Create/modify job queue.’ In the job queue window we’ll select ‘Download and install updates.’ Then we click ‘Apply queue to row(s) without executing.’ Lastly, we select the VM host row and apply a queue to it as well. However, in this case we’ll apply ‘Download and install updates + reboot always.’

We end up with something like this:
We’re almost done with the setup. The last thing we need to do is create an ‘Execution row’ for the sequence. This is a special row that we designate to enable us to actually launch the sequence. The host name that we specify for the row doesn’t actually matter, but for the sake of clarity I’ve created a new row ‘Hyper-V_Sequence1_ExecutionRow’ in the ‘Host’ field.

The final step is to execute the sequence. In this example we’ll launch the sequence manually, but you can just as easily launch the sequence at a specific time and date using the ‘Task Scheduler.’ To launch the sequence on-demand, highlight the ‘Execution Row’ and then select ‘Actions > Job Queue > Execute advanced multi-row queue sequence.’ The ‘Confirm Action’ prompt appears and tells us exactly what is about to happen. When we click ‘OK,’ the job queue that we specified for each row in the grid that contains the sequence name ‘Hyper-V_Sequence1’ will be executed in the order that we specified, which now appears in the ‘Advanced Multi-Row Queue’ column. In this instance that means all of the VM guests will download and install updates. When they are all finished, the VM host will then download and install updates plus reboot.

Posted in Blog, General, Tutorials | Tagged multi-host, multi-row, queue, sequence | Comments closed

Advanced Multi-Row Queue Sequence

By Scott | Published: March 16, 2015

In the most recent release of BatchPatch we added a cool new feature that we’re really excited about. It’s called the Advanced Multi-Row Queue Sequence. This new automation feature really ties together some of the other functionality in the application, so that you can now create much more advanced, automated sequences. Essentially it allows you to expand the functionality of a normal job queue across multiple rows. Instead of just having a single host be able to execute a sequence of actions on that host, independently of tasks that might be running on other hosts, the advanced multi-row queue sequence allows you to tie together or link the actions of different hosts into one larger, more complex sequence.

You can use the advanced multi-row queue sequence to execute an action or a set of actions on one or more target computers. When those target computers complete the specified actions, another target computer or set of computers could be triggered to execute an action or set of actions. When the second set of computers is finished, a third set of computers could be triggered, and so on. In a single sequence you can integrate scripts, deployments, updates, reboots, and pretty much anything else that BatchPatch has to offer.

Admittedly, it’s a bit challenging to explain the advanced multi-row queue, so after I do my best to give you some examples of how it might be used, I’ll include a step-by-step tutorial so that you can see exactly what I mean. Below are a few ways that one can use this new feature:

In a virtual machine environment an administrator could use an advanced multi-row queue sequence to update and reboot all the VM guests as well as their VM host, all in a single automated sequence. The sequence could be configured so that when it begins all VM guests are updated, and then when all VM guests are finished updating, the VM host is automatically triggered to update and reboot.
In an environment that utilizes a script to put the entire environment into ‘maintenance mode,’ an advanced multi-row queue sequence could be used to launch the script and wait for it to complete, and then upon completion start the update process on hosts, and then when the update process on hosts is completed, another script could be triggered to disable ‘maintenance mode’ for the environment.
Some environments require that machines are only taken offline or rebooted in a very specific order. The advanced multi-row queue sequence allows you to easily string together actions such that any number of hosts could be updated and rebooted in any order desired by the administrator. Target hosts could be setup to update sequentially or simultaneously, or you could configure a combination of sequential and simultaneous actions.

Tutorial: Using the Advanced Multi-Row Queue Sequence

The first thing we have to do is configure the regular job queue for each row. Since all 4 hosts in our sequence are going to be performing the same actions, we can apply the same queue to all of them. However, if you are going to have different hosts complete different actions, then adjust accordingly so that each host’s job queue is set to complete only the tasks that need to be completed on that host. Highlight the hosts and select ‘Actions > Job Queue > Create/modify job queue.’ In the ‘Job Queue’ window choose the desired actions, and then click ‘Apply queue to row(s) without executing.’ In the screenshot below you can see that I’ve selected two actions:
Download and install updates + reboot always Wait for host to go offline and come back online
Once the desired job queue is applied to each row, we have to choose a name for our sequence, and we have to set the order of execution. In this example our sequence is going to execute the job queue on host1 and host2 simultaneously. Only after both rows’ actions are complete and the hosts have come back online after being rebooted will the job queues for host 3 and host 4 be executed simultaneously. Select ‘Actions > Job Queue > Create/modify advanced multi-row queue sequence.’
Every sequence in a grid has to have a unique name. All rows with the same sequence name will be considered part of the same sequence. If two rows are given different sequence names, those two rows will not be able to participate in the same sequence. As you can see in the screenshot, using the ‘Apply values to selected row(s)’ button, I’ve set the sequence name ‘Tutorial,’ and I’ve set the sequence position numbers for all hosts so that host1 and host2 are in position number 1, and host3 and host4 are in position number 2.
We’re almost done, but before we can actually execute the sequence, we need to create a specially designated ‘ExecutionRow.’ Since a sequence might be comprised of numerous rows, we use this specially designated ‘ExecutionRow’ for launching the sequence. In this case, the host name used in the execution row doesn’t matter and can be anything. I’ve chosen ‘TutorialExecutionRow’ but you could use anything you want. I then highlighted the row and chose the “Create Sequence Execution Row” option, and then I clicked ‘Apply values to selected row(s).’ In the screenshot below in the ‘Advanced Multi-Row Queue’ column we can see what this looks like. All 5 rows are assigned the same sequence name ‘Tutorial.’ The 4 hosts that will be included in the sequence also have position numbers, while the execution row is assigned as such.
We’re now ready to execute the sequence! Highlight *only* the execution row, and then select ‘Actions > Job Queue > Execute advanced multi-row queue sequence.’ That’s all there is to it. You can even set the execution row to be launched by the Task Scheduler if you desire. However, as always we urge you to use caution when running a complex sequence without a human monitoring the process.

You’ll notice that when you launch the sequence the first thing that happens is both host1 and host2 start performing the actions in their respective job queues since they are both assigned sequence position number 1. Once both hosts have completed their respective queues, only then will host3 and host4 begin their job queues because host3 and host4 are both assigned sequence position number 2.

If you’re confused about this feature, another tutorial that demonstrates how you might use the advanced multi-row job queue sequence is posted here: Virtual Machine Guest Host Update And Reboot Sequence Automation

Posted in Blog, General, Tutorials | Tagged automation, job queue, sequence, sequencing | Comments closed

Basic Multi-Row Queue Sequence

By Scott | Published: March 6, 2015

One of the questions we get sometimes is how do you update and reboot a set of computers in a specific sequence, without having to babysit the entire process?

In the most recent version of BatchPatch we introduced the basic ‘multi-row job queue sequence.’ This new feature takes the existing job queue to the next level by allowing you to string together job queues from multiple rows in the BatchPatch grid all into a single, larger multi-row (multi-host) job queue.

So, let’s say you have 10 machines, and you want them to be updated and rebooted one at a time, so that no more than one host from the group is ever offline at any given time. You can use the new basic ‘multi-row job queue sequence’ to accomplish this. Another potential use case is for a virtual machine environment. You might want to update each guest VM in sequence, followed by the VM host. (NOTE: We also have an *advanced* multi-row queue sequence, which allows much more complex sequences that are not limited to a single host at a time. You can use it to execute actions on multiple hosts, and when those hosts all complete their actions, another set of hosts can be triggered to execute actions, and when all of the second set completes, a third set can be triggered, and so on. Very cool stuff!)

Below I explain how to use the new basic ‘multi-row job queue sequence’ to perform a simple ordered reboot sequence for 3 hosts. The goal here is to reboot host1, wait for it to go offline and come back online, then reboot host2 and wait for it to go offline and come back online, and then finally reboot host3.

First we need to apply a job queue to each row that we want to include in the multi-row job queue sequence. Highlight the hosts and then select ‘Actions > Job queue > Create/modify job queue’. The job queue that we’re creating contains only 2 items:
Reboot (force, if required) Wait for host to go offline and come back online

Click ‘Apply queue to row(s) without executing’
After applying the queues to the selected rows we’re ready to start our multi-row queue sequence. Highlight the rows in the order that you want them to be processed. Then select ‘Actions > Job queue > Execute basic multi-row queue sequence’
That’s all there is to it! In the screenshot below you can see that our first host is in the process of rebooting and ‘waiting for host to go offline and come back online.’ The second and third hosts are queued.

Posted in Blog, General, Tutorials | Tagged reboot, sequence, update | Comments closed