Deploying a Script with Relative Instead of Absolute Paths

By Scott | Published: January 6, 2017

In order for a custom deployment to be successful, you might not be able to use absolute paths inside of a script where those paths point to a location on a remote server. This is dependent upon the particular situation, but if you’re having problems successfully deploying a script that makes calls to other scripts or executables stored on a remote server, below I will show you how to ensure success.

Example:

Imagine you have a remote server folder:

\\RemoteServer\SharedFolder\Example

The folder contains two files – MyCustomExecutable.exe and MyCustomScript.cmd:

The contents of the script are as follows. Note, the script makes a call to execute the MyCustomExecutable.exe using an absolute path to the server location where the exe file currently resides:

@ECHO OFF
ECHO *** Executing My Custom Script With Remote Server Absolute Paths ***
"\\RemoteServer\SharedFolder\Example\MyCustomExecutable.exe"

You are attempting to deploy the script using the configuration in the screenshot below, but you are not having success:

If you are having problems getting the deployment to run successfully, you have a couple of options to try:

  1. You might be able to get the deployment to execute successfully simply by modifying the ‘Remote Execution Context’ settings. In the screenshot below you can see that I have launched the ‘Remote Execution Context’ settings window directly from the deployment configuration screen. However, you can also get to the ‘Remote Execution Context’ settings by clicking ‘Tools > Settings > Remote Execution.’

    The default configuration is set to use the SYSTEM account for remote execution. This is usually the best for most situations, but one drawback to this setup is that the SYSTEM account does not have access to network resources. Since the script that gets executed on the target system is currently set to make a call to a remote server location (“\\RemoteServer\SharedFolder\Example\MyCustomExecutable.exe”), the deployment will fail because the SYSTEM account on the target computer will not be able to reach that network resource. Try running your deployment with ‘Elevated token’ or ‘Normal’ and see if you have success. If not, set the Remote Execution Context setting back to ‘SYSTEM’ and go to the next step.
  2. With a simple adjustment to your script and your BP deployment configuration you can remove any network calls so that the entire deployment executes locally on the target system.

    A. Modify your script to remove the absolute path. See below for example:

    @ECHO OFF
ECHO *** Executing My Custom Script WITHOUT Remote Server Absolute Paths ***
"MyCustomExecutable.exe"

    B. Modify your deployment configuration by ticking the box that says “Copy entire directory contents in addition to the specified file”

    C. Now when you execute the deployment, the entire folder contents of (\\RemoteServer\SharedFolder\Example) will be copied to the target systems. Then when the script is executed, since it now contains a relative path to the MyCustomExecutable.exe, it will find that file in the same temp deployment directory as the script is being executed from. The deployment will complete successfully (unless, of course, the reason for it failing in the first place was due to some other unrelated issue).

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

Remotely Install Greenshot 1.2.9.104 on Many Computers Simultaneously

By Scott | Published: December 22, 2016

Today let’s have a look at deploying Greenshot screen capture software to numerous computers simultaneously. The process is no different from other remote installations with BatchPatch. We will start by determining the appropriate installation parameters to use in order to trigger a “silent” or “quiet” installation on target computers. Next we will create the actual deployment in BatchPatch. Lastly we will execute the deployment.

  1. Download the version of Greenshot that you intend to install. In this case we are installing the latest version 1.2.9.104, downloaded from http://getgreenshot.org/downloads/
  2. As is the case with any remote software installation, the installation must be triggered to run without any user interaction required on the target computer. The reason for this is because if the installation package pops up a window on the target system, asking the user to select configuration options such as installation directory, that popup window will be hidden from the administrator on the BatchPatch computer, and the deployment will consequently hang indefinitely without ever completing. So, before we deploy Greenshot we have to determine the appropriate switch to use in our deployment configuration to make sure that the installation occurs without any user interaction. This is known as a “silent” or “quiet” installation.

    To determine the correct silent parameter, we execute the installer package at the cmd prompt with the /? switch. See screenshot below for illustration.
  3. Running the command above causes the installation package to pop up the messagebox shown in the screenshot below. We are going to use the /VERSILENT and /NORESTART parameters for our deployment.
  4. To create the deployment in BatchPatch, select the target hosts that will receive the deployment, and then select ‘Actions > Deploy > Create modify deployment’
  5. In the Deployment form, click the browse button to browse to the Greenshot-INSTALLER-1.2.9.104-RELEASE.exe that you downloaded earlier. Then type /VERYSILENT /NORESTART into the ‘Parameters’ field, just as I have done in the screenshot below. Optionally give your deployment a title and save it using the >> button.
  6. At this point you can either execute the deployment now or close the window and execute it later. I’m going to simply click the ‘Execute now’ button.
  7. Exit code 0 indicates success. Greenshot is now installed on the target system(s).

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

Exporting the BatchPatch Grid

By Scott | Published: December 14, 2016

One of the features in BatchPatch that many users overlook is the export tool. Admins frequently desire to get BatchPatch grid information into a different format so that it can be consumed by people who are not using BatchPatch, whether it be for reporting or other purposes.

For example, what if you want to prepare a simple report that shows the CPU information for a given list of computers?

  1. Start by adding the desired hosts to the BatchPatch grid. Then highlight the hosts and perform the desired action, which in this case is ‘Actions > Get information > Get CPU info’ The result should look similar to my screenshot below.
    2016-12-14-14_38_01-cpu-bps-e__20161214-batchpatch-x3
  2. For this mini-report I only want to include the actual CPU information for each host. I don’t need the information from the ‘All Messages’ column, so I’m going to hide that column by right clicking on the column header and then unchecking the ‘All Messages’ box.
    2016-12-14-14_40_08-customize-columns

    2016-12-14-14_40_31-cpu-bps-e__20161214-batchpatch-x3

  3. Now that I am displaying only the information that I’m interested in seeing in the report, I can go ahead and create the export file, which in this example will be an HTML file. Select ‘File > Export grid > Export current grid to HTML file’ and then choose a location to save the output .html file.
    2016-12-14-14_43_33
  4. You can now launch your .html report by double-clicking on it and opening it in your default browser. One of the nice things about the HTML export is that it shows the original grid with clickable elements that enable you to click on a field in the grid and immediately jump down to the corresponding location in the report. You can then use the ‘back to table’ option to jump right back to the top of the file. It’s actually a pretty convenient way to display the information, and you can get virtually any kind of information from target computers that you need whether it be a list of installed software or a list of currently logged-on users or a list of last bootup times. Even if BatchPatch does not have a built-in query for the information you desire, it’s simple to write your own query to retrieve custom information. More details on that here: how-to-hard-code-your-own-custom-commands-in-the-batchpatch-actions-menu
    2016-12-14-14_47_01-mozilla-firefox
  5. You can also export to a delimited file in case you want to later import the data into a spreadsheet or database. To do this select ‘File > Export grid > Export current grid to delimited file’
    2016-12-14-14_54_28-settings
  6. You’ll be prompted to select a custom delimiter. You have to be careful about which delimiter you select. For example, you might think to use the standard comma to create a .csv file. However, commas can appear in BatchPatch grid data, particularly if you are listing titles of Windows Updates. And if a comma appears in the grid data but is also used as a delimiter, you end up with problems with your output file. We usually like to use ‘?’ because it is generally unlikely to appear in grid data. However, you can also specify a custom multi-character delimiter, such as ‘$#$’ or ‘%%^^%%’ or whatever you like.
    2016-12-14-15_00_01-cpu-bps-e__20161214-batchpatch-x3

    I have launched the output text file in my default text editor. You can see what that looks like below.
    2016-12-14-15_03_37-e__20161214_cpu-txt-notepad
  7. So now if I want to import my file into a spreadsheet, I can do so very easily using the spreadsheet application’s import feature.
    2016-12-14-15_05_01-cpu-txt-libreoffice-calc
Posted in Blog, General, Tutorials | Tagged | Comments closed

Adding Hosts to BatchPatch from Active Directory

By Scott | Published: December 7, 2016

Even if you have been using BatchPatch for a while, you might have realized that you can import host names into a BatchPatch grid directly from Active Directory, if you desire.

In BatchPatch use the ‘File > Add hosts from directory’ option.

2016-12-07-17_41_52-file_add_hosts_from_directory

In most cases BatchPatch will automatically detect and retrieve the defaultNamingContext so that it can bind to your Active Directory domain. However, in some environments, it’s possible that you would manually have to input the domain controller name that you wish to connect to. For the sake of this example, I am on a computer that is *not* a domain member, and so in order to connect to an Active Directory domain in BatchPatch, I am required to both specify the domain controller name as well as the credentials of a user with permission to read from the directory. In the screenshot below you can see that I’ve done exactly that.

2016-12-07-17_46_43

Once you have established the connection with Active Directory, you may browse through the tree to select computers to add to the BatchPatch grid. If you highlight a container or organizational unit (OU), BatchPatch will display all of the machine accounts (computers) that exist inside of that container or OU.

2016-12-07-17_49_42-add-hosts-from-directory

If you select only a single computer in the directory tree, then of course only that single computer will be displayed for addition to the grid.

2016-12-07-17_51_05-add-hosts-from-directory

If you tick the box in the lower left corner of the window for ‘Recursive search’ BatchPatch will find all machine accounts in the selected directory and all subdirectories.

2016-12-07-17_53_09-add-hosts-from-directory

If you would like to add a computer (or multiple computers) to the BatchPatch grid, first you click the >> button to move them to your staging list.

2016-12-07-17_55_01-add-hosts-from-directory

Next you have two additional options that you may select, if desired, before clicking ‘Add to grid.’ The first option ‘Import description field’ allows you to automatically import the description field for the computer from Active Directory into the ‘Description’ column in BatchPatch. The second option ‘Append DNS suffix to hosts’ allows you to automatically append the specified DNS suffix to the host name before adding the host name to the destination grid. So, for example, if you have host ‘Computer1’ on domain ‘MyCompany.com,’ and you work in an environment where multiple domains exist, such that your DNS settings require you to generally use fully qualified names, then you can simply tick the ‘Append DNS suffix to hosts’ box and add the domain suffix that you wish to append. Then when you click ‘Add to grid’ all hosts will be added with the suffix you specified. So in the above-mentioned example, we would see ‘Computer1.MyCompany.com’ get added to the grid instead of just ‘Computer1.’

When you are ready to add all of your hosts to the grid, simply click ‘Add to grid.’ All hosts that are displayed in ‘Computers to add to BatchPatch grid’ list will be added to the BatchPatch grid.

2016-12-07-18_01_52-add-hosts-from-directory

2016-12-07-18_01_58-new-1-batchpatch-x3

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

BatchPatch Troubleshooting Guide

By Scott | Published: November 23, 2016

We designed BatchPatch to be as easy to use as possible. However, of course it’s still possible to encounter problems or run into unexpected situations. The goal of this guide is to help direct your troubleshooting efforts, so that you can narrow down the potential causes of whatever issue it is that you’re experiencing.

  1. The first order of business is to make sure your environment is setup properly. Please review all of the steps in the ‘Getting Started‘ page, and make sure your environment has been configured properly to work with BatchPatch.

  2. Next, see if the issue that you are encountering is addressed here or here.

  3. If you’re still having an issue, let’s break down what BatchPatch tries to accomplish, so that you can determine where in the process your issue is occurring.

    ‘Get information’ actions

    Most ‘Get information’ commands, such as ‘Get last boot time’, ‘Get MAC address’, ‘Get computer model’, ‘Get CPU info’, and ‘Get OS version’ are retrieved by BatchPatch using simple WMI queries. In order for a WMI query to be executed successfully, the target computer must be able to receive and process it. This means the firewall has to be configured to allow WMI queries to pass through it, and the target computer has to have WMI enabled, and permissions have to be set properly so that the requesting account is allowed to retrieve the information requested. This page addresses the typical errors that one would encounter if not everything is setup properly to allow WMI queries to be processed.

    ‘Windows Update’ actions

    Most ‘Windows Update’ commands utilize a combination of WMI commands (mentioned above) as well as a remote executable (BatchPatchRemoteAgent.exe) that is executed by PsExec. The BatchPatchRemoteAgent.exe is responsible for communicating with the Windows Update Agent, in order to instruct it to search for updates, download updates, install updates etc.

    When you are having problems executing Windows Update actions through BatchPatch, here is what to look for when trying to determine specifically where the issue is occurring.

    • Make sure WMI is working first. Test a ‘Get information’ action such as ‘Get last boot time.’ If ‘Get last boot time’ is throwing an exception, then start with troubleshooting WMI setup/configuration before doing anything else.
    • If WMI is working properly and you are able to successfully run various ‘Get information’ actions such as ‘Get last boot time’ and ‘Get MAC address’, then your next step is to see if BatchPatch is successfully able to create the target computer remote working directory. In BatchPatch ‘Tools > Settings > Remote Execution’ there is a ‘Remote Working Directory’ setting, which by default is set to C:\Program Files\BatchPatch. This it the directory on the target computer that BatchPatch tries to create before it is able to execute any Windows Update actions. Please check the target computer for the existence of this directory. If the directory does not exist, then it means that BatchPatch is either not able to reach the target computer to create the directory, or BatchPatch is able to reach the computer but does not have the appropriate permissions needed to create the directory.
    • Assuming that BatchPatch has successfully created the remote working directory, the next step is to watch this folder during an attempted Windows Update action. Execute the desired action in BatchPatch such as ‘Check for available updates.’ Then monitor the remote working directory for activity. You should see ‘BatchPatchRemoteAgent.exe’ is copied to directory.
      2016-11-23-14_43_23-batchpatch
    • After ‘BatchPatchRemoteAgent.exe’ is copied to the target directory, PsExec is used to run the executable. In order to determine if PsExec is running the exe successfully, check Task Manager on the target computer for active processes. You should see ‘psexesvc.exe’ and ‘BatchPatchRemoteAgent.exe’ running on the target computer. However, please note that if you have modified the following setting in BatchPatch, then instead of seeing ‘psexesvc.exe’ you will see a process with the name that you specified in ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify a remote service name’

      2016-11-23-15_04_06-win2012r2-virtual-machine-connection

    • If you do not see ‘BatchPatchRemoteAgent.exe’ and ‘psexesvc.exe’ running on the target computer, then your next step should be to verify that PsExec is working as expected. Try running PsExec at the command line from the BatchPatch computer to the target computer *WITHOUT* using BatchPatch. For example, you could simply run the following command to see if works properly or if it throws an error: 
      PsExec \\targetComputer cmd.exe

      2016-11-23-15_21_24-__win2012r2_-cmd-exe

    • If PsExec is not working properly, then you’ll need to troubleshoot from that angle. Make sure you can ping the target computer. Make sure you can connect to the admin$ share on the target computer by going to ‘Start > run > \\targetComputer\admin$’ If you are not able to connect to the admin$ share, then you might need to take another look at your firewall and permissions: getting-started-with-batchpatch

    • Also make sure PsExec.exe is not being blocked by Windows. Right click on PsExec.exe and select ‘Properties‘ and then view the ‘General‘ tab. If you see a checkbox that says ‘Unblock‘ like in the screenshot below, check the box and click OK.

    ‘Deployment’ actions

    For troubleshooting ‘Deployment’ actions, start by making sure that ‘Windows Update’ actions are working properly (see above). You can use ‘Actions > Windows Updates > Check for available updates‘ as a test action that won’t make any changes to the target computer. If you have Windows Update actions working, then everything that is needed for Deployment actions to work is already in place. The most common problem people encounter when executing a Deployment is that they forget the silent parameter, and then the Deployment hangs indefinitely. You can read more about understanding and discovering silent parameters for Deployment actions here: understanding-and-discovering-the-silent-parameters-required-to-remotely-deploy-software-with-batchpatch

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

Removing Adobe Flash Player from Multiple Remote Computers

By Scott | Published: November 17, 2016

Last year we posted one method for removing / uninstalling Adobe Flash from multiple computers (uninstall-adobe-flash-player-from-multiple-computers), but there is another method that might be easier or work better, depending on your situation, so I’m going to explain that process below.

Adobe has a Flash player removal utility available from the following link that makes it simple to remove any Flash plugins. When you deploy that utility with BatchPatch you can quickly/easily handle numerous computers, simultaneously.

Adobe Flash Player Removal Utility

As noted on the top of the Adobe Flash Player Removal Help Page, the removal utility will not work for the Flash Player included with Microsoft Edge or Internet Explorer on Windows 8 and later or with Google Chrome on all supported operating systems. For those situations you would simply enable/disable Flash in the browser, as described here.

To remove the Adobe Flash Player Plugins using BatchPatch with the “uninstall_flash_player.exe” utility, here’s all you need to do:

  1. Highlight the desired hosts in the BatchPatch grid, and the select ‘Actions > Deploy > Create/modify deployment’
    2016-11-17-14_19_12
  2. In the deployment window you’ll need to select the file to deploy as the “uninstall_flash_player.exe” like in the below screenshot. Additionally, you must add the -uninstall parameter in order to execute this installation remotely, unattended and silently.
    2016-11-17-14_17_06-deploy-msi-msp-msu-exe-reg-vbs-bat-cmd-ps1-etc
  3. Once you have the deployment configured, you can simply go ahead an execute it by clicking ‘Execute now.’ Any host that is selected in the grid will be affected. When the deployment completes, BatchPatch will display ‘Exit Code: 0 (SUCCESS).’
    2016-11-17-14_25_04-new-1-batchpatch-x1
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

The Best Way to Patch an Isolated Network Environment

By Scott | Published: November 9, 2016

We have talked a lot about offline patch management with BatchPatch, and today will be no exception. We truly believe that BatchPatch provides the best, simplest, least expensive way to apply updates to machines on isolated networks. (We also happen to believe that BatchPatch is the best, simplest, and least expensive option for updating machines that are *not* on isolated networks!) Many organizations have at least one high-security network that is either completely offline or sometimes just minimally connected, which makes Windows Updates and patching the computers in said network much more challenging than it would otherwise be.

BatchPatch addresses the need for offline patch management of isolated networks by allowing the administrator to use an internet-connected computer to pre-download all updates that are required by computers on the offline network so that he/she can then copy the update files to the isolated network. From there BatchPatch is able to distribute the updates to all of the computers on that same offline network segment. This way the machines on the offline network do not ever have to connect to the internet nor to another online network segment. Furthermore, BatchPatch provides a couple of different methods for handling offline patch management, such that if you are not even able to remove a single text file from the offline network due to stringent security requirements, BatchPatch can still work by enabling the administrator to only move/copy files in one direction *to* the high-security network without ever having to remove any files *from* the high-security network.

The main page we have setup to discuss ‘Cached Mode’ and ‘Offline Updates’ is here: https://batchpatch.com/cached-mode-and-offline-updates

Additionally, we address offline Windows Update options in more detail here: https://batchpatch.com/offline-windows-update

If you aren’t sure about how well BatchPatch will work in your environment, the good news is that the evaluation is totally free and allows you to patch up to 4 computers, simultaneously. You can download it from https://batchpatch.com/download

If you have any questions about the application, licensing, pricing, trials, quotes, invoices, POs etc, please reach out to us through the contact form at https://batchpatch.com/contact

2016-11-09-17_54_45-settings

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

How to Automate Windows Updates with Multiple Patch and Reboot Cycles

By Scott | Published: October 18, 2016

Anyone who has worked with Windows Updates for any length of time has encountered the situation where after downloading/installing updates and rebooting, all of a sudden after the computer comes back online there are new updates available, even though all available updates were installed before the reboot. This seems to be an unavoidable fact with Windows Updates some months where an update simply will not be “available” until after certain other updates have been installed. And while it certainly isn’t a big deal to just install the newly available updates and reboot a second time when you’re dealing with a single computer, if you’re dealing with a lot of computers or you have a brief maintenance window to work with, things tend to get complicated very quickly. Soon you find yourself at the end of the maintenance window with machines offline that need to be online, and confusion about which machines have been rebooted twice and which ones have only been rebooted once etc. Wouldn’t it be nice if you could have a one-click way to launch a cycle of multiple updates and reboots across many computers, simultaneously? BatchPatch to the rescue! Here’s how you can use BatchPatch to automate a sequence of multiple update plus reboot cycles.

BatchPatch’s Job Queue Feature:

In BatchPatch we select the hosts that we want to update, and then we select ‘Actions > Job Queue > Create/modify job queue’

One option for a typical update + reboot cycle is illustrated in the screenshot below. The steps are as follows:

1. Download and install updates + reboot always
2. Wait 10 minutes
3. Download and install updates + reboot if required

2016-10-18-16_00_35

A second option for a typical update + reboot cycle is illustrated in the following screenshot. In this job queue we utilize the BatchPatch built-in option to ‘Wait for host to go offline and come back online.’ A host is determined to be offline when X pings timeout/fail, where X is an integer defined under ‘Tools > Settings > Grid preferences > Hosts are considered offline after X ping timeouts.’ The default value for this setting is 3, and that works great for physical computers. We recommend a value of 2 for virtual machines that are able to reboot extremely quickly. A host is determined to be back online after it both responds to pings AND also responds to WMI queries.

The steps are as follows:

1. Download and install updates + reboot always
2. Wait for host to go offline and come back online
3. Wait 1 minute
4. Download and install updates + reboot if required

2016-10-18-16_00_52

If you want, you can add even more steps to the job queue, whether that be for an additional update + reboot cycle or if you need to execute a custom script or retrieve some info from host computers. However, for our purposes, 2 cycles of update + reboot is sufficient.

Once you have a job queue created you execute it right away for the selected hosts in the grid using the ‘Execute now’ button, or you can save the queue using the ‘>>’ button for later execution. Once a queue has been saved, then to execute it for a given set of hosts/rows in a grid, you would simply highlight the hosts and select ‘Actions > Job Queue > Execute saved job queues > *Your job queue name*’

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

The Best Way to Patch an Isolated Network

By Scott | Published: October 11, 2016

One of our goals with BatchPatch is for it to be the best tool for patching isolated networks. We think it provides the simplest method for applying Windows Updates in bulk to computers on segregated and/or offline networks. When dealing with isolated/segregated networks, there are typically some additional challenges involved in keeping computers up to date. The computers typically will not have internet access, and usually the computers will also not have physical connectivity to other networks. This ‘air gap’ presents a significant obstacle for the administrators, especially in cases where the segregated network has very strict rules due to its high-security designation. After all, the purpose for an air-gapped network is usually to increase the overall security of the connected computers. On the one hand, keeping computers patched and up to date is paramount to maintaining security of the network, but other hand, how do you patch the computers if they are not connected to anything?

We describe, in detail, all of the cached mode and offline update options in BatchPatch at this link: Cached Mode and Offline Updates

2016-10-11-15_54_31

There are two basic options that BatchPatch provides for patching an air-gapped network of computers

Option A: On an internet-connected computer, pre-download *all* Windows Update security updates for the operating systems that you plan to patch. Then bring all of those updates on a hard drive to the offline network and use BatchPatch to apply them to all of the computers.

The advantage of option A is that files never need to be transferred from the offline network to an online network. In high-security environments this might be particularly useful because change-management requirements might make it very difficult or perhaps impossible to remove files from the offline, high-security network.

The disadvantage of option A is that you have to download *all* available security updates for a given OS, which might take some time.

Step-by-step tutorial for option A: Patching an isolated environment with strict security rules

Option B: First run BatchPatch on the offline network so that it can produce a report of all the security updates that are needed by computers. Take the report to a computer that has internet access, and then use BatchPatch to download the needed updates from the report. Then bring the downloaded updates from the internet-connected computer to the offline network where you can then use BatchPatch to apply those updates to the computers that require them.

The advantage to option B is that you will only need to download the exact/specific security updates that are required by computers on the offline network. This might be a significant time saver over option A.

The disadvantage to option B is that it requires taking a simple BatchPatch text file report from the offline network to an internet-connected computer. Security restrictions and/or change-management protocol may make this a very difficult or impossible task in some environments.

Step-by-step tutorial for option B: Patching an isolated environment with less stringent security rules

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

Automated Windows Patching

By Scott | Published: September 28, 2016

Today I’d like to go over the automation options that BatchPatch provides for downloading and installing Windows updates on multiple computers.

Update + Reboot Cycle

First let’s look at the ‘Update + Reboot Cycle’ feature, which is available on the ‘Actions’ menu. Select ‘Actions > Windows updates > Update + reboot cycle > Modify default cycle settings’
2016-09-28-19_53_18-program-manager

You’ll be presented with a warning that informs you that you’re about to modify a global setting.
2016-09-28-19_56_14-important-notification
Click OK to proceed. The window that appears allows you to modify the default settings for the ‘Update + reboot cycle’ action. Essentially this is just a simplified version of our ‘Job Queue’ feature. In addition to being simplified, it’s also a global setting, whereas the normal ‘Job Queue’ is configured on a per-row basis. For most users in most situations we actually recommend the job queue because it provides the most complete control. We’ll go over the ‘Job Queue’ further below, so you may skip straight to that section if you prefer.

2016-09-28-20_02_03-update-reboot-cycle-settings-these-settings-are-saved-and-apply-to-all-rows

We can modify the default cycle to be whatever we desire, but a simple cycle that works for most situations is just 3 steps:

*Download and install updates + reboot always
*Wait for host to go offline and come back online
*Download and install updates + reboot if required

Click OK to save the default cycle settings. Next you can execute the cycle for hosts that have been selected in the grid by selecting the desired hosts and then click ‘Actions > Windows updates > Update + reboot cycle > Execute cycle’. You’ll be presented with a confirmation dialog that explains what you’re about to execute on the selected hosts in the grid.
2016-09-28-20_06_42-confirm-update-plus-reboot-cycle-execution

Click OK to execute the cycle on the highlighted hosts. That’s all there is to it.

Job Queue

The job queue is the more advanced version of the update + reboot cycle. It has more options, it enables you to save your queues, and it allows you to apply queues on a per-row basis, so you can have one separate job queue for each row/host, or you can have one job queue for all hosts, or one queue for some hosts and another queue for other hosts and so on. To launch the job queue configuration window, select ‘Actions > Job Queue > Create / modify job queue’
2016-09-28-20_11_43-job-queue

In this form you can create a custom job queue and save it or apply it directly to a given row or set of rows in the BatchPatch grid. You can add your own custom remote command or deployments to the queue, along with numerous built-in actions. In the screenshot below I’ve created a simple queue, and then I’ve gone ahead and saved it by using the ‘>>’ button.

2016-09-28-20_14_59-job-queue

You can also execute the queue directly right now on the currently selected rows by using the ‘Execute now’ button, but in this case since I’ve saved the queue, I’m now going to close the Job Queue window and then execute the queue from the BP Actions menu instead. When I click ‘Actions > Job queue > Execute saved job queues,’ my own queue now appears under the title I gave it, ‘Standard Queue for Update + Reboot Cycle.’ I can select that menu item to execute that queue on the currently selected rows in the grid.

2016-09-28-20_26_57-settings

Task Scheduler

We can now bring together these automation options with the task scheduler, which lets us execute the ‘Job Queue’ or ‘Update + reboot cycle’ at a scheduled time/day.

I’ve selected ‘Actions > Task scheduler > Create/modify scheduled task.’ In the screenshot below you can see that I have selected the Job Queue that I created above. I can click OK to apply that scheduled task to each selected row.

2016-09-28-20_35_57-task-scheduler

At this point the only thing left for me to do is enable the task scheduler, which I can do by clicking on the red clock icon in the upper right corner of the window. Clicking on it one time turns it green and enables it. Once enabled, any tasks that are scheduled for a future time/date will run when that time/date is reached.

2016-09-28-20_32_17-settings

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