Blog | Page 27

Create a Consolidated Report of Available Updates for Numerous Computers

By Scott | Published: August 25, 2015

Some administrators might need a singular, consolidated report that lists all Windows Updates that are needed by computers in the organization. It would be nice if creating such a report didn’t require any manual work on the part of the administrator. The good news is that with BatchPatch you can create a consolidated report like this for all computers in just a few clicks. Usually it only takes a minute or two for all of the target computers to report back with results. However, the report is generated and displayed in real-time, so as target hosts complete their processing and report back to the main interface, the results are immediately visible in the report grid even if not all computers have reported back yet. The information displayed includes host name, update title, KB number (if applicable), update size, the published date or date of approval in WSUS, the update classification (Critical, Security, Definition, Updates, Update Rollups, Service Packs, Feature Packs, Drivers, Tools), whether or not the update has actually been downloaded to the target yet, and whether or not the update requires a reboot to complete installation.

Add target hosts to the BatchPatch grid by selecting ‘File > Add hosts’ and then inputting the names of the computers you want included in the consolidated report.
Select ‘Actions > Windows Updates > Generate consolidated report of available updates’
When you click OK to begin generating the report, you’ll see the report window appear. As individual hosts in the list are scanned and their scans complete, the available updates for those hosts will begin appearing in the report. In the screenshot below you can see we scanned a single host that had 12 available updates.
It should be noted that the ‘Date’ field is used to show the date the update was published, or in the event that a managed update server like WSUS is being used, it will show the date the update was approved by the WSUS administrator. The report can be exported to a delimited file by selecting the ‘Export report’ menu item in the upper left corner of the window, making it easy to import the report into your favorite spreadsheet application, such as Microsoft Excel.

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

How to Remotely Initiate Windows Update on Numerous Computers Simultaneously

By Scott | Published: August 18, 2015

One of BatchPatch’s core features is the ability to remotely initiate the Windows Update search/download/install process on target computers. Not only does it allow you to execute this process on many computers at the same time, but it even lets you monitor the process in real-time so that you can see how far along each computer is. In a BatchPatch grid, one row is created per computer, and each row has its own progress bar, which enables you to see the overall completion percentage, the name of the currently downloading/installing update, as well as the current update completion percentage. I’ll do a run-through of the entire process below, so that you can see just how quick, simple, and painless it is to remotely apply Windows Updates to an entire network of computers.

We’ll start by adding some computers to a BatchPatch grid. Launch BatchPatch and then right click on the empty grid and select ‘Add hosts.’ Then input the host names of the computers you want to add. Finally click ‘OK’ to add the hosts to the grid.
Before we proceed, let’s double-check our Windows Update settings. Go to ‘Tools > Settings > Windows Update.’ In the window that appears you have the option of choosing ‘Windows Update,’ ‘Microsoft Update,’ or your local WSUS server. You can also select from a few different search preferences, and you can set download and installation filters too, if you want.
Now that the grid has been populated with some target computers, let’s go ahead and initiate a check for available updates. This check will show us which updates are available on each computer. Highlight the desired rows, and then select ‘Actions > Windows Updates > Check for available updates.’

We can see the results for one of the hosts in the screenshot below. This log is made visible by simply middle-clicking on the ‘Remote Agent Log’ column for the host in question. There are also a couple of other ways to view this information in BatchPatch, including the ability to get a consolidated list of available updates from all hosts in the grid.
Even though we first did a check for available updates in the previous step, if we had wanted we could have skipped straight to this step, where we’ll download and install the updates to our target computers. However, in some cases it’s nice to know ahead of time what updates are even available to the computers before initiating the download and/or installation process. To remotely initiate the Windows Update download and installation process on all the selected computers, all you have to do is select ‘Actions > Windows Updates > Download and install updates + reboot if required.’ If you don’t want the hosts to be rebooted automatically by BatchPatch, then instead go ahead and select ‘Actions > Windows Updates > Download and install updates.’
At this point it’s just a question of waiting a few minutes until the process is complete. The process can take anywhere from a few minutes all the way up to a couple of hours, depending on how many updates need to be downloaded and installed. A new installation of Windows will likely have more than a hundred updates available, whereas an older installation that has been maintained might only have a couple. However, it doesn’t matter how many hosts are in the grid or how many hosts are executed simultaneously. Each host will be handled in a separate thread, so you don’t need to factor in extra time for more hosts. If a host will take about 10 minutes on its own, then it will still take the same 10 minutes when its handled concurrently with numerous other hosts. You can imagine how much time this can save when executing the process across dozens or even hundreds of target computers!

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

Copying files or folders to numerous computers using BatchPatch

By Scott | Published: August 11, 2015

BatchPatch provides the administrator with the ability to easily copy files and/or folders to numerous computers, simultaneously. If you simply need to push a file to target computers or you need to replace a file that already exists on target computers, here’s how to do it:

Select the target hosts that you want to copy files/folders to. Then select ‘Actions > Copy file / folder > Create/modify file or folder copy’
In the dialog that appears, let’s start by adding a title for our copy job. Note, a title is not required for one-off jobs. The title is only required if you plan to save the copy job to use again in the future. For the sake of this example, we’ll save the job.
Use the browse button to select the source file/folder to be copied. In the ‘Destination folder’ field, we manually type the path of the folder on target computers that we want to set as the destination for the copied files. Lastly, if we want to overwrite existing files with the same name, then we can check the ‘overwrite’ box. Optionally use the >> button to save the copy job for future use.
At this point we are actually ready to execute the copy. If we click on the button that says “Execute now,” the file copy job will be executed for each selected row. The file will be copied from our source folder to the specified destination folder on each selected computer in the BatchPatch grid. Alternatively, if we saved the copy job, then we can close this window and execute the copy job later. For the sake of this example, let’s close the window.
Now that the copy job has been created, let’s go ahead an execute it. Highlight the desired target hosts in the grid, and then select ‘Actions > Copy file/folder > Execute saved file/folder copy job.’ In this case since I’ve only saved one job, I’ll select it. You can see when I hover my mouse over the menu item, a tooltip window appears showing the details of the copy job configuration, so that I can verify that I’m executing the correct job.
Finally, I will complete the job by clicking the menu item for the job in question. I’m prompted to confirm the action, so I select OK to complete the copy.
We can see the successful copy in the screenshot below. That’s all there is to it!

Posted in Blog, General, Tutorials | Comments closed

Checking for Stopped Automatic Services with Exclusions

By Scott | Published: July 29, 2015

In the most recent release of BatchPatch we added a simple but very useful little feature to assist with reporting on stopped automatic services on a large number of target computers.

As sysadmins, we know that after rebooting a large number of computers, it’s extremely useful to be able to confirm that the services that have been set to ‘automatic’ have actually started properly. If you install updates on 100 SQL servers, but one of the updates somehow prevents the SQL Server service from starting properly after the machines are rebooted, you’re going to want to know about it immediately. The same goes for Exchange services, which commonly don’t all start properly after reboot, as well as many other services.

BatchPatch has always had the ability to retrieve from target computer the list of services that are set to ‘automatic’ but in the ‘stopped’ state. However, when working with a large number of target machines, this was less than ideal because there are some automatic services that we don’t care about that might regularly be in a stopped state. The perfect example is the Windows ‘Software Protection’ service. It’s generally going to be in the stopped state even though it’s set to automatic. It would be really nice if we could simply report on the services that we really care about, so that at a quick glance we can immediately determine which machines we need to investigate further, rather than having to read through separate a list of stopped automatic services for every single target computer.

In the latest release of BatchPatch we added an exclusions list that works in conjunction with the check for stopped automatic services. Using it is very simple. Go to ‘Tools > Settings > General’ and then click on the “exclusions list” button next to the label that says “Global exclusions list for automatic services in stopped state.”

You can see in the screenshot above that I’ve added a few services to exclude. In this list we require the service ‘Display Name’ not the actual service name. For example, the ‘Software Protection’ service corresponds to the sppsvc service. You can see the display name vs the actual service name of all services in the Services console. My favorite way to launch the services console is to go to ‘Start > Run’ and then type “services.msc” in the run box without the quotes.

In the Services console if we double-click the ‘Software Protection’ service entry, we can see the details where it shows us the ‘Service name’ and the ‘Display name.’

So, for the BatchPatch services exclusions list, make sure to always use the display name, not the actual service name. Enter one service display name per line. Any service that is included in the exclusions list will then be skipped/ignored if it is stopped on target hosts when you perform the check for stopped automatic services.

In the screenshot below I’ve executed ‘Actions > Get information > Get automatic services in stopped state.’ You’ll notice that the first host reports 2 stopped automatic services. In reality, the computer has 3 stopped automatic services, with that third service being ‘Software Protection.’ However, since ‘Software Protection’ is in our exclusions list, when we check for stopped automatic services, BatchPatch simply reports that 2 services are stopped, and we can see in the list of stopped services that ‘Software Protection’ is not included.

Posted in Blog, General, Tutorials | Tagged automatic services, exclusions | Comments closed

Running BatchPatch as a Service

By Scott | Published: July 21, 2015

In the latest release of BatchPatch we added functionality to run BatchPatch as a service, enabling you to execute scheduled tasks even when no one is logged on to the BatchPatch computer.

Go to Tools > Run BatchPatch as a service to reveal the run-as-service settings window.

The installation of the service requires BatchPatch to be running with elevation (as administrator). When running as admin you simply need to click the Install Service button. The service will be installed under the logon account that you’re currently using to run BatchPatch. In this way we allow multiple users on the same computer to each install their own instances of the BatchPatch service.

Once installed we can see 3 green check marks to indicate that the service is installed, the service is running, and the service instance is running. The BatchPatch service is responsible for starting the BatchPatch service instance (a dedicated/special instance of BatchPatch that runs as long as the service is running).

Once the service has been installed, you can select grids to be run by the service instance. You would create a BatchPatch grid and set the various scheduled tasks that you desire to execute on the hosts in the grid. Then save the grid to a .bps file. Once the file has been saved you can ‘send’ it to the service instance in two ways. Either right-click on the tab header and choose “Send grid to service instance”

Or use the run-as-service settings dialog + button to add .bps files:

Once a file has been added, we’ll see it appear in the list of currently active .bps files:

We can monitor this grid by launching it in the service instance .bps file viewer. Either double-click the filename in the list, or highlight it and choose the option to “Launch selected .bps file(s) in viewer.” Alternatively, you could even select “File > Open” and browse to the .bps file, or you could drag and drop the .bps file onto the BatchPatch window. Any of these actions will launch the grid in the service instance viewer.

The viewer will allow you to monitor the grid in real-time, but you will not be able to edit/modify it. If you desire to modify the grid, you’ll have to first remove the grid from the service instance. The removal process is similar to the process we used to add the grid in the first place. Only this time we’ll choose the “Remove grid from service instance” option. We can also just drag the grid from the service instance viewer into the regular/main BatchPatch window. Either action will prompt BatchPatch to display a confirmation dialog.

Don’t hesitate to contact us with comments, criticisms, and suggestions: Contact us

Posted in Blog, General, Tutorials | Tagged run as service, service | Comments closed

Enabling Microsoft Update instead of Windows Update on Target Computers with BatchPatch

By Scott | Published: July 13, 2015

The distinction between ‘Windows Update’ and ‘Microsoft Update’ has caused a significant amount of confusion for people over the years, so I’d like to take a moment to clarify the difference, as well as to explain how you can configure your target computers to use one or the other with BatchPatch.

First note that if you are using WSUS in your environment, then you probably aren’t going to be too concerned with the distinction. Your target computers will be receiving updates from your local WSUS server, and that’s all there is to it. However, for environments and users that are not using WSUS, the distinction is more important.

Defining ‘Windows Update’ and ‘Microsoft Update’

Generically, when we say ‘Windows Update’ or ‘Microsoft Update’ we are talking about software updates for computers. More specifically, when Microsoft uses the term ‘Windows Update’ they are referring to the update service that provides software updates to Windows operating systems. When they mention ‘Microsoft Update’ they are referring to the update service that provides software updates to Windows operating systems AND to individual software products that Microsoft has created, such as Office, Visual Studio, Exchange, and SQL.

By default all Windows computers today are subscribed to the ‘Windows Update’ service when a computer is first enabled for receiving software updates from Microsoft. When configured to use ‘Windows Update’ a computer will only ever detect available operating system updates. To enable the system also retrieve updates for individual Microsoft products, ‘Microsoft Update’ needs to be explicitly enabled on each computer.

Configuring ‘Windows Update’ vs ‘Microsoft Update’ on Individual Computers

If you launch the control panel Windows Update interface (Control Panel > Windows Update), you can determine which service a particular computer is configured to use.

When ‘Windows Update’ is enabled, you’ll see something like this:

To configure the computer to use the ‘Microsoft Update’ service instead of the ‘Windows Update’ service, click on the link that says “Find out more.”

When ‘Microsoft Update’ is enabled, you’ll see something like this:

Configuring ‘Windows Update’ vs ‘Microsoft Update’ on Numerous Computers with BatchPatch

You can use BatchPatch to determine which update service your target computers are configured to use, as well as to configure your target computers for a particular service.

Highlight the desired hosts in the BatchPatch grid and select ‘Actions > Windows Updates > Get Windows Update configuration’ (note, this is the same as ‘Actions > Get information > Get Windows Update configuration’).

After clicking OK BatchPatch will connect to the target computers to retrieve their current settings. You can see in the screenshot below that both of my test computers are currently set to use the ‘Windows Update’ service. If either were configured for ‘Microsoft Update’ we would see it in the screenshot. Additionally, if either were configured to use a local WSUS server instead of one of the Microsoft public services, we would see that here as well too.

To configure the target computers to use ‘Microsoft Update’ we select ‘Actions > Windows Update > Opt-in to Microsoft Update (enable updates for other MS products)’

Note, the Windows Update service on the target computer will be restarted as part of the ‘opt-in’ process. In the screenshot below you can see that I enabled the ‘Microsoft Update’ service on one of the computers.

In the same way that I just enabled ‘Microsoft Update’ I can easily disable it by using ‘Actions > Windows Update > Opt-out of Microsoft Update (disable updates for other MS products)’. That’s all there is to it.

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

Executing PowerShell Scripts and Commands (cmdlets) on Remote Computers with BatchPatch

By Scott | Published: July 2, 2015

Executing PowerShell commands and scripts remotely can be a bit tricky. BatchPatch currently has direct support for deploying PowerShell scripts to target computers, and we will be adding more PowerShell functionality in the not-too-distant future. However, today I’d like to take a few minutes to go over the current options you have for executing PowerShell commands through BatchPatch on target computers.

Executing PowerShell Scripts:

If you’ve written a powershell script that you simply need to execute on a set of target computers, your easiest option is to use BatchPatch’s deployment feature. BatchPatch will handle copying the file to target systems, executing the script, and then deleting the file.

In BatchPatch, select Actions > Deploy software/patch/script/regkey etc > Create/modify deployment
In the Deployment form set a title, browse and for the .ps1 script file. For ease of operation I’m going to save this Deployment using the double right arrow button >>. Once the Deployment has been saved, the Deployment form can be closed.
Highlight the hosts you want to deploy the script to. I titled my deployment “Execute PowerShell Script 1,” so I will now select Actions > Deploy software/patch/script/regkey etc > Execute saved deployments > Execute PowerShell Script 1. You can see in the screenshot below that when the mouse hovers over the menu item, the configuration of the actual deployment is displayed in a tooltip.
When you click OK you’ll be presented with a confirmation dialog which also displays the configuration of the deployment that is going to be executed. Click OK to continue.
When the script completes Exit Code: 0 (SUCCESS) is displayed in the ‘All Messages’ column. That’s all there is to it. However, if your script was specifically written to output messages to the console, you could select the “Retrieve console output” checkbox option in the Deployment form when configuring the deployment. However, this setting can cause a deployment to not execute in some cases, so proceed accordingly.

Executing PowerShell Cmdlets:

If you only need to execute a particular powershell cmdlet that’s already available/installed on the target computer, you can do that with a single command instead of deploying a whole script.

Select Actions > Execute remote process/command > Create/modify remote commands (logged output)
In the ‘Remote Process’ form, add a new row, give the cmdlet a title, and enter the actual cmdlet into the ‘command’ field. For the sake of this tutorial I’m just going to execute the ‘get-help’ cmdlet. Here’s the key part: Unfortunately you can’t simply enter ‘get-help’ like you would at the command line. In a future build of BatchPatch we will be adding direct support for PowerShell cmdlets so that will be able to execute cmdlets more intuitively, but for the time being you’ll need to enter the following syntax, substituting the cmdlet that you want to run for ‘get-help,’ of course:
cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "get-help"
Click OK after you’ve created the command.
Now highlight the hosts that you would like to execute the cmdlet on, and then select Actions > Execute remote process/command > Execute saved remote commands (logged output) > PowerShell Get-Help Cmdlet. Of course you’ll substitute your own title for ‘PowerShell Get-Help Cmdlet.’
The command completes and we see the output from the cmdlet in the ‘Remote Command Output Log’ column.

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

Advanced Script Integration with BatchPatch – Part 2

By Scott | Published: June 24, 2015

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

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

Create a ‘Local process/command’ in BatchPatch. Select Actions > Execute local process/command > Create/modify local commands.
Add the StoppedAutoService.vbs script to the grid.
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.

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

Posted in Blog, General, Tutorials | Tagged automatic services, remote script execution | Comments closed

Using BatchPatch with an Enterprise Web Proxy

By Scott | Published: June 15, 2015

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 proxy, windows update agent, Windows Updates | Comments closed

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

By Scott | Published: June 3, 2015

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.

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.

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.
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.
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 deploy software, quiet deployment, quiet installation, remote software deployment, silent deployment, silent installation, software deployment | Comments closed