Remotely Install Java 8 on Numerous Computers Simultaneously

By Scott | Published: August 3, 2016

It looks like the team working on Java has made it easier, finally, to perform offline installations of their software. The tutorial below takes advantage of the Java offline installer to deploy Java 8 Update 101 using BatchPatch. Note, we have an older tutorial on our site posted for deploying Java version 7 to multiple computers. However, it looks like now with the offline installer you should just be able to follow this new tutorial below, even if you are deploying an older version of Java.

Download the offline Java installer for Windows. At the time of this writing, the Java offline installer for Windows is available from here: https://www.java.com/en/download/manual.jsp. Make sure to get the correct version for your target OS (x64 vs x86). For this tutorial I have downloaded the file titled Windows Offline (64-bit) from their site.
In BatchPatch, create the deployment. Go to ‘Actions > Deploy > Create/modify deployment’
In the deployment window, I’ve given a title to the deployment, and I have selected the jre-8u101-windows-x64.exe that I downloaded a moment ago. Additionally, I have added the following command line parameters
/s WEB_JAVA=0
The /s tells the installer to work silently, without user interaction. This is always necessary when using BatchPatch to perform the installation. If the installer on the target computer requires user interaction, then the deployment will appear to hang indefinitely without ever completing. So, in order to perform a remote installation, we always use the silent installation parameter for the installer package. In this case that parameter is /s. The second parameter that we’re using is WEB_JAVA=0, which tells the installer to configure the Java installation to NOT be available to web browsers.

Unless you have a very strong reason to enable Java in your web browsers, it is highly recommended to disable it for the sake of protecting your computers. Java enabled in the browser has been a major vector for delivering malware in the past decade, so it’s much safer to keep it disabled.

You can see all of the available command line installer options here: https://www.java.com/en/download/help/silent_install.xml
Before proceeding to install Java, one important thing to keep in mind is that the Java installer typically needs web browsers to be closed on the target computers. Failing to close any web browsers before installing or uninstalling Java could cause the process to hang or not complete or it might simply require a reboot in order to complete the process. Consider killing all browser sessions with Actions > Services/Processes > Kill specific running process by name to kill firefox.exe, chrome.exe, and iexplore.exe on target computers.

At this point we’re pretty much ready to execute the deployment. If you already have your target computers added to the grid, you can simply highlight them and choose the option to ‘Execute now.’ In my case, I haven’t yet added any hosts to the grid. So instead I’m going to save the deployment using the double-arrow button >>. When you save a deployment it appears in the ‘Saved Deployments’ grid.
I have now added my target host to the grid. I will execute the deployment by selecting my target host(s), and then choosing ‘Actions > Deploy > Execute saved deployments > Java 8u101 x64’
Click OK on the deployment confirmation dialog.
About a minute later the deployment completes with Exit Code: 0 (SUCCESS).

I am able to see on my target computer that the Java installation now appears in the add/remove programs wizard:

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

Windows Patch Management without WSUS

By Scott | Published: July 25, 2016

To WSUS or not to WSUS, that is the question!

A lot of folks simply do not want to invest the time or infrastructure to setup a WSUS server, so today we’re going to talk a bit about how to use BatchPatch for Windows patch management as well as 3rd party patch management *without* using WSUS.

Before I get started, I do want to take a moment to highlight that BatchPatch is also able to work great *with* WSUS, which is is both free and easy to install and use, and can be run on a small virtual machine at minimal cost. That said, if you’re scared to use WSUS simply because you think it’s going to add complexity to your life, don’t worry. It truly is quick, easy, and painless to get up and running. We have a WSUS setup tutorial posted here if you need assistance: How to Setup a New WSUS Server from Scratch on Windows Server 2012 R2

For those of you looking for a patch management solution that does not rely on WSUS, BatchPatch works fantastically as a stand-alone alternative to or replacement for WSUS…

First let me acknowledge that there are always people out there who will say “Don’t bother with a third-party Windows Update patch management solution when you can just use group policy to download and install updates on computers.” However, what these people tend to fail to realize is that in many environments, this kind of methodology simply doesn’t provide an acceptable level of control and monitoring of the process. If you are responsible for an environment where uptime of your servers simply *isn’t* important, then group policy alone might be sufficient. However, if you manage critical servers that cannot be down or offline outside of scheduled maintenance windows, then you will inevitably get into trouble if you try to rely on just group policy alone, especially if your maintenance windows are small. There are a few reasons why this is the case, which I’ll get into momentarily. Ultimately the decision is always yours to make, of course, but do understand that regardless of specific requirements, a patch management tool such as BatchPatch was designed specifically to save you a massive amount of time on systems maintenance, while also minimizing pain and effort. Efficiency is the name of the game… and we all know time is money.

The problem with relying on only group policy to handle your entire download, install, and reboot process for Windows Updates

If you’re relying on group policy alone to download, install, and then reboot your critical servers, you cannot monitor the process in real-time. When dealing with any number of servers beyond just a handful, you’re going to need and want to be able to watch the process in real-time to ensure that all applicable updates are successfully installed, that all servers are properly rebooted, and that all servers come back online within your maintenance window and start hosting whatever services they are responsible for hosting. If you don’t have a way to monitor this in real-time, then you are stuck with the following potential issues:

Some updates fail to install: In this case, to track down which updates failed to install on which servers is not only difficult to determine quickly, but it also becomes increasingly likely that your maintenance window will end before you find and resolve all the failed update installations, leaving your servers potentially vulnerable until the next maintenance window.

The server hangs during reboot either on its way down or on its way back up: If the server hangs during shutdown, then you’ll probably never discover it during your maintenance window. The updates therefore will never be applied completely, and your server will be in a potentially unstable and/or vulnerable state until the next maintenance window. If the server hangs after shutdown but before coming back online, then whatever services it’s hosting will be offline. Since you probably shut off your server alerts during the maintenance window, you won’t learn that the server is offline until the window ends. At that point you’ll be scrambling to get the server back online after the maintenance window is already over. Clearly this is *not* good for service level agreements (SLAs).

Services fail to start after reboot: Since you will likely have your alert system disabled during the maintenance window, you won’t discover that critical services never started on particular servers until the maintenance window ends, which again is simply not good for SLAs.

Knowing the download/install/reboot status of any given server during the maintenance window is near-impossible: Without real-time monitoring, you simply can’t know/tell what the status of servers are during the maintenance window.

On-Demand Download, Installation, and Monitoring of Windows Updates and Reboots on Numerous Computers

Scenario 1:

BatchPatch Default Mode – No Caching (All computers have access to the internet)

In it’s default configuration, you can use BatchPatch to easily manage the download and installation of Windows Updates on target computers. In this out-of-the-box configuration BatchPatch uses Microsoft’s public Windows Update server to first determine which updates are available to install on each target computer, and then to download and install the applicable updates on each machine, ending with a reboot if required in order to complete the installation process. The whole sequence can be initiated from and monitored by the BatchPatch console with just a single click.

Using BatchPatch To Remotely Install Windows Updates

Scenario 2:

BatchPatch Cached Mode (All computers have access to the internet)

In the online cached-mode configuration, BatchPatch still uses Microsoft’s public Windows Update server to determine which updates are available to install on each target computer. However, instead of each target computer downloading its own copy of any needed / available updates, BatchPatch downloads all updates just one time to a single local repository, and then from there it distributes copies of the updates to target computers. Cached-mode can therefore reduce overall bandwidth usage to the internet, though local network bandwidth usage might be increased.

Using BatchPatch In Cached Mode

Scenario 3:

BatchPatch Cached Mode + Offline Mode (The BatchPatch computer has internet access. Target computers do not have internet access but they do have connectivity to the BatchPatch computer)

In this first offline cached-mode configuration, BatchPatch does not rely on Microsoft’s public Windows Update server to determine which updates are available to install on target computers. Instead, the offline scan file (WsusScn2.cab) that Microsoft publishes each month is downloaded by BatchPatch and used for offline scanning to determine which updates are needed by computers when those computers are not able to access Microsoft’s public Windows Update server.

Using BatchPatch In Offline Mode When BatchPatch Has Internet Access

Scenario 4:

BatchPatch Cached Mode + Offline Mode (Target computers do not have access to the internet, but administrators are able/allowed to transfer or copy files from this network to another network that has access to the internet. BatchPatch is run in two separate instances – one instance on a computer that has internet access in order to obtain updates, and one instance on the offline network in order to deploy the updates to target computers)

In this second offline cached-mode configuration, BatchPatch does not rely on Microsoft’s public Windows Update server to determine which updates are available to install on target computers. Instead, the offline scan file (WsusScn2.cab) that Microsoft publishes each month is downloaded by BatchPatch and used for offline scanning to determine which updates are needed by computers when those computers are not able to access Microsoft’s public Windows Update server.

Using BatchPatch In Offline Mode When BatchPatch Does Not Have Internet Access

Scenario 5:

BatchPatch Cached Mode + Offline Mode (Target computers do not have access to the internet. These computers are connected to a high-security network with strict rules that disallow administrators and users from transferring or copying any files from the high-security network to a lower-security network. BatchPatch is run in two separate instances – one instance on a computer that has internet access in order to obtain updates, and one instance on the offline network in order to deploy the updates to target computers)

In this third offline cached-mode configuration, BatchPatch does not rely on Microsoft’s public Windows Update server to determine which updates are available to install on target computers. Instead, *all* available updates for a given operating system may be downloaded in advance by the administrator. Once pre-downloaded, the update may then be moved to a high-security network for subsequent deployment to computers on that network.

Downloading Windows Updates for Distribution to Offline Computers on High-Security Networks

Posted in Blog, General, Tutorials | Tagged offline windows updates, patch management, Windows Updates, WSUS | Comments closed

How to Setup a New WSUS Server from Scratch on Windows Server 2012 R2

By Scott | Published: July 19, 2016

We are starting with a brand new, unmodified, stand-alone installation of Windows 2012 R2.

In the Server Manager, click on ‘Add roles and features.’
The ‘Add Roles and Features Wizard’ is presented. Click ‘Next.’
For the ‘Installation Type’ we’ll select ‘Role-based or feature-based installation.’
For ‘Server Selection’ I’ve selected the server the local machine..
In the ‘Server Roles’ screen, scroll to the bottom and select ‘Windows Server Update Services.’ This will immediately bring up a new window, describing that other features and services are required to be installed. Click ‘Add features’ on this window, and then click ‘Next’ on the remaining window.
For ‘Features’ simply click ‘Next.’
On the ‘WSUS’ window, click ‘Next.’
For ‘Role Services’ we are once again going to leave the defaults as-is and click ‘Next.’
For the ‘Content’ screen we need to enter a local directory to keep all of the WSUS content that is downloaded. On my server I’ve selected C:\WSUS. Normally I would use a drive that doesn’t also contain the OS, but for the sake of this tutorial I’m using a virtual machine with only a single drive. Make sure that whatever location you specify has plenty of free space. In this window Microsoft is officially recommending to have at least 6GB of free space, but I’d say shoot for a minimum of 30GB free space, otherwise you’ll end up running out soon and need to do cleanup. Since disk space is relatively cheap these days, it makes more sense to provide plenty of room, so that you have less disk space maintenance to deal with in the future.
On the ‘Web Server Role (IIS)’ screen, click ‘Next.’
On the ‘Role Services’ screen, leave the defaults as-is and click ‘Next.’
On the ‘Confirmation’ screen I have checked the box to ‘Restart the destination server automatically if required.’ Click ‘Yes’ to confirm automatic restarts.
Finally click ‘Install’ to proceed with the WSUS installation. The WSUS server along with all required services and features will be installed.
The installation only took about a minute on my lab machine. Next click on ‘Tools > Windows Server Update Services’ in the ‘Server Manager’ window. You will be prompted to complete some post-installation configuration tasks.
We are prompted to ‘Complete WSUS Installation’ and choose whether or not to store updates locally. If you de-select this check box, your WSUS will not download any updates. Instead, it would only be used to control which updates are approved for your target computers. However, updates would then still be downloaded by each target computer directly from Microsoft. This is rarely the desired use for a WSUS server, so we recommend leaving the default as-is to ‘Store updates locally’ for most situations. Click ‘Run’ to run the post-installation task. When it completes a few seconds later, click ‘Close.’
After clicking ‘Close’ on the previous screen, the ‘Windows Server Update Services Configuration Wizard’ will be displayed. Click ‘Next’ to proceed.
Decide whether or not you would like to join the Microsoft Update Improvement Program, and the click ‘Next.’
If you already have an existing WSUS server in place, you may optionally choose to synchronize the newly installed server from an existing WSUS server. However, I expect that most people following this tutorial will want to synchronize from Microsoft Update. Select your desired source, and then click ‘Next.’
If your environment requires a proxy server to access the internet, then you can configure the proxy server settings. If no proxy, simply click ‘Next.’
Click ‘Start Connecting’ to continue. This process might take a little while to complete. When it’s done, click ‘Next.’
Choose your desired languages, and then click ‘Next.’
Choose your desired products, and then click ‘Next.’ You can always add more (or remove) later, so start with only the ones that you are sure you need, like the OS updates for whatever operating systems you currently have deployed to target computers.
Choose your desired classifications, and then click ‘Next.’ The default values are just ‘Critical,’ ‘Definition,’ and ‘Security Updates,’ but we strongly recommend that you also include ‘Update Rollups’ and ‘Updates’ because Microsoft releases updates under these two classifications that they deem to be ‘Important.’

IMPORTANT: Do not select ‘Upgrades’ until after you have installed KB3095113 on your WSUS server. If you enable ‘Upgrades’ before installing KB3095113, then you will need to follow instructions here to fix your WSUS to be able to support Windows 10 feature upgrades like the 1607 anniversary update or the 1703 update.

Please also note we have noticed that if you install all applicable Windows Updates to the server prior to enabling ‘Upgrades’, then you actually will not be able to install KB3095113 because in the process of installing all applicable updates, the content of KB3095113 appears to be included in one of the other updates, and KB3095113 will not appear in your update history.
Choose a synchronization schedule. For most environments, once per day is probably sufficient.
Lastly, you may choose to begin the initial synchronization. The first synchronization always takes the longest, so at this point you can plan on checking back every hour or two to see if it has completed. Click ‘Finish’ to proceed.
Now that the WSUS has been configured, you’ll want to use GPO to configure your target computers to get their updates from your new WSUS. Please review the section titled Our recommended approach to using BatchPatch with WSUS on this page to learn which settings to use.

Posted in Blog, General, Tutorials | Tagged windows update, wsus server setup | Comments closed

Reviewing the Core Functionality that BatchPatch Offers

By Scott | Published: July 11, 2016

Today I’d like to review some of the core functionality that BatchPatch offers. For systems administrators who need a controlled way to install Windows Updates on many computers at the same time, while monitoring their progress, automating the reboot process, and maximizing efficiency during maintenance windows, BatchPatch can’t be beat.

BatchPatch offers an extremely simple and reliable toolset to perform the following tasks (and more):

Remote Windows Update management with or without WSUS
Remote Windows Update management for secure, offline networks in addition to online, internet-connected networks
Windows Update caching for low-bandwidth networks (WSUS alternative)
Remote software deployment
Remote script deployment and command execution
Remote reboots, shutdowns, and Wake On LAN
Multi-step execution options
Multi-computer, coordinated sequences
Scheduled tasks

Additional Resources:

Posted in Blog, General, Tutorials | Tagged remote reboot, remote shutdown, script execution, software deployment, wake on lan, Windows Updates | Comments closed

Download the Complete Windows Updates Security Repository per Operating System

By Scott | Published: June 28, 2016

In the most recent release of BatchPatch (June 2016) we added new functionality that enables administrators to download *all* Windows security updates for a given operating system. There are various reasons why someone might want or need to do this, but the most common reason that we have encountered is when computers need to be updated but they don’t have internet access, and they are members of a high-security network with strict rules that prevent admins from copying files from computers in the high-security environment to computers in a lower-security environment. At https://batchpatch.com/cached-mode-and-offline-updates we have a number of tutorials posted that explain how to update computers on offline networks.

If you simply want or need to download all of the Windows Updates security updates for a given operating system, below are simple instructions for doing that.

In BatchPatch select ‘Tools > Download offline updates repository’

In the window that appears, tick the box for each operating system that you need updates for. Additionally, select at least one language preference. Older operating systems require separate files for each language while the newer operating systems have multi-lingual files. After selecting the desired options, click OK.
Wait while BatchPatch downloads the WsusScn2.cab file from Microsoft, and then parses it to extract the relevant Windows Update download links.
After a minute or so a new window will appear showing a grid full of Windows Update download URLs and filenames.
You can sort the list and remove any updates that you don’t want to download by highlighting the desired rows and right-clicking to select the ‘Delete selected rows’ option. When you’re ready to initiate the download the process, click on ‘Download files to local cache.’

The next window that appears will allow you to control the download process.
If you plan to distribute these updates using BatchPatch, please review the various methods for doing this at https://batchpatch.com/cached-mode-and-offline-updates.

Posted in Blog, General, Tutorials | Tagged download windows updates repository, offline windows updates | Comments closed

Downloading Windows Updates for Distribution to Offline Computers on High-Security Networks

By Scott | Published: June 16, 2016

For environments with high-security networks that not only have NO access to the internet or a WSUS but also disallow copying any data from the high-security network to any other lower-security network, BatchPatch has a feature for pre-downloading some or all of the Windows Updates security updates repository from Microsoft on a computer that has internet access, so that the repository can be transferred to the high-security offline network, where updates can then be distributed to computers. This process can be performed without ever having to remove any files/data from the secure network. Files are only ever transferred from the low-security network to the high-security network.

Note, BatchPatch offers multiple methods for deploying security updates to offline computers. For more on the various ways you can use ‘cached mode’ and ‘offline mode’ please see: Cached Mode and Offline Updates

Enable cached mode first in order to activate the required menu item that will be used in the next step. Go to ‘Tools > Settings > Windows Update’ and then tick the ‘Enable cached mode’ checkbox near the bottom.
Now select ‘Tools > Download offline updates repository’
Select the products for which you would like to download updates, and select at least one language preference, and then click OK.

The WsusScn2.cab file will be downloaded from Microsoft and then parsed and filtered based on your selections.
A list of Urls for the products that you selected will be displayed in a new window. At this point you can optionally delete rows for any updates that you are not interested in downloading. Click “Download files to local cache” when you’re ready to begin the download process.
A new window will appear where you can monitor and control the download process.
Now that you have downloaded all the updates, the next step is to move the populated cache directory to a computer on the high-security offline network. Please use whatever method is appropriate for your environment in order to transfer the files from the online network to the offline network, such as a USB drive.

At this point the setup process is complete. You should have a folder full of update files on a computer that is attached to the offline network. BatchPatch should be launched with cached mode and offline mode enabled. The local update cache directory specified in Tools > Settings > Windows Update must point to the directory that contains all of the update files that you just moved. You may now proceed to update your computers. Highlight your hosts in the grid and select Actions > Windows Updates > Download and install updates + reboot if required. The target computers will now all “download” their updates from the BatchPatch computer’s local cache. I use quotation marks around “download” because what actually happens is the BatchPatch computer copies the appropriate update files to the target computers. The target computers then add these files to their Windows Update cache, and then the updates are installed.

I have included a series of screenshots below to show the whole the process. Upon completion we have the overall content logged to the ‘All Messages’ column, with detailed information in the ‘Local Agent’ and ‘Remote Agent’ logs.

The computer that is running BatchPatch will copy the most recently published WsusScn2.cab offline scan file that was downloaded in an earlier step to the target host.

BatchPatch instructs the target host to perform a search for available updates against the WsusScn2.cab file, which is why the target host does not require internet access to perform its search.

The list of available updates on the target host is copied back to the BatchPatch console. Since the updates were all previously downloaded to BatchPatch’s local cache directory, BatchPatch proceeds to copy the required updates to the target host.

After the updates have been copied to the target host, the target host must move the files to its Windows Update cache.

When the caching process completes, the installation is finally ready to be executed.

After installation, the target host is rebooted and the process is complete.

Posted in Blog, General, Tutorials | Tagged offline updates, wsus alternative, wsus offline update, wsus replacement | Comments closed

Remote Software Deployment Hangs Indefinitely – How to Resolve

By Scott | Published: June 13, 2016

One of the most common support questions we receive from customers is regarding software deployments that appear to never complete. In these situations, the remote software deployments seem to just hang forever until you eventually kill the task. Why does this happen? How do you prevent it?

It’s important to understand that remote software deployments must be executed silently/quietly on target computers. Essentially what this means is that when the deployment runs, it must not attempt to display any notifications, confirmations, or configuration dialogs.

Normally if you install software on your local computer by double-clicking on the application’s setup.exe, it pops up a dialog box that requires you to click ‘Next’ a few times before the software installation is completed. You might also be prompted to choose an installation path or some other settings and configurations for the software that is to be installed. Well, as you can imagine, if you execute a software deployment remotely, but the deployment pops up an installation configuration screen on the target computer, you won’t be able to respond to that dialog because you won’t see it appear. Not only will it not appear on the local machine that you’re using to execute the remote deployment, but it also will not appear on the target computer either. This is because the remote deployment process runs on the target computer hidden, with no visible user interface. Any confirmation dialogs or settings dialogs that are displayed by the setup package will simply never be seen. The result is that the software installation appears to hang forever without completing. This is because it’s waiting for user input, but since the dialog is hidden, no user can or will ever be able to provide the input and click ‘Next’ to complete the remote installation.

The solution is very simple, but it does require an extra step for the administrator. In order to prevent the deployment from hanging, it must be executed without ever requiring any user interaction, so that it can run to completion in a hidden remote process. Virtually all software installation packages come with a facility to run a ‘silent’ or ‘quiet’ installation. When the installation package is executed, the administrator simply needs to include the appropriate argument/parameter/switch that tells the package to execute silently/quietly.

In many cases, the silent/quiet installation parameter is simply a /S or /s or /Q or /q. However, often times the silent/quiet switch is something different, so unfortunately you cannot make any assumptions about which switch to use. In the case of the Java deployment that you see in the screenshot below, the silent parameter is simply /s.

The real question, however, is how does one determine what switch/parameter to use to execute a silent/hidden deployment? I wrote a longer, more detailed posting last year that explains exactly how to go about figuring out what the silent/quiet installation parameter is for any given software deployment.

Understanding and Discovering The Silent Parameters Required to Remotely Deploy Software with BatchPatch

We also have many specific tutorials for deploying software remotely posted at the following link. You’ll find tutorials for deploying applications like Adobe Flash, Adobe AIR, Adobe Reader, 7-Zip, Skype, Firefox, Chrome etc:

Software Deployment with BatchPatch

Posted in Blog, General, Tutorials | Tagged quiet deployment, remote software deployment, silent deployment, silent parameters | Comments closed

Triggering ConfigMgr (SCCM) Client Actions Remotely

By Scott | Published: June 1, 2016

As a convenience for those of you are using SCCM in your environment, last year we added the ability to trigger SCCM client actions remotely, directly from BatchPatch. We’ve received a few questions about this topic recently, so I figured I would take a few minutes to provide some context here.

SCCM administrators sometimes need or want to initiate a certain activity on client computers at non-scheduled times. For example, maybe you need your clients to perform a ‘Software Inventory,’ and you would like to execute that action on-demand. You could certainly establish a remote connection to all of the computers in question, and then you could execute a command line task to trigger the desired process. Or you could fire up PsExec from your workstation, and then use it to remotely trigger the process on a set of target computers. However, if you are a BatchPatch user, you can initiate the process directly from BatchPatch in a single click. BatchPatch isn’t doing any special magic here. We’re simply making it quicker/easier for you to remotely trigger SCCM client actions without having to mess with any command line copy/paste.

The list of SCCM triggers available in BatchPatch are:

{00000000-0000-0000-0000-000000000001} Hardware Inventory
{00000000-0000-0000-0000-000000000002} Software Inventory
{00000000-0000-0000-0000-000000000003} Discovery Inventory
{00000000-0000-0000-0000-000000000010} File Collection
{00000000-0000-0000-0000-000000000011} IDMIF Collection
{00000000-0000-0000-0000-000000000012} Client Machine Authentication
{00000000-0000-0000-0000-000000000021} Request Machine Assignments
{00000000-0000-0000-0000-000000000022} Evaluate Machine Policies
{00000000-0000-0000-0000-000000000023} Refresh Default MP Task
{00000000-0000-0000-0000-000000000024} LS (Location Service) Refresh Locations Task
{00000000-0000-0000-0000-000000000025} LS (Location Service) Timeout Refresh Task
{00000000-0000-0000-0000-000000000026} Policy Agent Request Assignment (User)
{00000000-0000-0000-0000-000000000027} Policy Agent Evaluate Assignment (User)
{00000000-0000-0000-0000-000000000031} Software Metering Generating Usage Report
{00000000-0000-0000-0000-000000000032} Source Update Message
{00000000-0000-0000-0000-000000000037} Clearing proxy settings cache
{00000000-0000-0000-0000-000000000040} Machine Policy Agent Cleanup
{00000000-0000-0000-0000-000000000041} User Policy Agent Cleanup
{00000000-0000-0000-0000-000000000042} Policy Agent Validate Machine Policy / Assignment
{00000000-0000-0000-0000-000000000043} Policy Agent Validate User Policy / Assignment
{00000000-0000-0000-0000-000000000051} Retrying/Refreshing certificates in AD on MP
{00000000-0000-0000-0000-000000000061} Peer DP Status reporting
{00000000-0000-0000-0000-000000000062} Peer DP Pending package check schedule
{00000000-0000-0000-0000-000000000063} SUM Updates install schedule
{00000000-0000-0000-0000-000000000071} NAP action
{00000000-0000-0000-0000-000000000101} Hardware Inventory Collection Cycle
{00000000-0000-0000-0000-000000000102} Software Inventory Collection Cycle
{00000000-0000-0000-0000-000000000103} Discovery Data Collection Cycle
{00000000-0000-0000-0000-000000000104} File Collection Cycle
{00000000-0000-0000-0000-000000000105} IDMIF Collection Cycle
{00000000-0000-0000-0000-000000000106} Software Metering Usage Report Cycle
{00000000-0000-0000-0000-000000000107} Windows Installer Source List Update Cycle
{00000000-0000-0000-0000-000000000108} Software Updates Assignments Evaluation Cycle
{00000000-0000-0000-0000-000000000109} Branch Distribution Point Maintenance Task
{00000000-0000-0000-0000-000000000110} DCM policy
{00000000-0000-0000-0000-000000000111} Send Unsent State Message
{00000000-0000-0000-0000-000000000112} State System policy cache cleanout
{00000000-0000-0000-0000-000000000113} Scan by Update Source
{00000000-0000-0000-0000-000000000114} Update Store Policy
{00000000-0000-0000-0000-000000000115} State system policy bulk send high
{00000000-0000-0000-0000-000000000116} State system policy bulk send low
{00000000-0000-0000-0000-000000000120} AMT Status Check Policy
{00000000-0000-0000-0000-000000000121} Application manager policy action
{00000000-0000-0000-0000-000000000122} Application manager user policy action
{00000000-0000-0000-0000-000000000123} Application manager global evaluation action
{00000000-0000-0000-0000-000000000131} Power management start summarizer
{00000000-0000-0000-0000-000000000221} Endpoint deployment reevaluate
{00000000-0000-0000-0000-000000000222} Endpoint AM policy reevaluate
{00000000-0000-0000-0000-000000000223} External event detection

In BatchPatch you can see all of the triggers listed alphabetically under ‘Tools > SCCM client triggers.’

To execute a particular task, simply highlight the desired target computers in the grid, then select ‘Tools > SCCM client triggers’ and choose the desired task. In the screenshot below you can see that when I hover over a particular task, it shows the actual command that will be executed on the target host.

Posted in Blog, General, Tutorials | Tagged SCCM client triggers | Comments closed

Deploying 7-Zip 16.0.2

By Scott | Published: May 23, 2016

Today I’ll demonstrate how to deploy the latest version of 7-Zip (version 16.0.2) to multiple target computers simultaneously.

Start by obtaining the installation media. I downloaded the 64-bit installer from http://www.7-zip.org/download.html

Configure the BatchPatch deployment. Highlight the desired target hosts in the grid, and then select ‘Actions > Deployment / Create/modify deployment’. In the Deployment form configure the deployment as I have done in the screenshot below. You need to provide a title, select the path of the installer that you downloaded in the previous step, and most importantly add the /S switch to the optional ‘Parameters’ field. The /S switch is what the 7-Zip installer uses to execute a silent/quiet installation. This means that when you use the /S, no interaction from the user will be required to complete the installation. This is a requirement for any/all remote installations. Without the /S, your deployment will hang indefinitely. More on understanding silent/quiet parameters at the bottom of this page. You can see the completed deployment configuration in the screenshot below:
With the deployment form properly configured, you’re ready to execute the deployment on the target hosts that you have selected in the grid. Either click ‘Execute now’ in the deployment form, or if you prefer you may first save the deployment and then execute it later directly from ‘Actions > Deployment > Execute saved deployment > 7-Zip 16.0.2 x64’

Confirm the deployment to be executed. Click OK on the dialog that appears to confirm the action.
When the action completes a few seconds later, you’ll see ‘Exit Code: 0 (SUCCESS) to indicate that everything is finished.

IMPORTANT: In order to execute a remote installation with BatchPatch, you must first determine the proper command line switch/parameter to initiate a “silent” or “quiet” installation.

A proper silent/quiet installation will complete without any user interaction, but if you execute an installation without specifying the correct silent/quiet parameter, the hidden remote process will hang indefinitely without ever completing.

Different installation packages have different command line switches. The silent/quiet switch might be any one of the following, or something completely different, depending on how the installer was created: /S, /s, -S, -s, /silent, -silent, /Q, /q, -Q, -q, /quiet, -quiet.

More here:
Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software with BatchPatch

Posted in Blog, General, Tutorials | Tagged 7-zip, deploy software, silent parameters | Comments closed

Update + Reboot Cycle – Create a Continuous Loop to Download and Install Windows Update Plus Reboot Until there are no Applicable Updates

By Scott | Published: May 16, 2016

EDIT 20200924: The long deprecated ‘Update + Reboot Cycle’ has finally officially been removed. It was really just a limited version of the BatchPatch Job Queue, so please now use the BatchPatch Job Queue instead, which will enable you ton produce the same functionality with many more customization options. Tutorial: Update + Reboot Cycle – Create a Continuous Loop to Download and Install Windows Update Plus Reboot Until there are no Applicable Updates
—————————————-

When it comes to Windows Update, one thing that can be pretty frustrating is that after you install a set of Windows Updates on a given computer, occasionally you need to repeat the download/install/reboot process a second time in order to get *all* applicable updates installed. When all goes smoothly, the administrator download and installs updates on a computer and then reboots the computer. That’s it. If another check for available updates is performed, there are no applicable updates left to install. However, in some cases after you install all the applicable updates and reboot the computer, a subsequent check for updates reveals that there are now more/new updates available to that computer. For those sysadmins who are performing the entire process manually without the help of an application like BatchPatch, the amount of work is doubled, and the time required to perform monthly server maintenance is increased dramatically.

BatchPatch has always provided a feature to easily handle multiple update + reboot cycles, but we’ve never blogged about it before. Considering that we still regularly receive emails about this topic, I thought it would be a good time to describe how you can use BatchPatch to perform a continuous cycle to make sure that *all* applicable updates are installed, even if it requires multiple iterations of download/install/reboot.

In BatchPatch take a look under ‘Actions > Windows Updates > Update + reboot cycle > Modify default cycle settings.’ The “Update + Reboot Cycle” in BatchPatch is essentially a dedicated Job Queue.

A BatchPatch job queue enables you to execute a sequence of actions on a given target host or set of hosts. That sequence might, for example, instruct target computers to download/install/reboot then wait until reboot is complete before performing the same download/install/reboot a second time (or more times, if desired). For a tutorial on using the job queue, please see this link: Using the Job Queue in BatchPatch for Multi-Step Execution

Since the ‘Update + Reboot Cycle’ task is one that administrators routinely ask for, we also include a dedicated Job Queue just for that purpose. There is nothing different about the ‘Update + Reboot Cycle’ dedicated job queue as compared to a regular/custom job queue that you create in the ‘Create/modify job queue’ window, with the exception that it’s a dedicated resource for this purpose. There is only one global ‘Update + Reboot Cycle’ queue. You can modify it by selecting ‘Actions > Windows Updates > Update + Reboot Cycle > Modify default cycle settings.’ The default update + reboot cycle queue is:

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

This cycle works well for most users’ needs, but of course you are welcomed to modify it, if needed. Or if you prefer you may always just create a custom job queue instead. When you’re ready to execute it, simply highlight the desired target hosts in the grid, and then select ‘Actions > Windows Updates > Update + reboot cycle > Execute cycle.’

Posted in Blog, General, Tutorials | Tagged cycle, loop, windows update | Comments closed

Remotely Install Java 8 on Numerous Computers Simultaneously

Windows Patch Management without WSUS

To WSUS or not to WSUS, that is the question!

For those of you looking for a patch management solution that does not rely on WSUS, BatchPatch works fantastically as a stand-alone alternative to or replacement for WSUS…

The problem with relying on only group policy to handle your entire download, install, and reboot process for Windows Updates

On-Demand Download, Installation, and Monitoring of Windows Updates and Reboots on Numerous Computers

Scenario 1:

Scenario 2:

Scenario 3:

Scenario 4:

Scenario 5:

How to Setup a New WSUS Server from Scratch on Windows Server 2012 R2

Reviewing the Core Functionality that BatchPatch Offers

Additional Resources:

Download the Complete Windows Updates Security Repository per Operating System

Downloading Windows Updates for Distribution to Offline Computers on High-Security Networks

Remote Software Deployment Hangs Indefinitely – How to Resolve

Triggering ConfigMgr (SCCM) Client Actions Remotely

Deploying 7-Zip 16.0.2

Update + Reboot Cycle – Create a Continuous Loop to Download and Install Windows Update Plus Reboot Until there are no Applicable Updates

Search

Recent Posts

Categories

Archives

Blogroll

RSS Links

To WSUS or not to WSUS, that is the question!

For those of you looking for a patch management solution that does not rely on WSUS, BatchPatch works fantastically as a stand-alone alternative to or replacement for WSUS…

The problem with relying on *only* group policy to handle your entire download, install, and reboot process for Windows Updates

On-Demand Download, Installation, and Monitoring of Windows Updates and Reboots on Numerous Computers

Scenario 1:

Scenario 2:

Scenario 3:

Scenario 4:

Scenario 5:

Additional Resources:

Search

Recent Posts

Categories

Archives

Blogroll

RSS Links

The problem with relying on only group policy to handle your entire download, install, and reboot process for Windows Updates