Advanced Script Integration with BatchPatch – Part 2

BatchPatch currently provides functionality for retrieving from target computers the list of services that are set to ‘automatic’ but currently in the ‘stopped’ state. The reason this is valuable/convenient for most users is because after you reboot computers you frequently want to have a quick way to determine that all of the services that should be running are, in fact, running.

If a service is set to ‘automatic’ it generally should be running after Windows boots. However, unfortunately there are actually some cases where a service might be set to ‘automatic’ but isn’t always running. In these cases we may or may not actually care about the particular service in question.

For example, the following services on my computer are currently set to ‘automatic,’ but none of them are actually running at the moment:

Microsoft .NET Framework NGEN v4.0.30319_X86
Microsoft .NET Framework NGEN v4.0.30319_X64
Google Update Service (gupdate)
Multimedia Class Scheduler
Software Protection
Skype Updater

We have had some customers request the ability to create an exclusion list for the BatchPatch “Get stopped automatic services” action. The idea here is that you would be able to create a list of services that you don’t really care about, so that when you execute “Get stopped automatic services” it only lists the services that are NOT contained in the exclusion list. So if a really important ‘automatic’ service, like SQL Server, had not started after rebooting a computer, it would be easier to identify it if it weren’t buried in a list of other services that aren’t started, like the ‘Software Protection’ service, which is usually not started, even though it’s set to ‘automatic.’ We intend to provide this functionality in a future version of BatchPatch (EDIT: The feature was added 2015-07-22 and is available under ‘Tools > Settings > General > Exclusions list’). However, in the meantime while you are waiting for it, there is actually a very easy way to accomplish the same task in the current version of BatchPatch.

Sample script:

Download StoppedAutoServices.vbs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
'Gets the list of services on a computer that are set to automatic and stopped but do not exist in the script's hardcoded list: arrayServiceExclusions.  Cocobolo Software, LLC June 2015

'usage: cscript.exe StoppedAutoServices.vbs COMPUTERNAME

'the first argument from the command line is assigned to strComputer
strComputer = WScript.Arguments(0)
 
'create an array containing the list of service display names to exclude from the check for stopped automatic services.
arrayServiceExclusions = Array("Microsoft .NET Framework NGEN v4.0.30319_X86","Microsoft .NET Framework NGEN v4.0.30319_X64","Google Update Service (gupdate)","Multimedia Class Scheduler","Software Protection","Skype Updater")
strStoppedAutoServicesList = ""
intCounter = 0
 
on error resume next
Err.Clear
 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
 
'Get list of running services
Set colService = objWMIService.ExecQuery("Select * from Win32_Service")
		For Each objService in colService
			If ((objService.StartMode = "Auto") And (objService.State = "Stopped")) Then
				boolIsServiceContainedInList = 0
				'loop through our hardcoded list and compare
				For Each strServiceName in arrayServiceExclusions
					If objService.DisplayName = strServiceName Then
						boolIsServiceContainedInList = 1
					End If
				Next
				'if a service is set to automatic and in the stopped state and NOT contained in our hardcoded list, then add it to our final report and increment the counter
				If boolIsServiceContainedInList = 0 Then
					strStoppedAutoServicesList = strStoppedAutoServicesList & vbLf & objService.DisplayName
					intCounter = intCounter + 1
				End If
			End If
		Next
 
'write the results list to the console
WScript.Echo strStoppedAutoServicesList
'exit the script with the return value as the number of items in our list
Wscript.Quit(intCounter)

To integrate the StoppedAutoServices.vbs script into BatchPatch:

  1. Create a ‘Local process/command’ in BatchPatch. Select Actions > Execute local process/command > Create/modify local commands.
    2015-04-27 16_15_11-Program Manager
  2. Add the StoppedAutoService.vbs script to the grid.
    2015-06-24 17_41_07-Program Manager Note, we use $computer as a parameter in the cscript.exe command. This tells BatchPatch to send the host name from the row that executes the script. This is what allows us to execute a script locally on the computer running BatchPatch to retrieve information from a remote computer.
  3. Now we’re ready to execute the script. For the sake of this example, I have removed all but ‘Software Protection’ from the exclusion list hardcoded into the script as arrayServiceExclusions. The reason for this is to demonstrate what the output looks like when some ‘automatic’ services are found in the ‘stopped’ state. However, we will not see ‘Software Protection’ appear in our output since it remains in the arrayServiceExclusions. Highlight the target computers in the grid and then select Actions > Execute local process/command > Execute saved local commands > Get Stopped Automatic Services
    ExecuteLocalCommandGetStoppedAutoServices
  4. When the script completes a couple of seconds later, we can see that the ‘Exit Code’ value in the ‘All Messages’ column is equal to the number of stopped automatic services that were found, excluding (of course) the items hardcoded into the script arrayServiceExclusions, which in this instance was only ‘Software Protection.’ In the screenshot below I have revealed the cell contents for the first row, and we can see the 4 services that were found. If a machine is clear and no stopped automatic services are found, then the Exit Code will be 0, indicating that we do not need to further examine that computer.
    ExecuteLocalCommandGetStoppedAutoServices_Result
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Using BatchPatch with an Enterprise Web Proxy

If your environment forces computers to make http connections through a corporate proxy of some kind, usually BatchPatch will work properly with no additional configuration. This is because in most environments where an outbound web proxy is already configured and running, the target systems will also already have been configured with all of the settings they need to successfully utilize the proxy to download Windows Updates from Microsoft. However, in some environments there could be additional configuration needed. Proxy configuration problems for BatchPatch users typically manifest in one of two ways:

Scenario 1: The Windows Update Agent on target computers is not configured to use the corporate proxy:

If your environment requires that outbound web requests be initiated through a proxy but your computers are not configured to utilize said proxy, BatchPatch will likely produce an error similar to one of the following. Note, the errors listed below are not the only possible manifestations of a proxy related issue. It’s possible that you have a proxy related issue and you are receiving a different error message or number:

-102: Failed to execute the search. HRESULT: -2147012866
-102: Failed to execute the search. HRESULT: -2147012867
-102: Failed to execute the search. HRESULT: -2147012894
-102: Failed to execute the search. HRESULT: -2145107924

When you see an error message like this, it is always a good idea to first examine the Windows Update log file (C:\Windows\WindowsUpdate.log) on the target computer to see if it has any other potentially relevant error codes or messages. Frequently the WindowsUpdate.log will contain additional errors or error text that can be useful to determine what the cause of the problem is.

In the BatchPatch Remote Agent Log errors listed above, the -102 is noted by BatchPatch to indicate that the target computer was not able to execute the search for updates. The HRESULT value is the decimal representation of the actual Windows error code, which we can use to learn *why* the search for updates failed.

Let’s start by converting the HRESULT decimal values to hex. There are many ways to accomplish this task, but a very simple one is with the method described here: how-to-convert-hresult-decimal-dec-values-to-hexadecimal-hex

In this case a quick Google search reveals what these errors mean (https://support2.microsoft.com/default.aspx?scid=836941):

-2147012866 => 0x80072EFE => ERROR_INTERNET_CONNECTION_ABORTED
-2147012867 => 0x80072EFD => ERROR_INTERNET_CANNOT_CONNECT
-2147012894 => 0x80072EE2 => ERROR_INTERNET_TIMEOUT
-2145107924 => 0x8024402c => WINHTTP_NAME_NOT_RESOLVED

Configuring target computers’ Windows Update Agents to utilize your corporate proxy for outbound connections:
Proxy Configuration for the Windows Update Agent – Microsoft

To summarize the link above, in order for the Windows Update Agent to utilize a proxy in your environment, it is *not* sufficient to simply configure the proxy settings in Internet Explorer or Control Panel Internet Options. Instead, the WinHTTP proxy settings must be configured using the NETSH tool or through the use of WPAD (Web Proxy Auto Detect). To set the WinHTTP proxy on each target computer, run the following command at an elevated command prompt, where proxyservername is the name of your proxy server, and portnumber is the port that it is listening on:

netsh winhttp set proxy proxyservername:portnumber

You can even use BatchPatch to execute the above NETSH command on your target computers. See the following links for assistance: Executing Remote Commands with BatchPatch and How to Hard-Code Your Own Custom Commands in the BatchPatch Actions Menu

Scenario 2: The Windows Update Agent on target computers is properly configured to use the corporate proxy, but the proxy requires authentication:

If your environment requires that outbound web requests be initiated through a proxy, and the proxy requires authentication, BatchPatch might produce an error similar to one of the following. Note, the errors listed below are not the only possible manifestations of a proxy related issue. It’s possible that you have a proxy related issue and you are receiving a different error message or number:

Download Result: Failed. HRESULT: -2145107941

Let’s start by converting the HRESULT decimal value to hex. There are many ways to accomplish this task, but a very simple one is through the use of an online tool such as this: http://www.rapidtables.com/convert/number/decimal-to-hex.htm

-2145107941=> 0x8024401B => WU_E_PT_HTTP_STATUS_PROXY_AUTH_REQ Same as HTTP status 407 - proxy authentication is required

So, if authentication is required by your proxy, and if you’re receiving an error message in BatchPatch or in the Windows Update log (C:\Windows\WindowsUpdate.log) on the target computer that indicates there is a proxy authentication issue or failure of some kind, you can resolve this problem by whitelisting the Windows Update / Microsoft Update websites in your proxy configuration. This way you allow target computers to bypass the corporate proxy when establishing connections to just these particular sites.

The domains to whitelist are:

http://download.windowsupdate.com
http://*.download.windowsupdate.com
http://download.microsoft.com
https://*.update.microsoft.com
http://*.update.microsoft.com
https://update.microsoft.com
http://update.microsoft.com
http://*.windowsupdate.com
http://*.windowsupdate.microsoft.com
http://windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://ntservicepack.microsoft.com
http://wustat.windows.com
http://*.au.windowsupdate.com
http://*.tlu.dl.delivery.mp.microsoft.com

If you are using a wpad.dat file to configure your computers’ proxy settings, you can use the following syntax in the wpad.dat file to whitelist the Microsoft domains:

if ( shExpMatch ( url, "*.download.windowsupdate.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.download.microsoft.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.update.microsoft.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.windowsupdate.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.download.windowsupdate.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.windowsupdate.microsoft.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.ntservicepack.microsoft.com/*") ) { return "DIRECT"; }
if ( shExpMatch ( url, "*.wustat.windows.com/*") ) { return "DIRECT"; } 
if ( shExpMatch ( url, "*.au.windowsupdate.com/*") ) { return "DIRECT"; } 
if ( shExpMatch ( url, "*.tlu.dl.delivery.mp.microsoft.com/*") ) { return "DIRECT"; }
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

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

One of the most common problems that people encounter with BatchPatch, and consequently one of the most common support questions we receive, has to do with remotely deploying software. A remote software deployment that is executed in BatchPatch without specifying the proper silent/quiet installation parameter/switch, will either fail altogether or in most cases will simply appear to hang indefinitely without ever completing. I want to take some time today to address this issue and to help clarify any confusion that you might have.

Normally when you install software on a computer you double-click a setup.exe file obtained from software vendor. When you double-click the setup/installation executable you are prompted with a dialog that asks you to choose various settings for the installation, usually including a target directory for the software, components of the software to be installed, startup options, desktop icons, etc. You typically have to click “Next” at least a couple times on the setup dialog until eventually the software installation is complete.

As you can imagine, if you execute the same software installation remotely on many computers, you’ll need a way to select the various setup options without requiring a remote user to have to interact with the installation process. Furthermore, in BatchPatch (or in any other deployment product) when you execute a software deployment on a set of target computers, the deployment process that runs on those remote computers is hidden from the interactive user. If the hidden process requires user input of any kind to select installation options or to click “Next” buttons in a dialog window, the software installation will simply hang forever because no one is able to see or interact with the hidden process in order to be able to click select the installation options and/or click “Next” when prompted.

The solution for remote software deployment is the silent/quiet switch/parameter. The large majority of software installation packages can be executed silently so that they simply install the software without prompting the interactive user to click on anything. For example, if the software to deploy comes in a Setup.exe file, the silent switch might be /silent, -silent, /s, -s, /quiet, -quiet, /q, -q or something similar. Those are the most commonly used switches, though sometimes case actually matters, and it could be /S instead of /s. And if the proper silent switch were just /s, then to execute a silent installation of the software locally we could just launch a command prompt and type:

Setup.exe /s

But how do we determine or discover what the silent installation parameter is for a given installation package? I can tell you that from the various support inquiries we’ve received over the years, many folks seem to think that you can simply make up your own installation parameters. However, I’m here to tell you that you can’t do that. There is generally a three-step method for determining the actual silent / quiet installation parameter for a given package.

  1. Try launching the installation package with one of the following parameters:

    /? -? ? /help -help

    As an example, you can see in the screenshot below that I have launched the .msu package with /? as its only parameter.
    2015-06-03 17_20_57-Command Prompt
    When executing this .msu at the command line with the appropriate help switch, the installation options for this package are revealed. We can see that in order to execute a silent installation of this package, we would use the /quiet parameter.
    2015-06-03 17_23_29-Program Manager

  2. If for some reason the package does not reveal its installation options, typically the next thing to do is check the vendor’s documentation or website, or reach out to the vendor’s support team.
  3. Finally, Google is always available when no other methods are working. In most cases you are not going to be the first person trying to silently install a program, so there’s a very good chance that you’ll be able to find a posting somewhere on the web to help you with the correct silent installation parameter.

Once you’ve determined the proper silent installation switch, it’s generally best to test it at the command line first to make sure it works as expected. The goal is to confirm that the software installs successfully and that it does not prompt you to click on anything in order to complete the installation. If any windows appear during the installation and wait for your input, then something isn’t right.

When you have the silent installation working properly at the command line, then you can transfer it to BatchPatch to execute the deployment on a test computer. Assuming all goes well with the test computer, then you can go ahead and feel comfortable executing the deployment on many target computers.

For numerous tutorials/examples for remote software deployment to many computers using BatchPatch, please visit the software deployment page.

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

Configuring Ping Status Alerts in BatchPatch

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

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

Windows Update Installation Filters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted in Blog, General, Tutorials | Comments closed

Using Alternate Logon Credentials in BatchPatch

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

3 methods for specifying credentials:

  • (Integrated Security Option 1 – Recommended) Logon to the BatchPatch computer with the same account that has been granted local administrator permission on the target computers. This is the recommended method for operating BatchPatch. Whenever possible, we encourage you to simply log on to the computer that runs BatchPatch with the same account that you have designated to exist in the local administrators group on the target computers. When you launch and operate BatchPatch, it will run under the security context of that same account, and so it will automatically have the appropriate permissions to connect to target computers.
  • (Integrated Security Option 2 – Recommended when option 1 is not possible) Launch BatchPatch using “run-as,” by right-clicking on the BatchPatch.exe and choosing “run-as” so that you may enter different credentials for launching the application. In this case you might be logged on to your computer with one account, but you are then able to launch and run BatchPatch under a different account, with that different account also being a member of the local administrators group on the target computers. NOTE: Generally, in order for this to work properly you must have logged on to the computer at least one time with the run-as account. If you are trying to use a run-as account that has never been used to log on to the computer, you will most likely experience an error.
  • (Alternate Credentials – Less Secure) Launch BatchPatch normally, but input row-specific credentials for each host in the BatchPatch grid. With this option you are able to specify a different logon account to use for each target host listed in the BatchPatch grid. If your target hosts are setup such that you must use a different logon account to obtain administrative privileges on each of the target computers, then this method is your best bet: ‘Actions > Specify alternate logon credentials’.

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

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

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

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

Domain environments:

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

Non-domain (workgroup) environments:

IMPORTANT: In workgroup / non-domain environments, there are a couple of extra items that you need to be aware of in order to get authentication working properly with BatchPatch. In the sections below that describe how to use local accounts for authentication, we highlight registry entries/changes that you might need to make in your environment if you desire to use local accounts for authentication. These registry modifications come with their own security implications. You can read more about those registry values and remote UAC filtering here:

User Account Control and WMI
Description of User Account Control and remote restrictions
User Account Control Group Policy and registry key settings

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

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

  • If the local account you are using to run BatchPatch is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. When this DWORD is set to 0, the built-in administrator account is set to full-token mode, and BatchPatch will work properly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most BatchPatch actions from completing successfully for those target computers:

    (Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets):

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken
  • If the local account you are using to run BatchPatch is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then the following registry DWORD must be set to 1 on the target computers:

    (Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets):

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Advanced Script Integration with BatchPatch

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

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

Sample script:

Download ProcessComparison.vbs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
'Gets the list of running processes on a computer.  If a running process matches a pre-defined list of executables, the script sleeps for a minute and then checks again.  If there is no match, the script exits.  Cocobolo Software LLC April 2015.
'usage: cscript.exe ProcessComparison.vbs COMPUTERNAME

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

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

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

Remember…

  • If a script has built-in capability to query remote computers, then the script should be run on the local computer that runs BatchPatch using Actions > Local process/command.
  • If the script does NOT have built-in capability to query remote computers and it can ONLY retrieve information about the local computer that it’s being executed on, then the script must be executed remotely on each target computer using Actions > Remote process/command.

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

  1. First we need to create the ‘Local process/command’ that we’ll use later in the Job Queue. Select Actions > Execute local process/command > Create/modify local commands.
    2015-04-27 16_15_11-Program Manager
  2. In ‘Local Process’ window we’ll add the command to execute our script.
    2015-04-27 16_24_17-Program Manager We’re able to use $computer as a parameter, which will tell BatchPatch to send the host name from the row that executes the script. This is the key to how we use a local script to accomplish a task on a remote computer.
  3. Next we’ll create the Job Queue that utilizes the script. The goal with this job queue is to only download and install Windows Updates on target computers *after* the script exits, which will indicate that none of the pre-defined processes that we hard-coded into the script are running on the target computers when the Windows Update action is triggered. Select Actions > Job Queue > Create/modify job queue.
    2015-04-27 16_53_21-Program Manager
  4. In the Job Queue window, locate the ‘Local Command’ you just created, and then insert it into the queue before the ‘Download and install updates + reboot if required’ action. Then save the queue by clicking the >> button.
    2015-04-27 16_55_24-Job Queue
  5. Finally we’re ready to execute the queue. Select Actions > Job Queue > Execute saved job queues > Wait for pre-defined processes to end…
    2015-04-27 16_59_01-
    BatchPatch will now wait until a target computer no longer has the running processes specified in our script. Then it will execute the Windows Update + reboot if required. That’s all there is to it!
Posted in Blog, General, Tutorials | Tagged , , , , , | Comments closed

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

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

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

Importing Hosts and Other Information into a BatchPatch Grid

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

The allowed values are:

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

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

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

1
2
3
4
5
host1
host2
host3
host4
host5

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

1
2
3
4
5
host1#CCDDEECCDDEE
host2#DDEECCDDEECC
host3#EECCDDEECCDD
host4#CCDDCCDDEEEE
host5#CCDDEEEECCDD

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

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

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

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

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

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

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

1
2
3
4
5
host1|special notes for host1
host2|special notes for host2
host3|special notes for host3
host4|special notes for host4
host5|special notes for host5
Posted in Blog, General, Tutorials | Tagged | Comments closed

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

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

  1. Place all the .MSU files that you plan to install into a single folder. There should be nothing else in that folder. You can use this method to install .MSU, .MSP, or .MSI files, but since Microsoft seems to now have mostly standardized on .MSU files for individual Windows update packages, in this example we’re just using .MSU files.
  2. Once all of your installation package files are in a single folder, launch BatchPatch and highlight the hosts that you want to include in the deployment. Then select ‘Actions > Deploy software/patch/script > Create/modify deployment.’
    2015-03-31 16_49_32-Program Manager
  3. In the ‘Deployment’ window that appears, click the folder browser button.
    2015-04-02 13_32_39-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  4. Select the ‘Multiple update file deployment’ radio button, and then click OK.
    2015-04-02 13_36_15-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  5. A message box pops up explaining to place all .msi, .msp, and .msu files to be deployed into a single folder. Click OK and then select the folder.
    2015-04-02 13_44_41-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  6. After we select the folder, BatchPatch scans the folder for .msi, .msp, and .msu files. BatchPatch then creates a .cmd script file in the folder. The .cmd file contains the commands that will be used during execution to install the .msu files.
    2015-04-02 13_45_19-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
    2015-03-31 16_55_19-DeployMultipleFiles_Tutorial
  7. When we click OK on the final message box, BatchPatch automatically inserts the correct/appropriate deployment configuration options into the ‘Deployment’ form. The configuration is setup so that when you execute the deployment, the .cmd file that BatchPatch created along with the entire folder of .msu files will be copied to the target computers. Once copied to the target computers, BatchPatch will execute the .cmd script, which will handle installing each .msu file, sequentially.
    2015-04-02 13_46_05-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  8. That’s all there is to it. You can now save and/or execute the deployment!
Posted in Blog, General, Tutorials | Tagged , , , , , | Comments closed