Pushing Windows Updates to Remote Computers

By Scott | Published: September 25, 2018

BatchPatch provides multiple different options for applying Windows Updates to numerous target computers simultaneously. In all cases the process involves loading a list of computer names or IP addresses into a BatchPatch grid, selecting/highlighting the desired target computers in the grid, and then choosing an action from the BatchPatch Actions menu to execute on the selected computers.

BatchPatch can initiate the Windows update process on numerous computers simultaneously. They can be instructed to retrieve updates from your local WSUS, Microsoft’s public ‘Windows Update’ server, or Microsoft’s public ‘Microsoft Update’ server. Additionally, it’s possible to “push” the updates to target computers from the BatchPatch computer rather than having the target computers “pull” updates from an update server. And finally, updates can even be applied to target computers that do not have any interest access.

In BatchPatch’s default/normal mode, when BatchPatch triggers a group of target computers to initiate the download and installation of Windows updates, the target computers will search for updates on a local WSUS or on Microsoft’s public Windows update server, depending on the existing configuration of the target computers. In this default mode BatchPatch will utilize the pre-existing configuration on each target computer to determine where each target computer will search for updates to download and install. However, BatchPatch can also be instructed to override the target computer’s default configuration so that, for example, updates are downloaded directly from Microft’s public update server rather than from an internal/local WSUS server. The different Windows Update options that BatchPatch offers can be viewed under ‘Tools > Settings > Windows Update’

When BatchPatch’s ‘cached mode’ is enabled, the administrator is provided with even more options for distributing Windows updates to target computers. The following page goes into detail about all of the different cached mode options including ‘offline mode’ which provides functionality to deploy Windows updates to computers that don’t have internet access.

BatchPatch Cached Mode And Offline Windows Update

Excerpt:

  • When ‘cached mode’ is enabled, the computer that is running BatchPatch will download all updates directly to its own local repository. Once downloaded to BatchPatch’s local repository, BatchPatch will handle distributing the updates to target computers. Target computers will not download their own updates from Microsoft, thus significantly reducing the overall amount of internet bandwidth used to retrieve Windows Updates.

  • When ‘cached mode’ is enabled without also enabling ‘offline mode’, target computers still require internet access because each target computer will perform its own online search for updates against Microsoft’s server. However, the actual download process will take place on the BatchPatch computer, not on the target computers, thus saving internet bandwidth since any available update will only be downloaded one time by the BatchPatch computer rather than being downloaded one time by each target computer. Once BatchPatch has downloaded updates to its cache, it is able to distribute them to target computers.

  • When ‘offline mode’ is enabled in conjunction with ‘cached mode’ each target computer does an offline search for available security updates, utilizing the offline scan file (wsusscn2.cab) that Microsoft provides, which means that target computers do not need to have internet access. The actual update download process will only take place through the BatchPatch computer. Once BatchPatch has downloaded updates to its cache, it is able to distribute them to target computers. With ‘offline mode’ it is also possible to download updates on a BatchPatch computer that has internet access, and then manually move the entire update cache repository to a computer or network that has no internet access, enabling you to distribute Windows Updates security updates to computers on a completely offline network.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Appending DNS Suffixes to the Network Interface Instead of to Each Host in the BatchPatch Grid

By Scott | Published: September 17, 2018

In BatchPatch most users enter each host name into the grid without using the entire fully qualified domain name (FQDN) or IP address. In general, for most situations entering just the host names will be sufficient. However, many users have more complex network environments, and sometimes it won’t be sufficient to enter just the unqualified single-label host name without using the FQDN or IP address. This is because when there are multiple domains involved, and a given target computer is not on the same domain as the BatchPatch computer, Windows will not automatically know what the proper DNS suffix for the target computer is unless DNS suffixes have already been configured for the network interface of the BatchPatch computer. That is to say, in a multi-domain environment, it’s often the case that the network and systems administrators will configure group policy for the domain to include a list of DNS suffixes on every member computer’s network interface, so that if a user of any computer in the domain types, for example, “ping computerX” into a cmd prompt, Windows can try each of the DNS suffixes defined on the network interface to locate computerX. So, if the 3 DNS suffixes are:

domain1.com
domain2.com
domain3.com

Behind the scenes Windows can lookup computerx.domain1.com, computerx.domain2.com, and computerx.domain3.com until it finds a host (A) record in DNS for computerx. So let’s say computerx is actually computerx.domain3.com. When the DNS suffixes on the network interface are set properly, instead of having to enter computerx.domain3.com into BatchPatch, you can simply add the host as computerx.

You can add a DNS suffix to the search list on the BatchPatch computer directly/manually by doing the following:

Manual/direct DNS Suffix Additions/Modifications:

  1. In Windows select ‘Start > Run‘ and type control netconnections. Then click OK.
  2. In the control panel network connections window that appears, select the active network interface. Right-click on it and select Properties.
  3. In the Properties window select Internet Protocol Version 4 (TCP/IPv4), and then click the Properties button.
  4. In the following window that appears titled Internet Protocol Version 4 (TCP/IPv4) Properties, click the ‘Advanced’ button.
  5. In the ‘Advanced TCP/IP Settings‘ window, click on the DNS tab.
  6. In the DNS tab click the radio button that says ‘Append these DNS suffixes (in order):‘ and click ‘Add’ to add each desired DNS suffix.

Group Policy DNS Suffix Additions/Modifications:

If you want to apply the same DNS suffix list to many computers, then rather than applying them manually/directly, you should consider using Group Policy to apply them instead.

  1. On a computer that has the domain administrative tools installed, or on a domain controller, click Start > Programs > Administrative Tools > Group Policy Management
  2. In Group Policy Management, expand the forest and the domain in which you will apply Group Policy. Right-click Group Policy Objects, and then click New.
  3. In New GPO, type a name for the policy, and then click OK.
  4. Right-click the new policy that you created in Step 4, and then click Edit.
  5. In Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, and then click DNS Client.
  6. Right-click DNS Suffix Search List, click All Tasks, and then click Edit.
  7. On the DNS Suffix Search List Properties page, select Enabled. In the DNS Suffixes box, type the desired DNS suffixes. Click OK.
  8. In Group Policy Management, expand Group Policy Objects, and then select the policy that you created in Step 4. On the Scope tab, scope the policy so that it applies to the desired comptuers.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Automatically Apply Scheduled Tasks, Job Queues, Deployments, and Commands to New Rows with the Row Template Configurator

By Scott | Published: September 4, 2018

In the August 2018 release of BatchPatch, one of the new features that we added is the ‘Row Template Configurator’, which is available under ‘Grid > Row template configurator’. When you add new rows to a grid, sometimes it might be helpful to have the new rows be automatically configured with certain values such as scheduled task, job queue, deployment, remote or local command, etc. This is especially the case for users who have their grids configured to automatically synchronize with OUs/groups in Active Directory. After all, when you are automatically adding hosts/rows to a grid on a schedule, it’s common to also want other values automatically applied to the new hosts/rows too. Note, each grid can have its own row template configured/linked. This way if you want hosts that are added to one particular grid to be automatically populated with certain values, but you want hosts added to a different grid to be automatically populated with different values, you can do it very easily by applying a different row template to each grid. To use the row template configurator follow the instructions below.

  1. Start with a regular row in the main BatchPatch grid. Apply any values you want to the row, such as a job queue or scheduled task or deployment or remote command or local command etc. The idea here is that you’ll create a row in the main grid that contains all of the values/columns that you would like to be automatically included for new rows that are added to the grid.

  2. Once you have created a “template” row in the main grid, select ‘Grid > Row template configurator’ to launch the row template configurator form.

  3. With the row that you created in the main form still highlighted, click the button ‘Create/update row template based on selected row in main BatchPatch grid.

  4. After clicking the ‘Create/update…’ button you’ll see a single row appear the ‘Row Template’ grid. This row will contain any templatizable values from the main grid’s selected row. So if the main grid has a scheduled task configured, the row template will now show the same scheduled task values. Same goes for any job queues, deployments, commands, notes etc. They will all get included in the row template, and they will be visible in the new row template row that appears in the ‘Row Template Configurator’ form.

  5. Now that you have configured the row template values, you need to actually enable the row template for the grid. The default setting is ‘Disabled’ which means that if you add new rows/hosts to this grid, nothing special will occur. But as soon as you switch the radio button to ‘Enabled’ and click OK, then all new rows added to the grid will automatically receive any values that were set in the row template.

  6. So now if you look at my existing grid I have ‘host1’ showing a scheduled task configured, but host2, host3, host4, and host5 show nothing. Since I’ve just enabled a new row template for the grid, based on host1, watch what happens when I add more hosts to the grid.

  7. All the newly added rows/hosts look identical to the row for host1. This is all thanks to the row template that we enabled for this grid.

We know that many of you have been looking forward to this new functionality. As always, if you have any comments or suggestions, don’t hesitate to contact us to let us know.

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

Windows Update Management Tools

By Scott | Published: August 30, 2018

When it comes to performing Windows updates on an entire network of computers, there are a number of things that frequently need to be addressed, depending on the size of the environment, the number of actual target systems, the service-level agreements in place, the length and frequency of the maintenance windows, and so on. When we first started working on BatchPatch one of our goals was to try to address the needs of technology administrators in a tight package that would enable scaling from small to large environments without requiring a hefty infrastructure just to run the patching tools, and without being difficult or clunky to operate. It seems like one of the common problems that sysadmins regularly face when it comes to software management tools is that if they want more features and functionality or if they have to manage a larger environment, then the software options out there for them tend to be extremely expensive or very difficult to install or challenging to learn to operate or just plain clunky and unappealing to use. And sometimes the management systems might even require numerous servers of their own, which only adds to the expense.

In BatchPatch we feel we’ve done a good job at balancing all of the elements in a package that is very small and efficient, inexpensive, and very feature-packed. There are features in BatchPatch that “just work” that you simply will not find anywhere else. And many of the features that do find somewhere else were directly lifted from BatchPatch anyway. However, we believe even with that being the case, the value offering that BatchPatch provides simply cannot be matched. In the large majority of cases BatchPatch pays for itself in time saved usually in just the first or second use.

Today let’s review, at a basic level, how to use BatchPatch to accomplish your Windows update and general patch management tasks. The main BatchPatch interface is a grid, similar to a spreadsheet, that allows you to simply populate it with a list of target servers (or workstations, laptops, etc). There is no complex or time consuming process for adding new hosts, and you don’t have to wait around to deploy a persistent agent to targets. You can simply type the name or IP of computer, and then you’ll see it appears in the grid instantly. Alternatively you can query your Active Directory OUs and groups as another method to populate the grid, and of course you can always drag and drop (or use ‘File > Open’ or ‘File > Import’) to get an existing list of computers into the grid from a text file, CSV file, or a similar delimited file. Once you have hosts in the grid, you can simply highlight/select the desired ones, and then choose an option to execute from the ‘Actions’ menu or the ‘right-click’ menu. So in the screenshot below you can see that with the selected hosts I am about to choose ‘Download and install updates + reboot if required.’ All of the selected hosts will begin processing updates right away, and BatchPatch will monitor their statuses during the entire process, showing the completion percentage of the download and then the completion percentage of the install. Then finally when the update installation has completed, BatchPatch will initiate and monitor the reboot process until the computer is back online. It’s just as simple as that to execute virtually all of the different available actions/options in BatchPatch.

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

Deploying Windows Updates and Third Party Software Updates Quickly and Easily to Numerous Computers

By Scott | Published: August 20, 2018

OK, so you have a lot of computers on your network, and you need a way to quickly install Windows Updates and/or 3rd party software updates on all computers without having to connect to each computer individually to initiate and monitor the install. BatchPatch to the rescue!

If you haven’t already done so, I would encourage you to download the free BatchPatch evaluation version. While the evaluation is limited to a maximum of 4 simultaneous target hosts, there is no time limit, and other features in the app are fully functional. This gives you a very simple way to try BatchPatch at no cost, configure your environment to work with it, and then take your time to decide if you want to purchase licenses.

Assuming that this is your first time trying the application, you’ll want to review the ‘Getting Started‘ posting to see how to configure your environment to work with BatchPatch. This tutorial goes through all of the elements that need to be addressed for setting up BatchPatch, from permissions to firewalls, though in many environments BatchPatch will just work right out of the box with no additional configuration required.

After you get the basics down, like installing Windows Updates remotely, and deploying software to numerous computers, you can test out the more advanced features like the job queue, the task scheduler, and the advanced multi-row queue sequence.

Hopefully you’ll not only begin to see just how simple it is to use BatchPatch to get your entire network of computers updated, regardless of whether you have an internal WSUS or use Windows Update or Microsoft Update, regardless of whether your computers are internet-connected or not, and even if you simply don’t have a lot of free time on your hands! BatchPatch allows you to truly minimize the amount of time and effort needed to patch computers. I continue to be amazed by how many customers have written notes to us to let us know that BatchPatch paid for itself in just the first few hours of usage based on how many man-hours it saves.

To review the full list of features and functionality that BatchPatch offers, please check out the home page. If you have any questions, problems, or concerns, don’t hesitate to reach out to us.

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

UAC Behavior with Remote WMI Connections in Non-Domain (Workgroup) Environments

By Scott | Published: August 15, 2018

When you are working in a network environment without a domain– that is to say there are no domain controllers and no member servers because all computers are simply part of a workgroup, authentication can be a challenge when trying to perform operations remotely. Generally speaking, if you have a network with enough computers where there is a need to perform any tasks remotely, you should ask yourself “Why is there no domain established yet?” because realistically there probably ought to be one. However, let’s assume that for whatever reason there is not already a domain and there is not going to be a domain, but you have tasks to perform on remote computers, then what?

OK, so the main issue you need to be aware of when dealing with remote WMI connections is User Account Control (UAC). In a workgroup/non-domain environment there will never be domain logon accounts, so all accounts that one needs to deal with are going to be local accounts. However, when working with local accounts, in order to execute many (not all) remote WMI queries or methods, remote UAC actually needs to be disabled on each target computer that is being operated on.

Disabling Remote UAC

Remote UAC is controlled by a single registry value. If the local account you are using to run the query (or in the case of BatchPatch, the account you are using to run BatchPatch or the account that you specify in the ‘alternate credentials’ field in 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 in order to disable remote UAC the following registry DWORD must be set to 1 on the target computers. If the DWORD does not exist or is set to 0, then remote UAC is enabled, and you will generally get ‘Access Denied’ when trying to perform a remote WMI query. To disable remote UAC, set the value of the following registry DWORD to 1. If the DWORD does not exist, then you must create it:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

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

Disabling Admin-Approval Mode (Enabling Full-Token Mode) for the Built-in Administrator Account

Unfortunately that’s not everything. What if you are using THE built-in administrator account (as opposed to a regular named local account that is a member of the local administrators group on the target computers)? If the local account you are using to execute the WMI query/method is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. If the DWORD does not exist, then you must create it. When this DWORD is set to 0, the built-in administrator account is set to full-token mode, and WMI queries (including WMI queries executed through BatchPatch) will work propertly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most remote WMI actions (including most BatchPatch actions) from completing successfully for those target computers:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken

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

Microsoft discusses remote UAC in more detail here. We discuss more about authentication options for BatchPatch here.

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

Removing a Microsoft Office Update from Multiple Computers

By Scott | Published: July 31, 2018

This is one of those situations where something that seems like it ought to be very quick and simple is unfortunately not so quick and not so simple. The good news it’s also not *that* difficult, but there’s no question that it’s a pain and it takes a bit of effort.

It used to be the case that if you needed to remove a Microsoft Office Update such as KBXXXXXX that you could remove it just like you can remove any other Windows Update. In BatchPatch we have a couple of built-in options for executing the update removal process of a particular Windows Update that you can access under ‘Actions > Windows Updates > Uninstall individual update…‘ To use those menu items all you need is the KB number of the update that you want to remove.

Unfortunately for a while now the above-mentioned built-in commands for removing individual updates is only successful for standard Windows operating system updates. Microsoft Office updates, on the other hand, require a different removal command that unfortunately involves some manual digging.

The command line syntax options for removing a MSOffice update are as follows, but you have to substitute the correct Office GUID and Patch GUID values into your command, and this is what makes the process frustrating/tedious:

msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN
msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN REBOOT=REALLYSUPPRESS

This Microsoft Blog article explains the process for locating the correct GUIDs in the registry for the patch that you wish to uninstall.

After you find the appropriate GUIDs, you can form the actual command to use to remove the update. So, for example, the following command is an example of what your command will actually look like, as I have inserted actual GUID values, but as previously mentioned, you’ll need to find the GUIDs for the product and patch that you are removing.

c:\windows\system32\msiexec.exe /package {90140000-0012-0000-1000-0000000FF1CE} /uninstall {B23AAF3E-F931-4C72-8D96-7E58363A3D12} /qn

Once you have determined the proper syntax and have run it successfully on your test computer, you may insert it into a ‘Remote Command’ in BatchPatch. Highlight the desired target computer rows in the BatchPatch grid. Then select ‘Actions > Execute remote process/command > Create/modify remote command 1‘

Paste your command into the field, as illustrated in the screenshot above. Then either ‘Execute’ the command immediately or choose ‘Apply…’ to execute it later. Another option for executing at a later time/date is to hard-code the command into the BatchPatch menu by using ‘Actions > Execute remote process/command > Create/modify remote commands‘ In this case I have used ‘Apply…’ to apply the commands to each of the highlighted rows, which you can see in the screenshot below.

Now I can execute the applied command for each/every row by just selecting the rows that I want to include, and then clicking ‘Actions > Execute remote process/command > Execute remote command 1‘

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

Windows Server Patching Tools

By Scott | Published: July 25, 2018

We all know that keeping servers up to date is one of the most important aspects of keeping a secure environment. At one point or another every systems administrator is faced with the challenge of having to apply updates to numerous remote servers on a network. We have all been through the tedious process of manually connecting on an individual basis to each target computer, then applying updates or configuration changes, rebooting the computer, waiting 10 minutes, then checking to verify the computer did in fact reboot and that it did come back online after reboot. Multiply this process by a dozen or a hundred or even one thousand target computers, and all of a sudden the process becomes unwieldy, time-consuming, and downright stressful. The more computers that one is managing, the more quickly it becomes difficult to successfully keep track of the status of each target computer during such a process. Wouldn’t it be easier if we could just have a single console to manage all of the target computers, regardless of whether it’s 10, 20, 50, or 1000 machines?

BatchPatch was designed to make life easy for the systems administrators and engineers of the world. It enables the administrator to apply updates or make settings changes or to run scripts or applications remotely to numerous computers, simultaneously. No longer do you have to keep track of each machine individually with numerous remote desktop windows and ping windows etc. Instead you can just launch BatchPatch, add the desired target computers, select the desired action, and then just sit back and watch all target computers perform the specified action. You can install Windows Updates, deploy third party software or updates, deploy registry keys, run custom scripts, gather information for inventory or other purposes, etc. Or you can string together numerous actions into complete ‘job queues’ for single-click automation efforts.

In addition to the standard features mentioned above, BatchPatch also has unique sequencing functionality that enables the administrator to be able to create complex sequences of updates, reboots and deployments that involve numerous computers. Computers can be triggered by order in the sequence so that only certain machines are offline at any given time. The automation options are very cool, and they allow you to choreograph a “dance” of reboots and updates unlike anything you have seen before. With BatchPatch there is a surprising amount of functionality packaged into a very small executable. To read about all of the features that BatchPatch has to offer, please have a look at BatchPatch Home Page

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

Patch and Update Automation with Multiple Dependent Systems

By Scott | Published: July 18, 2018

I have posted articles and tutorials in the past on the BatchPatch feature known as the ‘Advanced multi-row queue sequence.‘ In fact there is a really thorough tutorial here that demonstrates how to integrate custom scripts into your job queues and multi-row queue sequences, which essentially enables the administrator to incorporate features/functionality into BatchPatch that might not exist already in a single-click menu item.

Today I’d like to discuss a bit more some thoughts on what an ‘Advanced multi-row queue sequence’ might look like in a different environment. For example, let’s say that you want to have one computer check for available updates and install them if there are any, but if there aren’t any, then you want the next server in the queue to do the same. Furthermore, if there *are* updates available for installation, you want to download and install them and reboot the computer, and then you want the computer to check again to see if after reboot any new updates became available. And again you want to then install any available updates, but if there are none available you want the next host in the advanced multi-row queue sequence to begin working. Additionally, if updates are available and installed and the host is then rebooted, you want to perform a verification check on that server to make sure that it is functioning properly before moving on to the next host in the sequence. There are surely multiple ways to accomplish something like this, but below I’m going to provide one possible way to accomplish this.

First, if you are not familiar with ‘Advanced multi-row queue sequence’ execution, please review the following links, which all demonstrate how to use it.

Advanced Multi Row Queue Sequence Video Tutorial

Virtual Machine Guest Host Update and Reboot Sequence Automation

Advanced Multi Row Queue Sequence Contingent Operations with Custom Scripts

Now, what if we apply the following job queue to each of the hosts in our advanced multi-row queue sequence? This allows us to have each host do multiple cycles of ‘download/install/reboot’ along with running a custom script to verify that our target is functioning in the way that we want … i.e. in addition to being online, which BatchPatch checks for, the custom script can check to see that the server is providing whatever service it provides. If the verification script finds that it is providing the service, the script returns 0. If the verification script finds that it is not providing the service, the script returns a non-0 integer. This enables us to use the two following special job queue items:

Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors

So, if we apply the queue below to three hosts in the BatchPatch grid, for example. And if include those three hosts in the advanced multi-row queue sequence, such that each host represents one sequence position, which means that each host will execute the complete job queue below in sequence, so that no host goes offline at the same time, and so that if one host fails the verification script, then no other hosts will be acted upon in any way, then we can accomplish a pretty solid automation routine.

Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Check for available updates
Terminate queue if previous 'Check for available updates' finds 0 updates
Download and install updates + reboot if required
Wait 10 minutes
Wait for host to be detected online
*Run a custom remote verification script/deployment that returns 0 if successful/OK, non-0 if unsuccessful/notOK
Abort advanced multi-row sequence if previous action fails/errors
Terminate queue if previous action fails/errors
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Does BatchPatch Work Over a VPN Connection?

By Scott | Published: July 4, 2018

One of the common questions we regularly receive is will BatchPatch be able to work over a VPN? BatchPatch *can* work over a VPN connection, but the real question is will BatchPatch work over *your* VPN connection? It really depends on how your VPN and VPN firewall are configured, not on how BatchPatch is configured.

In corporate environments we usually see two ways that VPNs are deployed. In one configuration a site-to-site VPN configuration might be used to effectively connect a remote office to a corporate headquarters in order for the users in the remote office to be able to connect to all the resources in the corporate headquarters just as if those users were connected directly to the LAN in the headquarters office. Typically in this kind of site-to-site VPN configuration there is little to no firewalling between the two offices, because the goal is for the remote office users to have an identical experience to the users who are directly connected to the main LAN back at headquarters. When a firewall is used to block ports or services between sites, the experience for remote users is quickly degraded because they don’t get the same unfettered access to resources that users in headquarters get. This diminished experience in turn makes it harder, sometimes, for remote users to complete their duties. Similarly, if there is significant firewalling of ports or services between the two offices, IT administrators who work in the main office might not be able to perform all of the duties that they need to perform on remote office computers. Furthermore, in the typical site-to-site VPN setup, users do not have to run special VPN client software on their computers. In fact, when they are plugged into the LAN in the remote office, they should have a seamless experience in which they cannot even tell that there is any difference to be connected to the main office. Plugging a computer into either the home office or the remote office should yield the same experience for the end user.

In the second type of configuration, instead of setting up a complete site-to-site VPN with little to no restrictions between the two sites, remote users might install a VPN client software on their computers. Whenever they want or need to connect to services in the main corporate headquarters they simply launch the VPN client software, click the ‘connect’ button, and then the VPN software establishes a tunnel to the corporate LAN. Once connected, the users are able to access various services that have been pre-configured by the IT department. In this case where VPN client software is used, it seems to be much more common in corporate environments for firewall configurations to be more tightly locked down such that only designated sites and services are made available to the end users who connect through the VPN. Frequently in this type of VPN configuration, if an application has not bee pre-approved and pre-configured to work across the tunnel, it won’t. And similarly, IT staff frequently are not able to connect from the main office to the VPN-connected client computers in order to manage them in the same way that they would be able to manage the computers that are directly connected to the corporate LAN. But again, it all depends on how the firewalls are configured.

So, when it comes to BatchPatch, if you’re not sure if it will work over your VPN, here is what I would suggest:

1. Download the free evaluation version of BatchPatch from https://batchpatch.com/download

2. Test BatchPatch on your main LAN without involving any VPNs. After all, if you can’t get BatchPatch working without using the VPN, then you’re certainly not going to get it working over the VPN. Please carefully review the ‘Getting Started‘ page to learn how to configure your environment to work with BatchPatch.

3. Once you have BatchPatch working on your main LAN, then go ahead and test it over the VPN. If it doesn’t work, visit the administrator or engineer who controls the VPN and firewall devices in your environment, and work with him or her to get everything configured for BatchPatch to function properly. In some cases if corporate policy prevents them from modifying the existing VPN to allow BatchPatch to function, they might still be willing or able to configure a specially permissioned VPN that is strictly for IT staff and that has less restrictions in place so that software like BatchPatch can be allowed to work over it.

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