Blog | Page 26

Protecting Sensitive Passwords in Saved BatchPatch Grid Files (.bps / .bpt)

By Scott | Published: December 1, 2015

In the November 2015 release of BatchPatch one of the cool new features is password protection with 256-bit AES encryption for your saved .bps / .bpt files. What does this mean? The contents of a .bps / .bpt file can be password encrypted such that after you have applied a password to a particular grid, when you save that grid, the contents will be encrypted on disk. Then later when you load the saved grid file into an instance of BatchPatch you will be prompted to enter the password to unlock/decrypt the file contents to be displayed in the grid.

Why might an administrator want to use this feature? In particular, if you are storing sensitive passwords in any of your .bps / .bpt grid files, this feature might be important to you. In BatchPatch if you’re using ‘Integrated Security,’ which means that you are launching the BatchPatch.exe in the context of a user that has been granted local administrator privileges on target computers, then you probably do not have any passwords stored in a grid or a saved .bps / .bpt file. However, for those of you who are using ‘Alternate Credentials’ in BatchPatch, which means that you have specified particular logon credentials for a given row/host or set of row(s)/host(s), this new feature might be just what you were looking for to increase overall security.

To add password protection to a grid simply click on ‘File > Password protect .bps/.bpt file contents…’ You will be presented with a dialog that enables you to apply a password to that grid, and then you’ll be prompted to save the grid.

To maximize security we recommend an absolute minimum of 12 characters for your password, though even longer is better! A good password should also contain a mix of uppercase letters, lowercase letters, numbers, and non-alphanumeric characters. A long, non-dictionary, high-entropy password is of paramount importance to prevent a brute-force (password-guessing) attack from being successful. Even though the encryption itself can’t be “cracked” per se, your password *can* be guessed, especially when it’s short and low-entropy. And when you’re using one password to protect a file that contains many other passwords, we strongly recommend using a very long, unpredictable password.

To further increase security and make a brute-force (password-guessing) attack even more difficult and time consuming, you may modify/increase the number of iterations used during key derivation (PBKDF2) under ‘Tools > Settings > PBKDF2 iterations.’

Posted in Blog, General, Tutorials | Tagged encryption, password protection | Comments closed

Remotely Remove a Problematic Windows Update from Multiple Computers

By Scott | Published: November 18, 2015

It seems to be happening more and more frequently these days. Microsoft releases a Windows Update that causes some type of problem for users, and even though you are a stellar sysadmin with a solid process in place for testing Windows Updates before deploying them to your general user population, your thorough testing process somehow doesn’t reveal the issue. As such, you end up deploying the problematic update to all of your users’ computers, and now you want to remove / uninstall it as quickly as possible while you wait for Microsoft to publish a new, fixed version of the update. Don’t fret! With BatchPatch you can rectify the issue easily and quickly.

Uninstall individual Windows Updates from Newer Operating Systems (Windows Vista/7/8/10/2008/2012):

The process is actually very simple. Highlight the desired hosts in the grid and select ‘Actions > Windows Updates > Uninstall individual update’
In the dialog that is presented, enter the KB number of the update you want to uninstall. Then click OK.
On the confirmation dialog that appears, click ‘OK’ to execute the update removal process. That’s all there is to it.

Uninstall individual Windows Updates from Older Operating Systems (Windows XP/2003):

On Windows XP and 2003 we have to use a different method because they do not support WUSA.exe. Highlight hosts in the grid and then select ‘Actions > Execute remote process/command > Create/modify remote command 1’
Input the following command, but substitute your KB ID number for the one used in the code line below:
C:\WINDOWS\$NtUninstallKB123456$\spuninst\spuninst.exe /quiet /norestart
At this point simply click ‘Execute’ to initiate the Windows Update removal process.

Posted in Blog, General, Tutorials | Tagged remote windows update, remotely remove windows updates, remove windows update, uninstall windows update | Comments closed

Initiating Tasks on Computers that are Frequently Offline

By Scott | Published: November 11, 2015

One of the challenges that administrators often face is getting things done on user computers that rarely connect to the network. For example, part of your job might be to update Java, Adobe Flash, or Adobe Reader on all of your users’ computers. Inevitably it seems that you are able to get 90% done immediately while the other 10% take many days or even weeks (sometimes months!) simply because the users aren’t in the office frequently. And then when they are in the office, you don’t learn about it quickly enough to perform the update, so they’re back on the road before you get it done! Wouldn’t it be nice if you could just setup a job that would automatically run the update the moment the traveling users come back to the office and attach their computers to the network? Fortunately with BatchPatch this is actually very easy to accomplish.

In the BatchPatch task scheduler there is an option to “Run task immediately upon detecting target computer online.”

This scheduled task option works exactly as it sounds. It’s as simple as selecting any BatchPatch task such as downloading/installing Windows updates, deploying software, or executing a custom script or job queue, and then ticking the box to “Run task immediately upon detecting computer online.” BatchPatch will constantly monitor the network for the desired computer. As soon as BatchPatch detects that the computer is online, the task is executed. Below is a step-by-step tutorial.

Select the desired hosts in the BatchPatch grid, and then select ‘Actions > Task Scheduler > Create/modify scheduled task.’
In the task scheduler window select from the drop-down menu the desired task. In this case I’m going to choose a previously saved software deployment task that installs 7-zip (any deployment that you create in the ‘Actions > Deploy > Create/modify deployment’ window can be saved in that same interface).
Make sure that you have ticked the “Run task immediately upon detecting computer online” checkbox. Then click OK.
Lastly, make sure you enable the scheduler if it isn’t already running. Do this by clicking on the smaller clock icon in the upper right portion of the BatchPatch window.
That’s all there is to it! At this point you can simply go on about your other regular duties and just check back every now and again to see which computers have come online and received the update. Or if you prefer to receive an email notification each time a machine is updated, then instead of executing the software deployment directly from the task scheduler, setup a two-step job queue with the software deployment as the first step, and an email notification as the second step. Then from the task scheduler you can just execute that job queue with the same “Run task immediately upon detecting computer online” checkbox!

Posted in Blog, General, Tutorials | Tagged disconnected, offline, software deployment | Comments closed

Install Adobe Reader Remotely to Multiple Computers

By Scott | Published: November 3, 2015

In this tutorial I will demonstrate how to deploy Adobe Reader to multiple computers on your network, simultaneously, in just a few clicks. After the installation is complete, I will then execute a remote uninstallation.

Obtain the Adobe Reader offline installer package. At the time of this writing, the following link contains the offline installer downloads. For this example I downloaded the ‘Adobe Reader 11.0 – Multilingual (MUI) installer package.’ Adobe Reader Offline Installer Download
After downloading the .zip file, extract it. In the screenshot below you can see that I’ve extracted it to AdbeRdr11000_mui_Std.

The AdbeRdr11000_mui_Std contains the following items:
Now that we have the installation files, we’re ready to create the deployment in BatchPatch. Launch BatchPatch and highlight the desired hosts that will receive the deployment. Then select ‘Actions > Deploy > Create/modify deployment.’ The deployment window will appear.
In the deployment window, type a title (if you wish to save the deployment for future use), and browse to the .msi in the AdbeRdr11000_mui_Std folder that you created earlier. Also make sure to tick the option to ‘Copy entire directory contents in addition to the specified file.’
Now that we’ve selected our deployment options, we are ready to execute the remote software installation. Click ‘Execute Now,’ and then click ‘OK’ to confirm that you want to continue.
20 seconds later we see Deployment: Exit Code: 0 (SUCCESS). That’s all there is to it!
The process for uninstalling / removing Adobe Reader is almost identical as the installation process. For the uninstallation we have to change just a single parameter in the deployment configuration to select ‘uninstall’ instead of ‘install.’
We can then execute the uninstallation, if needed. Again, I’ll just click the ‘Execute Now’ button and wait. After 14 seconds, Adobe Reader has been uninstalled from the target computer. Once again we see Deployment: Exit Code: 0 (SUCCESS).

Posted in Blog, General, Tutorials | Tagged Remote Installation, remote software deployment, remote software installation, software deployment | Comments closed

Uninstall Adobe Flash Player from Multiple Computers

By Scott | Published: October 21, 2015

In a previous posting I demonstrated how to install Adobe Flash on numerous computers, simultaneously. In this posting I will demonstrate how to remove (uninstall) Adobe Flash from numerous computers, simultaneously.

Obtain the installation media. In this example we’re going to use the .msi installer file for Flash player version 19 for plugin-based browsers that Adobe makes available because it seems to be the simplest to use. Adobe has a specific distribution license agreement, so you should review that before you proceed with deploying Adobe Flash in your environment to make sure that you are complying with their rules. The following link has more information about that: Adobe Flash Player Distribution.

Once you have saved the installation media to your computer, you’re ready to proceed. I’ve put the ‘install_flash_player_19_plugin.msi’ file in my E:\temp directory on the computer that is running BatchPatch. Add the desired host(s) to the grid, and then select ‘Actions > Deploy > Create/modify deployment.’

In the Deployment window that appears, browse to the .msi file to select it. Then select the radio button option for ‘uninstall.’ Optionally give the deployment a title so that you can save it for future use. That’s all there is to the setup/configuration. Pretty simple, right?

To perform the actual removal/uninstallation task, you may select ‘Execute now’ to immediately initiate the removal for all highlighted hosts in the grid. Or if you prefer, give the Deployment a title, and then save it using the ‘>>‘ button, and then close the Deployment window so that you may execute the uninstallation later. For the sake of demonstration, I’ll show you what it looks like when we save it and execute it later.

After saving the deployment and closing the Deployment window, I’m now left with my normal grid view. I select the host(s), and choose ‘Actions > Deploy > Execute saved deployments > Remove Adobe Flash 19 for Plugin-based Browsers,’ because that’s the title I gave it in the previous step. When I mouse over the saved deployment, BatchPatch displays the deployment’s configuration in a tooltip, so that I can quickly confirm that I’m selecting the desired one.

When I click ‘OK’ I am prompted with a confirmation dialog that also displays the configuration of the deployment to be executed. The key part of the configuration (see the screenshot below) is the command:
msiexec.exe /x "install_flash_player_19_plugin.msi" /q
The /x is the removal parameter for .msi packages.

I click OK to proceed with the uninstallation of Adobe Flash Player from the selected computers.

After waiting a few seconds, the deployment is complete, and the Adobe Flash Player has been removed from the selected computer(s). We see Exit Code: 0 (SUCCESS), and we know that it’s done. We can also then confirm on the target computer that the Flash Player is gone.

Posted in Blog, General, Tutorials | Tagged remove adobe flash, uninstall adobe flash | Comments closed

Remote Software Installation with BatchPatch

By Scott | Published: October 12, 2015

Today I’d like to demonstrate a silent remote software installation with BatchPatch. We’ll deploy 7-zip to the computers in our lab. Once deployed, we’ll then go ahead and remotely uninstall it too.

Remote Software Installation – Deploying 7-zip to remote computers

Select the desired target host(s) in the BatchPatch grid, and then choose ‘Actions > Deploy > Create/modify deployment’
In the ‘Deploy’ window, browse to the 7-zip installer that you previously downloaded from 7-zip.org. I did a google search to see what the silent installation parameter is for the 7-zip 32-bit .exe installer, and it’s just a /S (case-sensitive). So, you can see in the ‘Deploy’ window screenshot above, I’ve browsed to the location of the 7z920.exe, and I’ve added the /S parameter.
All we have to do is execute the deployment now by clicking the ‘Execute now’ button. BatchPatch prompts us to confirm the deployment. Click OK to proceed.
A few seconds later the ‘All Messages’ column reports ‘Deployment: Exit Code: 0 (SUCCESS),’ and we’re all done! In the screenshow below I’ve expanded the ‘All Messages’ contents so that you can see exactly what BatchPatch did.

Remote Software Installation – Uninstalling 7-zip from remote computers

For the removal / uninstallation, we don’t need to deploy any files to target computers. Instead we simply need to execute a command. In the case of a default installation, the 7-zip files will be stored in “C:\Program Files\7-zip.” Make sure you identify the correct directory in your environment. Then highlight the host and select ‘Actions > Execute remote process/command > Create/modify remote command.’
In the ‘Remote process/command’ window, add the uninstallation command exactly as follows:
"C:\Program Files\7-Zip\Uninstall.exe" /S
Click ‘Execute’ to initiate the uninstallation. Then click ‘OK’ to confirm that you want to proceed.
After a few seconds we see ‘Remote Command: Exit Code: 0 (SUCCESS)‘ to indicate that the command has been executed. We can now check the target machine to confirm that the software has been removed.

Posted in Blog, General, Tutorials | Tagged remote software installation, software depoyment | Comments closed

Configure Computers to Automatically Logon after Reboot

By Scott | Published: October 5, 2015

Windows provides a feature that enables it to automatically logon after reboot, which can sometimes be very handy in certain environments. The configuration is applied through a series of registry values, which isn’t particularly convenient to enable manually. However, BatchPatch provides a quick way to apply the settings to target computers when you want to set them to automatically logon after reboot.

The most important thing to know about the automatic logon feature in Windows is that it creates a security vulnerability. In order to automatically logon after reboot, the computer stores the username and password in the registry in plain text. In some environments, this may be an acceptable risk, especially if the logon account being used does not have access to anything that wouldn’t be publicly accessible already. In environments where the risk is not acceptable, automatic logon probably should not be used at all. However, there is also always the possibility of inserting the appropriate username and password registry values, rebooting the computer and letting it automatically logon, and then finally removing the registry values that were previously inserted.

To use BatchPatch to insert the autologon registry entries in target systems, highlight the desired host(s) and select ‘Actions > Reboot > Configure autologon > Insert autologon registry values’
The ‘Auto Logon Credentials’ window appears. Input the username and password that you want to use to automatically logon the target system(s). In the ‘Domain’ field either enter the domain name where the user account resides, or if it’s a local computer account simply untick the ‘Domain’ checkbox, and you’ll see that it will be automatically filled in with $computer. Lastly, input a value for the ‘AutoLogonCount’ field.

Note: The ‘AutoLogonCount’ value controls how many times the machine can be auto-logged-on after reboot before Windows automatically purges the username and password from the registry to prevent further automatic logons. With each restart, Windows decrements the value by 1 until it reaches 0. Note, if you set the ‘AutoLogonCount’ to 1, it will actually take 2 restarts before the credentials are automatically removed by Windows. On the first restart, Windows will automatically logon with the specified credentials. On the second reboot, Windows will remove the saved credentials from the registry and not automatically logon again. For the sake of maximum security, if you set the AutoLogonCount to 1, then you should still plan to remove the entries yourself after reboot by selecting the ‘Remove autologon registry values’ menu item in BatchPatch, unless you are OK with the username and password being stored in the registry in plain text until the following reboot. If you want the system(s) to automatically logon indefinitely, and if you aren’t concerned about the username and password being stored in plain text in the registry, then you can simply choose a very high number for the ‘AutoLogonCount’ field.
Finally, to actually insert the necessary registry values, click OK.
Once the registry values have been successfully inserted you can go ahead and initiate the reboot. You’ll see that unless you entered invalid credentials, the computer will automatically logon after the reboot completes. As mentioned above, you might now choose to remove the previously inserted registry values so that the username and password are not left stored in plain text in the target computers’ registries. To do this, highlight the computers and select ‘Actions > Reboot > Configure autologon > Remove autologon registry values’

Posted in Blog, General, Tutorials | Tagged autologon, automatic logon | Comments closed

Update Date Filtering: Skip Download / Installation of Recently Deployed Updates

By Scott | Published: September 22, 2015

In the most recent release of BatchPatch we added functionality that enables you to easily filter out recently published/approved updates during download and installation. In many environments there is a need or desire to be able to apply updates to computers only if the updates are at least X days old, where X is a value that is configured by the administrator. So, for example, it might be the case that during monthly maintenance in September the administrator desires to install all Windows Updates that were published or approved for August. And then in October the administrator would apply the updates released in September, and so on, so that the entire environment is always one month “behind” in updates that have been released. You can now do this using BatchPatch without adding any extra work.

You can see the setting called ‘Update Date Filtering’ under Tools > Settings > Windows Update in the screenshot below:

This filter instructs BatchPatch to compare the current date to the LastDeploymentChangeTime property of each update. The LastDeploymentChangeTime property is printed as a date (yyyy-MM-dd) next to each updated listed in the BatchPatch.log file. You can see this easily in the ‘Remote Agent Log’ column when performing a check for available updates in BatchPatch. In the below screenshot I’ve displayed the ‘Remote Agent Log’ column with the middle-click field viewer. For the sake of this tutorial I circled the date entries in green.

Important note about LastDeploymentChangeTime:
***When updates are obtained from ‘Windows Update’ or ‘Microsoft Update,’ the LastDeploymentChangeTime property is equivalent to the date the update was published by Microsoft. However, when updates are obtained from WSUS, the LastDeploymentChangeTime property is equivalent to the date the update was approved in WSUS.***

So, when you set the ‘Update Date Filter’ value to something greater than 0, BatchPatch will only download/install updates that were published / approved at least X days ago, where X is the value that you’ve input. For example, if you set this value to 30, updates that were published / approved any time between today and 29 days ago will *not* be installed by BatchPatch. Only updates that were published / approved 30 or more days ago will be installed. Once the setting has been saved, there is nothing else special that needs to be done. You would simply initiate the regular download and/or installation of Windows Updates using one of the options on the BatchPatch ‘Actions > Windows Updates’ menu, such as “Download and install updates + reboot if required.” This action will initiate the normal download/install process on selected computers, but updates will only be installed if they were deployed/approved more than 29 days ago.

Posted in Blog, General, Tutorials | Tagged date filters, Windows Updates | Comments closed

Executing PowerShell Scripts and Commands on Many Remote Computers

By Scott | Published: September 14, 2015

One of the things that BatchPatch does very well is remote script execution on many computers all at the same time. The ability to remotely execute a single script on numerous computers, simultaneously, with just a few clicks, is one of the awesome features of BatchPatch. No administrator wants to repeat a single process over and over on many computers. What about when the script you want to execute is written in PowerShell? How do you go about executing that single PowerShell script on all of your networked computers?

First, before you try to execute a single PowerShell script on numerous computer, you need to make sure that the script at least executes successfully on a single computer. One of the annoyances with PowerShell is that if you don’t have the same version of PowerShell on your computer, you might find that the syntax of certain portions of your scripts might only work on version 3 of PowerShell, which would obviously be a problem if some or many of computers are currently only on version 2 of PowerShell.

The first thing you’ll want to do is check to see which version of PowerShell is installed on your target systems. You can use the following PowerShell command to get the version information:

$PSVersionTable.PSVersion

If you want to use BatchPatch to check the version of PowerShell on all of your target systems, here’s what to do.

Highlight the target hosts in BatchPatch, and then select ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)

In the command field we type or paste the following command exactly as it is written below:

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$PSVersionTable.PSVersion"

Note, if you think you might want to re-use the same command in BatchPatch more than once, then feel free to add the command to ‘Actions > Execute remote process/command > Create/modify remote commands (logged output), which will allow you to “permanently” hard-code any commands into the BatchPatch menu.
Click ‘execute’ to run the command on the selected hosts. You can see the results below from my quick run. I have one computer with version 3 of PowerShell, while the other still has version 2.
Now, let’s say you want to run a multi-line PowerShell script on your target machines. After verifying the PowerShell version that you have running on target computers and after making sure that your desired script works properly on at least one computer from each group (just to make sure that the syntax of your PowerShell script works on all versions of PowerShell being used in your environment, you now have two options for executing it from BatchPatch.
One option is to use the BatchPatch deployment feature. Please review this tutorial: Executing Powershell Commands On Remote Computers With BatchPatch You may also review the Software Deployment page to learn about BatchPatch deployments, in general. In this case instead of deploying a software package or an update, we want to deploy a PowerShell script. So, we would highlight the desired target computers, and then we’d select ‘Actions > Deploy > Create/modify deployment.’ In the window that appears we would select the script to be deployed, and then we would check the “retrieve console output’ if our script outputs anything to the console that we want to see. And then we can simply choose “Execute now” to execute the deployment and have BatchPatch copy the script to the target systems and subsequently execute it on each system.

A second option is to just run the script directly on target systems without doing a full deployment. In this case we would need to convert our script into the right format for it to be able to run in a single line. So, for example, let’s make up a very simple multi-line script to use for this example.
$version = $PSVersionTable.PSVersion $version | format-list
In order to execute this using the ‘Remote process/command’ feature of BatchPatch, we have to convert it into a single-line for execution. In PowerShell the semi-colon is used to separate multiple lines into a single line. So, in this case we would follow the same example that was given higher up in this tutorial, but note that this time we substitute in the above 2-line script.
Highlight the target hosts in BatchPatch, and then select ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)

In the command field we type or paste the following command exactly as it is written below:

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$version = $PSVersionTable.PSVersion; $version | format-list"

In the results screenshot below you can see our 2-line script was successful, and now we see our version outputted in list format.

Posted in Blog, General, Tutorials | Tagged powershell, remote powershell execution | Comments closed

Using the Job Queue in BatchPatch for Multi-Step Execution

By Scott | Published: September 8, 2015

The ‘Job Queue’ feature lets you line up a sequence of multiple actions to execute on a target host. There are many different situations where you might want to execute a sequence of actions on a given host (or set of hosts). For example, maybe you want to string together multiple software deployments into a single click action. Or perhaps you want to create an update and reboot cycle that can be used to trigger your computers to run Windows Update, then reboot, then wait a few minutes, then run the update and reboot again, and so on. Or perhaps you want to have a single click action that will execute a script, then execute the update+reboot process, then execute another script. All of these examples (plus many more) are possible with the Job Queue. It’s extremely simple to operate. Here’s how it works:

Select the host(s) that you want to include in the job queue execution, and then click on Actions > Job Queue > Create/modify job queue
In the Job Queue window that appears you can either select a previously saved Job Queue, or you can create a new one. To select a previously saved queue, double-click the previously saved queue in the ‘Saved Queues’ grid. Or highlight the saved queue and use the ‘<<' button to load it. Once loaded, you can modify it however you like. However, if you want to create a new queue, you can simply double-click on each action you want to be included in the queue, one at a time. Or you can highlight each action one at a time, and use the '>‘ button to add that action to the queue. In the screenshot below you can see that I’ve created a simple queue that does the following:
A. Wait for host to have zero logged-on users
B. Download and install updates + reboot always
C. Wait for host to go offline and come back online
D. Wait 3 minutes
E. Download and install updates + reboot always
F. Wait for host to go offline and come back online
G. Wait 3 minutes
H. Start stopped automatic services
Now that the queue has been created, we have the option of either saving it or running it without saving it. If we just want to run it now without saving it, we can use the ‘Execute now’ button. If we want to apply the queue to the selected hosts to run later, we can use the ‘Apply queue’ button. Once a queue has been applied to a row/host, it can be executed later from the actions menu by selecting the hosts and choosing ‘Actions > Job queue > Execute job queue.’ However, we also have the option of saving the queue, which we do by adding a Queue Title and then using the ‘>>’ button to save it. Once a queue has been saved, it can be run at any time directly from the actions menu by selecting ‘Actions > Job Queue > Execute saved job queues > Title of job queue to be executed’

That’s all there is to it. When we execute the job queue, each action that was included in the list will be executed sequentially on the host(s) selected. We could also execute a job queue from within a scheduled task, so that it’s launched on a particular date and time, even if we are not in front of the BatchPatch window at the time. Or, if you need to execute a sequence of actions/tasks that involves multiple hosts in the same sequence, please have a look at the advanced multi-row queue sequence, which allows you to coordinate a sequence of actions across multiple hosts, with dependencies such as a particular reboot/shutdown order for a given environment.

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