How to Run a Remote Task Immediately After a Computer is Detected Online

By Scott | Published: December 20, 2023

BatchPatch has functionality built-in that lets you use the Task Scheduler to schedule tasks to run on target computers immediately after those target computers are detected online. This can be useful for computers that are often taken off the network. If you need to deploy an update to such a computer, it might be good to do it the moment it appears back on the network.

In the BatchPatch Task Scheduler there is a checkbox option for Run task immediately upon detecting target computer online

To schedule a task, select the desired target hosts in the grid, and then click on Actions > Task scheduler > Create/modify scheduled task. Then in the dialog that appears, select the desired task from the drop-down menu, and click on the box that says Run task immediately upon detecting target computer online. Then make sure the scheduler is enabled by clicking on the red clock/timer icon in the upper-right corner of the BatchPatch window to toggle it to green/on/enabled. Note: Red is disabled; Green is enabled.

Once the scheduler is turned on, BatchPatch will check once per minute if any target computer that has been set to Run task immediately upon detecting target computer online is currently detectable online. If the target host is detected on the network, and if BatchPatch is able to reach it to trigger the task to execute, BatchPatch will proceed and launch the scheduled task. If not, it will wait a minute and then try again. It will keep doing this check every minute until eventually the computer is detected online and the task is executed.

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

How to Launch an Application Interactively on Remote Computers

By Scott | Published: November 1, 2023

Occasionally someone wants to launch an application interactively on target computers. That is, they want to use BatchPatch to trigger the execution of an application that will appear on the desktop of the currently logged-on user of the target system(s). This can be both simple and not-so-simple to do at the same time. There are a few things to consider:

  1. These instructions were created on Windows 10 machines using PsExec version 2.40. These instructions should work with PsExec versions going back to v2.32, but versions of PsExec that are older than 2.32 behave differently. Also older versions of Windows behave differently. The instructions might have to be altered to work with older versions of PsExec and/or older versions of Windows.

  2. Set your Remote Execution Context (Tools > Settings > Remote Execution) in BatchPatch to be either SYSTEM or Elevated token, but leave Interactive UNticked for this operation. IMPORTANT: Normally with PsExec version 2.32 or newer you can only use Elevated token if Interactive is also checked. However, for this particular tutorial to work, Interactive needs to be UNticked, so that we can specify the Interactive -i switch manually in the command itself. If you use SYSTEM, the command will be executed as SYSTEM. If you use Elevated token, the command will be executed as the user you specify in the Alternate Credentials field for the given row in BatchPatch. If no alternate credentials are specified, the command will execute as the user that launched BatchPatch. In all cases, the user account that executes the command needs to be a member of the local administrators group of the target computer(s).

  3. Here is where things get not-so-simple, especially if you want to an application to be launched interactively on many remote computers. To do this, we need to know the session ID of the logged-on user of the target system. The session ID is not guaranteed to be the same for any particular computer or for any particular logon session of a particular computer, which is why this becomes not-so-simple if you want this to be successful on numerous remote computers. However, since the session ID will typically be 1 or 2, or perhaps 3, you can probably fudge it in most cases without actually looking up the session ID for each target. I’ll explain in a moment, but first if you want to identify the correct session ID, one way to do it is to look at Task Manager’s Details tab on a target computer.

    Launch Task Manager and go to the Details tab, then right click on the column headers and choose Select Columns.

    Then tickSession ID in the list of columns to make that columns visible.

    With the Session ID visible you can now figure out the session ID of the desired user. In this case I’m logged on as testAdmin, and that account is running in session 1. Oftentimes I will find the interactive user is logged-on to session 2, but today for whatever reason it’s session 1.

  4. In order for me to launch Google Chrome remotely with BatchPatch so that it appears visible to the interactive/logged-on user of the target system, I have to specify the correct session ID in the command that I execute in BatchPatch. In a BatchPatch Remote Command I am using the following syntax: 
    -d -i 1 "C:\Program Files\Google\Chrome\Application\chrome.exe"

    The -d specifies that the command should be executed but that PsExec (and consequently BatchPatch) should NOT wait for the remote process to terminate. The -i 1 specifies that the command should run interactively in session 1 on the target system. Adjust this session ID number accordingly. The path to the executable has to exist on the target system. So, in this case I’m launching Chrome because Chrome has already been installed on the target system, and I’m specifying the correct path to the chrome.exe.

    When this is all done correctly, the exit code you see in BatchPatch will be the process ID (PID) of the process that is launched on the target. In the case of Google Chrome there will be multiple processes launched because when chrome.exe is launched, it spawns multiple other processes.

    If you see exit code 2, it likely means that you specified an invalid session ID. You can use that information to your advantage because instead of looking up the proper session ID manually for every target computer, you can probably just try session ID 1 first, and then for any commands that return exit code 2, next try session ID 2, and then finally after that maybe even try session ID 3.

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

Using BatchPatch to Rename the Windows SoftwareDistribution Folder on Target Computers

By Scott | Published: August 22, 2023

In some cases when you’re dealing with Windows Update problems on a target computer, you might find recommendations on the web that suggest to rename the Windows SoftwareDistribution folder ( C:\Windows\SoftwareDistribution ) in order to reset the Windows Update components. The purpose of renaming that folder is to cause Windows to re-create it from scratch. The process is to stop the Windows Update service, then rename or delete the folder, and then start the Windows Update service again. When the Windows Update service starts up again and sees that there is no longer a C:\Windows\SoftwareDistribution folder (because it has been renamed to something like C:\Windows\SoftwareDistribution.old ), Windows then just creates a brand new C:\Windows\SoftwareDistribution folder. The reason why it’s recommended to rename rather than delete the folder initially is because if you rename it, you could then always revert back to that renamed folder at any time. Whereas if you delete it altogether, there will be no going back, of course. This most likely isn’t going to be the end of the world in most situations, but at the very least when you trigger Windows to create a new SoftwareDistribution folder, you’re going to lose any visibility into update history on that computer since the update history database is stored in that SoftwareDistribution folder. That said, I’m not making an explicit recommendation here to perform this operation. I’m just explaining to you how you can do it from within BatchPatch if you’ve decided, at your own risk, to perform this operation.

Recently someone asked us how to perform this operation from within BatchPatch. First let me say that in general, if you’re going to be renaming the SoftwareDistribution folder, it doesn’t really strike me as an operation that should necessarily be done from within BatchPatch. I say this only because typically you’re going to be troubleshooting Windows Update issues on just a single computer at a time. And since BatchPatch really shines when you need to perform an action on numerous computers (as opposed to on just one computer), executing this operation from within BatchPatch on a single computer doesn’t solve a particular problem since it’s easy enough to just manually perform the operation on the machine that you’re troubleshooting. However, there might be some edge cases where you would want to perform this operation on numerous target computers, or you might find yourself performing this operation repeatedly to the point where you want to have it hard-coded into BatchPatch for one-click execution, like the customer who recently asked us how to do it. If you want to perform the SoftwareDistribution rename operations from within BatchPatch, here is how:

  1. In BatchPatch create a Remote Command by selecting Actions > Execute remote process/command > Create/modify remote commands
  2. Create a command with the following syntax: 
    NET STOP wuauserv & MOVE C:\Windows\SoftwareDistribution C:\Windows\SoftwareDistribution.old & NET START wuauserv

  3. After you’ve created the command it will become available to execute under Actions > Execute remote process/command > Execute saved remote commands like in the screenshot below. You can then simply select the desired target computers in your grid, and then click on the new menu item that you just created for this action. BatchPatch will then trigger the target computer to stop the Windows Update service, rename the SoftwareDistribution folder to SoftwareDistribution.old, and then finally start the Windows Update service again.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Using BatchPatch to Update Google Chrome on Remote Computers

By Scott | Published: July 7, 2023

The process for updating Google Chrome remotely, using BatchPatch, is quick and painless.

  1. Create a BatchPatch ‘Remote Command’ by highlighting the desired target hosts and then selecting Actions > Execute remote process/command > Create/modify remote command 1
  2. Input the remote command syntax exactly as follows: 
    "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /ua /installsource scheduler

  3. When you click the Execute button, BatchPatch will run the command on the highlighted target computers. After the above command completes on a given computer, Chrome needs to be restarted, and then it will be on the latest version. You could optionally forcibly close Chrome remotely using another remote command: 
    Taskkill /F /IM "chrome.exe"
  4. An alternative to running the one (or two) remote commands above would be to put both together into a text file with a .cmd or .bat extension to make it into a complete script. Put each command on its own line like this: 
    "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /ua /installsource scheduler
Taskkill /F /IM "chrome.exe"

    Then instead of using BatchPatch remote commands, just use a single BatchPatch deployment (Actions > Deploy) to deploy the .bat/.cmd file that you created. When you execute the deployment, the .bat/.cmd will be copied to the target computers and then executed, after which Chrome will be updated and closed so that next time its launched it will be on the latest version.

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

BatchPatch Error 1611:5. Failure

By Scott | Published: June 5, 2023

99% of the time if you see 1611:5. Failure appear in BatchPatch, it’s due to PsExec getting blocked by your anti-virus/security software. Sophos seems to be the primary culprit for when we get reports of this failure/error.

To resolve this, generally you’ll just need to add an exclusion in your AV/Security app for PsExec.exe that runs on the BatchPatch computer and/or PsExeSvc.exe that runs on the target computer. Please check in your BatchPatch under Tools > Settings > Remote Execution for the correct filenames and filepaths that will need to be excluded or allow-listed in your anti-virus server.

Take note of the two filepaths outlined in the screenshot above. The first one is the path where PsExec.exe is running on the BatchPatch computer. The second one is the remote service name of the PsExec service that runs on the target computer. Also note the checkbox that I have ticked for Append source computer name to remote service name. This means that when the remote service runs on target computers, it will run as BatchPatchExeSvc-BPSourceComputerNameGoesHere.exe

That said, since my BatchPatch computer is named BPSERVER, and since my remote service name is set to BatchPatchExeSvc with the checkbox ticked for Append source computer name to remote service name, on the target computers it will run as C:\Windows\BatchPatchExeSvc-BPSERVER.exe. So if I were encountering 1611:5. Failure, I would make exclusions in my Sophos server for C:\Windows\System32\PsExec_2.4.exe for the BatchPatch computer, and also for C:\Windows\BatchPatchExeSvc-BPSERVER.exe for the target computer(s).

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

BatchPatch Custom Email Notifications

By Scott | Published: May 2, 2023

Recently someone asked if it’s possible to configure BatchPatch to send an email notification 15 minutes before the patching maintenance begins. Here is how to do it:

  1. If you haven’t already done so, you’ll need to configure the outgoing email account details under Tools > Settings > Email Notifications

  2. Next, setup a custom email notification by clicking on Actions > Email notification > Create/modify email notifications. Fill out the fields, as desired. If you put $grid into the attachment field, a copy of the grid will be included as an attachment on the email. Click the double-right arrow to save the notification.

  3. Now you can setup your scheduled task to run at the desired time (15 minutes before the maintenance) to send out the custom email notification that you created in the previous step. Alternatively you could add the email notification to a job queue, if desired. However, in this example I’ve created a “dummy” row in the grid that serves no purpose except to send the email notification as a scheduled task. I select it and then click Actions > Task scheduler > Create/modify scheduled task

  4. In the Task drop-down I can now find and select the custom email notification that I created earlier.

  5. Next set the desired run date and time. Then click OK.

  6. Lastly, since this will run as a scheduled task, I need to make sure to enable the task scheduler by clicking the red timer/clock icon in the upper right corner of the BatchPatch window so that it turns green, which means it’s enabled. Alternatively, if you have the BatchPatch service instance installed/running, then you can just save the grid and send it to the BatchPatch service instance where the scheduler is always running.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

BatchPatch March 2023 New Release

By Scott | Published: April 3, 2023

On Friday we published a new version of BatchPatch. In addition to numerous smaller fixes and improvements (you can view them in the app under Help > Check for updates > View change log), we added more grid encryption options which are all available under File > Protection Options. For those of you using the BatchPatch ‘Run-As-Service’ feature, you can now use it with grids that are encrypted with any of the key-based encryption options.

The protection options in this form control how the grid file is protected when it’s saved to disk. These protection options are particularly relevant for users who are specifying ‘Alternate Credentials’ in their grids.

The most secure way to operate BatchPatch is with ‘Integrated Security’, where the account that is used to run BatchPatch is the same account that is granted permissions on target computers for BatchPatch to perform actions. When integrated security is used there are no credentials involved because the BatchPatch application will run in the context of the permissioned user, so no credentials have to be specified in the application for it to work. However, for BatchPatch users who are specifying alternate credentials for any rows in their grids, those credentials are saved in the .bps grid file when you save the grid file to disk (using File > Save), so when using alternate credentials it’s very important to protect those files.

To read more about ‘Integrated Security’ vs ‘Alternate Credentials’, as well as the security ramifications of using ‘Alternate Credentials’ please see:
Using Alternate Logon Credentials in BatchPatch

==================================================================================

Grid Protection Options:

Obfuscation – Legacy password field obfuscation ( Deprecated ):

This legacy mode is deprecated and is only available now for backward compatibility with older versions. In this mode each password in a grid’s password column is individually obfuscated when saved to a .bps/.bpt file. This obfuscation mode does NOT provide any meaningful security. Proceed with caution. Use encryption over obfuscation whenever possible.

=============================================

Obfuscation – Standard credentials field obfuscation:

In this mode each username and password in a grid’s credentials columns are individually obfuscated when saved to a .bps/.bpt file. This obfuscation mode does NOT provide any meaningful security. Proceed with caution. Use encryption over obfuscation whenever possible.

=============================================

Encryption – Credentials field encryption:

In this mode each username and password in a grid’s credentials columns are individually encrypted with AES-256 when saved to a .bps/.bpt file. The encryption/decryption key is randomly generated by BatchPatch per-user, per-computer and stored locally on this BatchPatch computer, encrypted, using the Windows Data Protection API (DPAPI). Files saved in this mode are tied to both the user and the computer where they are created. That is, these files’ credentials fields cannot be decrypted/loaded into a BatchPatch instance that’s running under a different user account or on a different computer (unless you first export the encryption key from this instance of BatchPatch and then import the key into the other user’s/computer’s BatchPatch instance). Despite any encryption applied to the credentials in grids saved with this mode, we still always recommend exercising care and caution when handling files that contain sensitive passwords. Consider using additional layers of encryption as well as limiting access to these files. Also, consider making a backup of the encryption key and storing it securely (NOT on this computer). If there is a failure or accident of some kind that causes the stored key to be lost or corrupted, you will not be able to decrypt the credentials saved in the grid. Of course this isn’t necessarily critical since re-populating the passwords in the grid or creating a new grid will always be possible, but it may cause a loss in time and productivity. Proceed accordingly.

=============================================

Encryption – Whole file encryption:

In this mode the entire grid is encrypted with AES-256 when saved to a .bps/.bpt file. The encryption/decryption key is randomly generated by BatchPatch per-user, per-computer and stored locally on this BatchPatch computer, encrypted, using the Windows Data Protection API (DPAPI). Files saved in this mode are tied to both the user and the computer where they are created. That is, these files cannot be decrypted/loaded into a BatchPatch instance that’s running under a different user account or on a different computer (unless you first export the encryption
key from this instance of BatchPatch and then import the key into the other user’s/computer’s BatchPatch instance). Despite any encryption applied to the grids saved with this mode, we still always recommend exercising care and caution when handling files that contain sensitive passwords. Consider using additional layers of encryption as well as limiting access to these files. Also, consider making a backup of the encryption key and storing it securely (NOT on this computer). If there is a failure or accident of some kind that causes the stored key to be lost or corrupted, you will not be able to decrypt the grid. Of course this isn’t necessarily critical since creating a new grid will always be possible, but it may cause a loss in time and productivity. Proceed accordingly.

=============================================

PRIMARY vs AUXILIARY key / Sharing encrypted grids

When BatchPatch is first launched it randomly generates a PRIMARY encryption key plus an AUXILIARY encryption key. There is no functional difference in behavior between the PRIMARY and AUXILIARY versions of the same mode. However, we include an AUXILIARY key option for each encryption mode so that users who want to share encrypted grids can do so without sharing their PRIMARY keys. If you want to regularly share encrypted grids with a co-worker, you can do this by sharing your AUXILIARY key. Export it and then have your co-worker import it into his/her BatchPatch instance as his/her AUXILIARY key. After that you’ll both have identical AUXILIARY keys, and thus you’ll be able to share grids that you have encrypted with your AUXILIARY key. Grids that are intended to be kept private should be encrypted with your PRIMARY key so that they are only decryptable by your own logon account.

=============================================

Encryption – Whole file encryption – Password-based key derivation:

In this mode the entire grid is encrypted with AES-256 when saved to a .bps/.bpt file. The encryption/decryption key is derived per grid, using PBKDF2, from the password that you set for each grid that is saved in this mode. Despite any encryption applied to the grids saved with this mode, we still always recommend exercising care and caution when handling files that contain sensitive passwords. Consider using additional layers of encryption as well as limiting access to these files. Note, in this mode since the encryption key used to encrypt/decrypt the file is derived from a password that you specify, it’s important to choose a password wisely. Password-based encryption usually does not provide the same level of security as key-based encryption since the average person tends to create and/or use relatively weak passwords that are more easily guessable by brute-force (attempting a large number of passwords until finding the correct one that successfully performs decryption of the encrypted data). Since the strength of the encryption in password-based encryption is limited by the strength of the password, choosing a unique, long, unpredictable/random password provides the most protection against brute-force.

=============================================

Export/import key:

When using the PRIMARY/AUXILIARY key modes, consider exporting the encryption key as a backup and storing it securely (NOT on this computer) because if any situation arises where the locally stored key becomes damaged or lost (BatchPatch computer dies or is replaced, corruption occurs, user profile is deleted from this computer, etc) you won’t be able to decrypt anything that was encrypted with the key. In many environments this might not be critical since creating a new grid from scratch will always be an option, but it may cause a loss in time and productivity, so proceed accordingly. In the case of ‘Credentials field encryption’, only the credentials fields will be unable to be decrypted, but the rest of the file will remain as clear text. However, in the case of ‘Whole file encryption’, the entire file will be unable to be decrypted and will therefore be completely unusable.

=============================================

Windows Data Protection API (DPAPI):

BatchPatch uses the DPAPI to protect the locally stored keys on disk. The DPAPI provides a reversible form of encryption that is used to store secrets on disk. These secrets are generally protected by the credentials of the user logon account under which they are stored. If an attacker is able to run code in the context of a user that stored secrets using the DPAPI, the attacker will then also have the ability to decrypt those secrets if A, the attacker locates those DPAPI-protected secrets on disk, and if B, the attacker has enough prior technical knowledge of the specific application that performed the DPAPI-protect operations in order to be able to successfully decrypt those protected secrets.

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

Silently Install Patches Remotely and Automatically Reboot Many Computers

By Scott | Published: February 16, 2023

If you’re new to BatchPatch you probably arrived at this page after some web searching or maybe through a link posted by someone in an IT-related forum. Presumably you’re looking for a tool that will enable you to easily install Windows Updates as well as third-party software and patches on a group of remote computers quickly and efficiently. Well, you’ve come to the right place. BatchPatch makes it easy to do remote updates, remote deployments, remote installations, remote script executions, remote command executions, and pretty much any similar task that you can think of. BatchPatch is perhaps the simplest and least expensive option for executing a task on numerous computers all at the same time. It gives you a high degree of power and control without requiring a lot of overhead, resources, human-power, or time.

Some of the basic functionality that BatchPatch offers includes options for remotely checking which Windows updates are needed by your computers, or downloading and/or installing Windows updates across an entire network of computers with a single click. BatchPatch also provides capability for retrieving information from computers into a consolidated grid view. For example, if you need to quickly identify which of your computers has a particular registry value set, or which computers have a particular OS version installed, or if you just need to see the last bootup time of your computers, BatchPatch provides functionality for that. If you need to deploy a 3rd-party application to your network of computers, you can use BatchPatch to do that very easily too. All of the actions in BatchPatch can also be scheduled to execute when you’re asleep, if desired, for maximum convenience. However, for networks with critical uptime requirements we generally still recommend watching over your jobs in real-time because even if everything goes smoothly in BatchPatch, you just never know if you reboot a computer if it might get stuck somewhere along the way. As great as Windows is, it’s not immune from problems from time time. Scheduled tasks are great, but they are not appropriate for every environment or every situation.

You can see a more comprehensive list of available features on our home page, or better yet download the free evaluation version of BatchPatch and just start experimenting with it yourself. It’s known for being very quick and painless to learn how to use. We have spent a lot of time keeping the functionality as intuitive as possible for sysadmins, so most users will “just know” how to use it right from the start without having to think about it or study documentation. Additionally, many users feel an immediate sense of empowerment when they start using the app because it provides so much control so quickly and easily.

One of the more powerful features that BatchPatch offers is the automation. In particular, not only can you use BatchPatch’s Job Queue feature to execute a sequence of steps on a given target computer or on a group of target computers, but what’s really cool and amazingly powerful is the functionality that BatchPatch provides for executing a sequence of operations that involves multiple computers. That is, you can use the BatchPatch Advanced Multi-Row Queue Sequence feature to orchestrate complex sequences where multiple steps are executed on multiple computers, where the computers and sequence steps are dependent upon one another. So for example if you have 10 target virtual machine guests running on a single virtual machine physical Hyper-V host, you could use this sequencing feature to initiate with a single click the download and install of updates on all virtual machines, and then after the installation process has completed on all 10 machines the sequence could be configured to auto-trigger the VM host to download and install updates and then reboot. So with a single click you get all of the VM guests and hosts updated while you just sit back and watch in real-time (or while you sleep, if desired). You could also do more complex sequences that involve many computers and many dependencies… for example if you want to execute job queue A on target computer A, job queue B on target computer B, and job queue C on target computer C, and then when all of those machines have completed executions of their respective job queues, the sequence can automatically trigger computers D, E, and F to run their job queues. And so on. There isn’t really any kind of limitation to the types of queues or sequences that can be put together. Sequences are able to wait until machines/groups complete any task or reboot etc before the next group proceeds, so if you have 100 computers that all need to be updated and rebooted, but only 10 of them can be offline at any one time, you could use a BatchPatch sequence to configure the entire process to run in a single click (or at a scheduled time). The functionality is a bit difficult to explain in a way that really captures how powerful it is, so I would encourage you to watch a video demonstration to see how it works here, or check out a written tutorial here.

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

BatchPatch Stuck Searching for Available Updates on a Windows 8.1 or 2012R2 Target

By Scott | Published: January 13, 2023

This isn’t really a BatchPatch problem per se, but it’s come up a couple of times in the past handful of months, so I want to take a moment to discuss it here today.

The issue is that when you have a Windows 8.1 or 2012R2 target computer, the search for available updates seems to go on forever. It may never return, or it may return many hours later and not find any updates (or it may also possibly find updates).

If you’re having this problem it’s likely due to an issue with the Windows Update client for those operating systems that was resolved in KB3138615

To resolve the issue, download the update directly from Microsoft, and then install it on your Windows 8.1 or 2012R2 target host.

You can either manually install the update by double-clicking the Windows8.1-KB3138615-x86.msu on the target computer’s desktop, or if you want to push the update from BatchPatch to one or more target computers, you can do that as well by following the instructions at this link: Deploying .msi, .msu, and .msp Files Remotely to Numerous Computers

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

Remotely Execute a Script that Connects to a Third Remote Computer

By Scott | Published: December 21, 2022

PROBLEM:

In BatchPatch you want to deploy a script to target computers that will connect to a third remote machine when it’s executed. That is, BatchPatch is running on computerA, your target computer where the script will run is computerB, and the script will create a connection to computerC. How do you do this in BatchPatch?

You might have noticed that if you have multiple hops involved (e.g. BatchPatch computerA remotely executes a script on target computerB [HOP1], which then establishes a remote connection to server computerC [HOP2]), you might encounter an error or unexpected failure.

The issue in the example described above occurs as a result of how authentication is handled in Windows. If you were to perform a Google search for something like double hop authentication you’ll be able to find more on this topic. Essentially the issue is that when BatchPatch authenticates from computerA to computerB, it doesn’t mean that this authentication is then able to automatically cross another hop from computerB to computerC. However, it’s actually still possible to accomplish this in BatchPatch, but there are a few things that you need to consider first.

SOLUTION:

  1. Permissions: This might seem obvious, but first make sure that the account that is being used to execute the script has the necessary permissions to connect to both computerB and computerC.

  2. Execution context: In BatchPatch under Tools > Settings > Remote Execution > Remote Execution Context… SYSTEM will not have access to network resources. This is by design in Windows. The SYSTEM account is a highly privileged account for the local system, but it cannot authenticate across a network. So, when BatchPatch deploys ascript to target computerB under SYSTEM, when the script actually runs on computerB it will not be able to reach any network locations, so a script that attempts to connect to a path on computerC will never be able to do so. In order for it to be able to work properly and have access to network resources, the BatchPatch remote execution context setting needs to instead be set to Elevated token + Interactive.

  3. Integrated security vs alternate credentials: In addition to the remote execution context, there is a consideration regarding how you authenticate to the target computer. While we generally always recommend using integrated security for authentication whenever possible, in this double-hop scenario you’ll actually have to instead specify alternate credentials for authentication to be successful across the second hop. In the case of integrated security, when BatchPatch on computerA tries to connect to computerB to run a script that connects to computerC, it will fail because Windows doesn’t allow authentication to make that extra step from computerB to computerC after it has already allowed authentication from computerA to computerB. However, when you use alternate credentials, you get an extra hop, essentially, because those credentials are used directly on computerB to execute the script. With integrated security the first hop is to computerB and the second hop is to computerC. However, with alternate credentials it’s more like having two first hops. You can authenticate from computerA to computerB (first hop), but then the credentials can be employed directly on computerB to authenticate on computerC (also a first hop, essentially), thus allowing your script to complete successfully.
Posted in Blog, General, Tutorials | Tagged , , | Comments closed