Blog | Page 33

BatchPatch Authentication in Domain and Workgroup (non-domain) Environments

By Scott | Published: April 16, 2014

When we set out to create BatchPatch, one of our primary concerns was to ensure that the software would be as easy to use as possible. We believe we were successful in that endeavor. However, since every network environment is unique, there are a few things that need to be understood about the BatchPatch authentication process in order to maximize your odds of smooth patching. In particular, the requirements to make BatchPatch work in a Windows workgroup environment are slightly different than the requirements for a domain environment.

If you’re currently seeing the following error message or something similar, you’ve come to the right place. Please see below for more information on resolving/rectifying the issue:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

BatchPatch Runner Account Must Be A Member Of The Local Administrators Group On All Target Computers

One of the most common use cases of BatchPatch is to remotely trigger the download and/or installation of Windows Updates on a network of computers. In order to do this, the account that you use to initiate the BatchPatch process must have local administrator privileges on the the target computers. To add a user to the local administrators group on a group of computers you must either log on to each computer individually to add the account, or you may use Group Policy (recommended) to apply the appropriate group membership to all computers at the same time.

You have three options for executing BatchPatch actions under the security context of the selected user account. Any of these options will work, but we recommend option number 1. Use option 1 unless you have a strong reason not to. If option 1 isn’t viable in your environment, use option 2. If option 2 also isn’t viable or convenient in your environment, then use option 3.

Option 1:

Recommended Method: Log on to the computer that you will use to run BatchPatch with the user account that you have added to the local administrators group on the target computers

Option 2:

Launch BatchPatch using right-click run-as to run BatchPatch with the user account that you added to the local administrators group on the target computers. This method can be used in cases where you are not logged on to Windows with the user account that you have setup to use with BatchPatch.

Option 3:

Launch BatchPatch with any account, and then inside of BatchPatch enter ‘alternate credentials’ for each of the hosts that you add to the BatchPatch grid. The ‘alternate credentials’ that you specify will, of course, be the user account that you previously added to the local administrators group on the target computers.

Additional BatchPatch Authentication Details:

IMPORTANT: In the sections below that describe how to use local accounts for authentication, we highlight registry entries/changes that you might need to make in your environment if you desire to use local accounts for authentication. These registry modifications come with their own security implications. You can read more about those registry values and remote UAC filtering here:

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

Using Integrated Security with a Domain Account:

The domain account that you use to launch BatchPatch must be a member of the local administrators group on the target computer.

Using Integrated Security with a Local Account:

The local account that you use to launch BatchPatch must also exist on the target computers, defined with the exact same username and password that is defined on the computer running BatchPatch.

If the local account you are using to run BatchPatch is THE built-in administrator account on the target computers, the following registry DWORD must be set to 0 on the target computers. 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 BatchPatch will work properly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most BatchPatch actions from completing successfully for those target computers:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken

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

If the local account you are using to run BatchPatch is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then the following registry DWORD must be set to 1 on the target computers. 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/2019 targets. NOT required for XP/2003 targets)

Using Alternate Credentials with a Domain Account:

The account that you specify must be a member of the local administrators group on the target computers.

Using Alternate Credentials with a Local Account:

The account that you specify must be a member of the local administrators group on the target computers.

If the local account that you specify 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 BatchPatch will work properly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most BatchPatch actions from completing successfully for those target computers:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\FilterAdministratorToken
(Only required for Vista/7/8/10/2008/2008R2/2012/2012R2/2016/2019 targets. NOT required for XP/2003 targets)

If the local account that you specify is not THE built-in administrator account on the target computers, but instead is just a regular named local account that is a member of the local administrators group on the target computers, then the following registry DWORD must be set to 1 on the target computers. 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/2019 targets. NOT required for XP/2003 targets)

Further Troubleshooting:

There is a bug that Microsoft acknowledged that exists only in Windows 10 version 1803 where if your BatchPatch computer is running this specific OS version, you may experience ‘Access Denied’ when using alternate credentials with a local account to connect to target computers of any OS, even if you have properly created the registry values as described in the previous section above. At the time of this writing the issue exists only when the BatchPatch computer is running Windows 10 version 1803. All earlier and later versions of Windows do *not* exhibit this issue.

Another issue exists where if your BatchPatch computer is at a patch level earlier than August/September/October 2021 (specific month is dependent on the particular version of Windows you are running), but your target computers are at a patch level of June 2022 or newer, then even if you are doing everything else properly according to the instructions provided in the document above, you would still see ‘Access is denied’ in BatchPatch. Please see this posting for a full explanation and resolution.

If you continue to have problems with ‘Access Denied’ I would suggest that you look at Microsoft’s more in-depth WMI Troubleshooting article.

Posted in Blog, General, Tutorials | Tagged alternate credentials, authentication | Comments closed

How to Hard-Code Your Own Custom Commands in the BatchPatch Actions Menu

By Scott | Published: April 8, 2014

We have done our best to make sure that all of the typical commands a Systems Administrator might need to run on computers in his/her network have been included in BatchPatch, so that it’s very easy to get information from remote computers with just a couple of clicks. That said, if there is a command that you would like to be in the menu that isn’t currently in the menu, we’ve provided a way for you to add your own commands to BatchPatch such that they will appear in the Actions menu, just like the factory-commands that we have included. If you believe that we should add a command (or feature) that isn’t already included in the default setup, please contact us or post in the forum with your request, and we will respond as soon as possible. However, if you simply want to add your own custom commands that might be unique to your environment, see below for steps on how to do that.

What Types of Custom Commands Can You Add to BatchPatch?

Virtually any command that you would run at the command line is a command that you can incorporate into BatchPatch. Maybe you need to get some information from a remote computer, or maybe you want to start or stop a service, or perhaps you need to kill a process. BatchPatch does provide built-in menu options for starting/stopping services as well as killing processes, but maybe you regularly have to start/stop a very specific service, and you don’t want to keep typing in the name of the service every time you need to restart it. In this case it would be very convenient to simply add the specific command to BatchPatch. Here are a list of examples. These are just some of the many commands that someone could add to BatchPatch, if he/she was so inclined:

WMIC SERVICE list brief
WMIC SERVICE where caption=’DNS Client’ CALL startservice
WMIC SERVICE where caption=’DNS Client’ CALL stopservice
WMIC SERVICE where state=’running’ GET name, displayname, pathname, processID
WMIC SERVICE where (state=’stopped’ and startmode=’auto’) GET displayname, name
WMIC SERVICE where (state=’stopped’ and startmode=’auto’) CALL startservice
WMIC SERVICE where (DisplayName=’DNS Client’) CALL ChangeStartMode Manual
WMIC PROCESS list brief
WMIC PROCESS where name=’hungProcess.exe’ call terminate
WMIC PROCESS where name=’hungProcess.exe’ delete
WMIC USERACCOUNT list brief
WMIC CPU get name, caption, maxclockspeed, systemname
WMIC OS GET caption,servicepackmajorversion,version
WMIC PATH Win32_ComputerSystem GET model
WMIC PATH Win32_BIOS GET caption
WMIC PATH Win32_ComputerSystem GET systemtype
WMIC PATH Win32_DiskDrive where “model like ‘%OCZ%'” GET deviceID, model
WMIC PATH Win32_DiskDrive where “not model like ‘%OCZ%'” GET deviceID, model
WMIC PATH Win32_LogicalDisk where “drivetype=3” GET deviceid, volumename, freespace, size
TASKLIST
TASKKILL /F /IM “hungProcess.exe”
PATHPING google.com
REG QUERY “HKLM\Software\Microsoft”
REG QUERY “HKLM\Software\Microsoft\.NETFramework” /v InstallRoot

3 Different Locations in BatchPatch to Incorporate Custom Commands

You can add your own commands under any of the 3 following menus:

Get Information
Remote Process/command
Local Process/command

There is only one subtle difference to be aware of when deciding where to add your commands. If you choose to add a command under the Get Information, then when you actually execute that command, it will not prompt you to confirm the execution. It will simply execute straight-away, right after you click the command in the menu. However, for both the Remote Process/command and Local Process/command menus, any commands stored in these menus will require you to confirm “Yes” or “No” after clicking on the command to execute.

How to Add Your Custom Commands to the BatchPatch Menu

The process for actually hard-coding your custom commands into the BatchPatch menu is very simple. We’ll use the Get Information menu for this example.

Select Actions > Get information > Create/modify user-defined commands

In the dialog that appears, in the left-hand column add the name/title of the command (this name/title is what will appear in the BatchPatch menu), and in the right-hand column add the corresponding command to execute. There is no limit to the number of commands that you can add. Simply create a new row for each command that you want to appear hard-coded in the BatchPatch menu.

Finally, when you’re ready to execute the command, simply highlight the hosts that you want to send the command to, and then select Actions > Get Information > Execute user-defined commands and then select the specific command that you want to execute

Posted in Blog, General, Tutorials | Tagged custom commands, execute remote commands, user-defined commands | Comments closed

How To Send Email Notifications In BatchPatch

By Scott | Published: March 31, 2014

We confess… The BatchPatch email notifications feature is not the most intuitive aspect of BatchPatch. However, it’s actually very simple to use, and my goal with this posting is to illustrate how to use email notifications in BatchPatch.

The original design of BatchPatch was focused on real-time patching, with the idea that any action a user chooses to perform will be done while the user is operating the BatchPatch console but not at some later time when the user is no longer in front of the computer. If you’re sitting in front of the BatchPatch console while it’s doing work, there isn’t really much purpose to sending email notifications since everything that BatchPatch is doing is being monitored.

It didn’t take long before we added scheduling options to BatchPatch, so that the operator could choose to run actions in the middle of the night without having to be in front of the computer. This is where the email notifications become more important. If you setup a BatchPatch grid to remotely install Windows Updates and reboot a set of computers at 3AM, you might desire to see the status of that grid when you first wake up in the morning without having to log on to your computer. Wouldn’t it be nice if you could simply take a look through your email to see how things went during the unattended 3AM actions? Fortunately, with the BatchPatch email notifications feature, you can do this quite easily. BatchPatch enables you to send the contents of any grid or individual row in an HTML formatted attachment to any email address or set of email addresses.

The email notifications in BatchPatch are designed to run in two ways. You can setup an email notification to be sent either during a Job Queue or as a Scheduled Task.

Configuring the Default Email Notification Settings:

Go to Tools > Settings > Email Notifications
Fill out the fields in the Email Notification settings form, and use the Send test email button to verify that your settings are correct and actually work. If the Send test email doesn’t complete successfully, you’ll need to adjust your settings until your test email is sent without errors.
For the subject body format, you have a few options. The subject field can be populated with any text you wish. If you include “$host” in the subject line, then when an email notification is sent, the host name in the BatchPatch row that initiated the email notification will be included in the subject line. The body text field has 4 special “keywords” that you can use. The “$host” keyword will behave the same in the body as it does in the subject line. However, to have the email notification actually include information about the grid, you will want to use use one of the other 3 keywords ($row, $grid, $allGrids).

$row: If you specify “$row” in the body, the entire contents of the BatchPatch row that initiates the email notification will be included with any email notification that is sent.
$grid: If you specify “$grid” in the body, the entire contents of the grid that contains the row that initiates the email notification will be included with any email notification that is sent
$allgrids: If you specify “$allgrids” in the body, the entire contents of the all the grids in the entire BatchPatch instance that contains the row that initiates the email notification will be included with any email notification that is sent.

Overriding the Default Email Notification Settings for an Individual Row:

Highlight the host(s) that you want to override, and then select Actions > Email Notification > Override default email notification settings
As you can see, the Override settings allow you to modify the Recipients, Subject, and Body, on a per-row basis. The rules for these fields are the same as described above for the Default Email Notification Settings, but in this case your settings will be for a given row, rather than applying to all rows that have not been overridden.

Using the Job Queue to Send Email Notifications:

Highlight the rows you wish to act on, and then select Actions > Create/modify job queue
In the Job Queue form, one of the actions that you may select to add to a queue is “Send email notification.” So, for any action(s) that you want to perform, you may put the “Send email notification” option as the very last item in the queue. When the job queue for that row is executed (either manually or by a scheduled task), the last action in the job queue will send the email notification. The email notification will be sent using the settings defined in Tools > Settings > Email Notifications unless you have overridden the particular row’s email notification settings, in which case the overridden settings for that row will be applied. Note that for the per-row email notification that we describe here, it probably makes the most sense for the “Body” field for your email notifications to be set as “$row” so that each row’s email notification sends the contents of its own row in the body of the email.

Using the Task Scheduler to Send Email Notifications:

For many users it doesn’t make a lot of sense to have each row send its own email notification at the end of a task. Often times it makes more sense to only send one email notification at the end of a series of tasks. For this, we prefer to use a scheduled task to send an email notification at a specific date/time. For example, if you are running a series of tasks at 2AM for a set of hosts, you could setup a single email notification to run for the entire grid (or all grids in the BatchPatch instance) at, say, 3AM. When 3AM comes, an HTML export of the entire grid (or all grids, if using $allgrids in the body text) will be sent to the specified email address(s). At 7AM when your alarm wakes you up out of a wonderful slumber, just pop open your smart phone email application to check out the grid status at 3AM without needing to get out of bed. You’ll be able to see exactly what happened during the 2AM actions by examining the HTML attachment email notification that was sent at 3AM.

Create a “dummy” row in a BatchPatch grid. The reason this is a “dummy” row is because it’s not going to be used to perform an action on a specific host. Instead it will be used by BatchPatch strictly for sending an email notification at a specific date/time. You may use any “dummy” host name you like for the row.
Highlight the row and then create a scheduled task for the row by clicking Actions > Task Scheduler > Create/modify scheduled task
Set any email notification overrides that you want for the particular row by highlighting the row and selecting Actions > Email Notification > Override default email notification settings. We recommend to use “$grid” or “$allgrids” in the body text field so that when the email notification is actually sent at the scheduled time, it will include the grid contents for the entire grid ($grid) or all grids in the BatchPatch instance ($allgrids).
Create a scheduled task that will perform the Send email notification action, as shown in the screenshot above.
Make sure to ENABLE THE TASK SCHEDULER by clicking on the small clock icon in the upper right corner of the BatchPatch window.

You can view a sample BatchPatch email notification (HTML export) here:

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

Removing Adobe Shockwave from Multiple Computers

By Scott | Published: March 19, 2014

From time to time we get asked how to use BatchPatch to uninstall Adobe Shockwave from a group of computers. The good news is that it’s relatively simple and straightforward.

The first thing we need to do is locate the uninstall string in the registry on a computer that has Adobe Shockwave installed. Launch the Registry Editor by going to Start > Run > Regedit.
Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and look for the Shockwave key. For older versions of Shockwave you’ll be searching through the many GUIDs that you see (ex: FF2A5498-4EFE-430F-A138-7EB365DBEBAD) for the REG_SZ called DisplayName. The DisplayNamevalue would contain a string that says something like Adobe Shockwave Player 11.1.

However, newer versions of Shockwave actually appear under their own Adobe Shockwave Player key instead of a GUID key. In the screenshot below you can see that we have located the appropriate key.
At this point we need to identify the UninstallString value, which in this case for version 12.1.0.150 is "C:\Windows\system32\Adobe\Shockwave12\uninstaller.exe"
Now let’s find that “uninstaller.exe” and copy it to our BatchPatch computer. For the sake of clarity in this example I have renamed the exe to shockwave_uninstaller.exe. We are going to deploy it to the target computers and then execute it remotely to uninstall shockwave on our targets. Once you have a local copy of the uninstaller.exe, select the hosts in BatchPatch and choose Actions > Deploy software/patch/script/regkey etc. Select the uninstaller as shown in the screenshot below, and then click OK.
Finally, select Actions > Deploy software/patch/script/regkey etc > Execute deployment
We can see that we were successful when we receive Exit Code: 0 (SUCCESS). And of course if we look at the target machines, we will find that Adobe Shockwave has been successfully removed.

Posted in Blog, General, Tutorials | Tagged software removal, software uninstallation | Comments closed

Deploy Java to Multiple Computers

By Scott | Published: March 10, 2014

We have a more recent tutorial posted here: Remotely Install Java 8 On Numerous Computers Simultaneously

The tutorial below utilizes an installation method that appears to no longer be necessary to remotely deploy Java. The new tutorial linked above should be all that is required at this time to perform the deployment. However, if you are installing an older version of Java and are having problems with the new method outlined in the tutorial above, you may want to try the old method outlined below.

Despite the fact that the Java Runtime Environment (JRE) has continued to be the source of repeated security vulnerabilities both in corporate environments as well as on home computers, we know that Systems Administrators are still frequently tasked with installing, updating, reconfiguring, and uninstalling Java in their environments.

At the time of this writing there seems to be a general consensus in the security community that if you do not need Java, you should uninstall it. However, if you *do* need it, at the very least when you install it you should make sure that it’s disabled in web browsers because that’s where the primary vector for attack lies. Unless you know definitively that you need Java running in your web browser, you probably don’t!

In this posting we’ll address how to remotely install Java to your entire network of computers using BatchPatch. In a future posting we’ll discuss how to remotely disable Java in web browsers.

Download the Java offline installer package. At the time of this writing you can retrieve this file from the following page: https://www.java.com/en/download/help/windows_offline_download.xml. However, if this link breaks at some point in the future, simply use Google to search for the Java offline installation download location.
For this example we are going to install Java version 7 update 51. The Java installer comes as a .EXE file, which unfortunately doesn’t support any silent or quiet installation parameters. The trick here is that you actually have to extract the contents of the .EXE in order to get a .MSI file that you can then use in a silent installation with BatchPatch. To extract the .EXE, doubleclick on it to launch it, but instead of completing the installation, after the installation dialog pops up, go ahead and cancel out of it. Then browse to the following location on your computer to find the .MSI file with a Data1.cab: C:\Users\yourUsername\AppData\LocalLow\Sun\Java\jre1.7.0_51
Before proceeding to install Java, one important thing to keep in mind is that the Java installer typically needs web browsers to be closed. Failing to close any web browsers before installing or uninstalling Java could cause the process to hang or not complete or it might simply require a reboot in order to complete the process. Consider killing all browser sessions with Actions > Services/Processes > Kill specific running process by name to kill firefox.exe, chrome.exe, and iexplore.exe on target computers.
Now that we have the .MSI and .CAB files extracted from the .EXE, we can setup the deployment in BatchPatch. Highlight the computers you want to push Java to, then select Actions > Deploy software/patch/script/regkey etc > Create/modify deployment.
In the BatchPatch Deployment window select the directory that contains the Java .MSI and .CAB files, and choose the actual .MSI file to appear in the MSI field in the Deployment window. Finally, tick the box to Copy entire directory in addition to the specified file. The reason we tick this box is because this installation requires the presence of BOTH the .MSI as well as the .CAB file. By ticking the box we are telling BatchPatch to copy all the files in that directory, which in this case is just those 2 files, to the target computers. We also verify the installation parameters, which in this case are /q /norestart.
After clicking OK on the Deployment window you can see that each of our target hosts contains the appropriate command that will be executed after the Java installation files are copied. Highlight the hosts that you are deploying Java to, and then select Actions > Deploy software/patch/script/regkey etc > Execute deployment. Click OK to begin the deployment.
Soon enough when the installation completes successfully, we see Exit Code: 0 (SUCCESS)

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

Deploying Windows Service Packs to Many Computers using BatchPatch

By Scott | Published: February 28, 2014

Did you know that you can deploy Windows Service Packs with BatchPatch? It’s actually very simple, just like deploying software or patches. BatchPatch gives you a simple way to push a service pack installer file to target computers, execute the service pack installation across all the target machines at the same time, and then reboot them with ping monitoring.

Before getting started, there are two items that we should address to help things go as smoothly as possible.

First, let’s take a look at the Concurrent File-Copy Operations Maximum setting, which can be viewed by clicking Tools > Settings > General. The purpose of this setting is to prevent the network connection from being overloaded when BatchPatch is in the process of copying the service pack installer file (or any file that is being deployed) to target computers. So, let’s say you execute the service pack deployment across 100 machines. Without this maximum setting enabled, BatchPatch would try to copy the 500+ megabyte executable file to all 100 computers simultaneously. For the sake of performance, this probably isn’t the greatest idea. It would make much more sense to copy the file to only one or a few machines at a time.

Note, if you wanted to you could actually use the Concurrent Thread Maximum setting to limit the number of active deployment execution threads in BatchPatch. However, since an individual service pack installation can take quite a while to complete, your overall time needed to deploy a service pack to 100 computers would be significantly increased since only X deployments would execute simultaneously, where X is the Concurrent Thread Maximum value that you specify in Tools > Settings.

So, instead of lowering the maximum number of concurrent threads, BatchPatch provides you with the ability to limit just the number of active file-copy operations that BatchPatch will perform. This means that if you execute a deployment simultaneously across 100 target machines, BatchPatch will only attempt to copy the installer file to X number of machines at a time, where X is the number you specify for the Concurrent File-Copy Operations Maximum setting. However, as the file copy completes for each machine, there will be no delay in the execution process as there would be with the Concurrent Thread Maximum setting.

For a large service pack installer file, I recommend keeping the Concurrent File-Copy Operations Maximum setting quite low, possibly even as low as 1, depending on your preference. Somewhere between 1 and 4 is probably a sweet spot, but feel free to use your own judgement. If you were manually going to copy a large file to multiple computers, how many transfer streams would you want to run at one time? As always, testing gives you the most information to make an educated decision, but there is no wrong answer here. It just depends on what you want and what you think will work well.

The second item we need to address is the location of the service pack installer file. Put it somewhere on the same machine that you’re using to run BatchPatch. Avoid deploying the service pack from a different computer’s shared directory. The reason for this is because for each target host that BatchPatch is deploying to, BatchPatch will end up pulling the file down from the network location through the computer that is running BatchPatch, and then finally on to the target host. This will double the amount of data that the BatchPatch computer has to transfer. However, if you start with the exe on the BatchPatch computer, then it can just push it directly to the target hosts.

OK, so let’s get started with the actual deployment. For this example we are deploying Windows 7 Service Pack 1.

First we need to determine what is the quiet/silent installation switch for the service pack exe. To do this we open a command prompt (Start > Run > cmd.exe) and type C:\deploymentFiles\windows6.1-KB976932-X86.exe /? where ‘deploymentFiles’ is the location of your service pack installer file. The /? will show us the command line switches that the exe supports. We will use /quiet /nodialog
Now, in the BatchPatch grid highlight the hosts that you want to deploy the service pack to, and then click on Actions > Deploy software/patch/script etc > Create/modify deployment. We need to select the location of the installer exe, and then we need to add /quiet /nodialog to the parameters field.
After clicking OK we can see that each row has a Deployment command populated. Now all we need to do is execute the deployment. Highlight the rows and select Actions > Deploy software/patch/script etc > Execute deployment. Click OK to confirm deployment. That’s it! Now we wait for execution to complete.
If installation completes successfully we will see Exit Code: 3010, which is a typical exit code for Windows installer files that means the installation was successful but reboot is required to complete it. However, since we didn’t specify the /norestart switch, Windows will actually automatically initiate the reboot for us anyway.

Posted in Blog, General, Tutorials | Tagged push install software, Remote Installation, service pack deployment | Comments closed

Using BatchPatch to Start and Stop Windows Services on Multiple Computers

By Scott | Published: February 26, 2014

Did you know that BatchPatch provides functionality to control Windows services on remote computers? For example, maybe you want to remotely reboot a large number of computers, but after they come online you also want to make sure that all services that are set to automatic are started. Fortunately you can do that pretty easily with BatchPatch. There are built-in scripts that enable you to perform the following actions on your network of computers. Best part is that you can perform these actions on many computers, simultaneously:

List all services
List automatic services
List manual services
List disabled services
List automatic services that are currently in a stopped state
Start automatic services that are currently in a stopped state
Start a specific service, by name
Stop a specific service, by name

To get a list of the services that are set to Automatic but currently in a stopped state, highlight your host(s) and select Actions > Services / Processes > List stopped automatic services

Notice that our stopped automatic services are listed in red:

If we want to issue a start command to all of the Automatic services that are currently stopped, no problem. We just select Actions > Services / Processes > Start stopped automatic services

A confirmation dialog appears asking us to click OK to continue with the operation. The script that will be executed on the highlighted hosts is displayed.

After clicking OK, BatchPatch will reach out to all of the target hosts that are currently highlighted in the grid, and it will execute the command to start all stopped automatic services. Upon completion we will see Exit code 0 in the All Messages column. We can then confirm that all of the services were sent start commands by looking at the contents of the Remote command output log column:

Posted in Blog, General, Tutorials | Tagged automatic services, start remote services, windows services | Comments closed

Deploy Registry Keys to Many Computers – Video Demo

By Scott | Published: February 20, 2014

Registry key deployment to numerous remote computers using BatchPatch – Video Demo:

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

Deploy Registry Keys to Multiple Computers Using BatchPatch

By Scott | Published: February 19, 2014

A systems administrator frequently needs to update the Windows Registry of every computer on his/her network. Did you know that you can use BatchPatch to accomplish this task extremely rapidly? BatchPatch provides administrators with a very simple way of getting registry keys to remote computers on a network.

Before we do anything please note that if you are going to be deploying a registry key/value to the HKEY_CURRENT_USER (HKCU) hive of the target computer(s), then you need to make sure that your ‘Remote Execution Context‘ is set to ‘Elevated token‘ and not ‘SYSTEM‘. If you are deploying a registry key/value to the HKEY_LOCAL_MACHINE (HKLM) hive of the target computer(s), then your ‘Remote Execution Context‘ can probably be set to either ‘SYSTEM‘ or ‘Elevated token‘. More details here: ‘Remote Execution Context‘

Create a .reg file for deployment. To do this you simply launch regedit.exe and highlight the key that you want to deploy to your target computers, and then choose File > Export. The registry editor application will create a .reg file for you. If you look at that reg file in a text editor, you’ll see it contains a line for each value in the key that you are creating/modifying. In the below screenshot you can see a .reg file for a FileZilla configuration that contains a single DWORD value in the HKLM\SOFTWARE\FileZilla key.
Now that you have your .reg file prepared, highlight the hosts in BatchPatch that you want to deploy it to, and select Actions > Deploy software/patch/script/regkey > Create/modify deployment
Browse to the location of your .reg file. After you select the file and click OK, you’ll see that BatchPatch displays the Command to execute:
regedit.exe /s "yourRegFile.reg"
The last thing you need to do is actually execute the deployment. You can do this by highlighting the hosts you are deploying to, and then select em>Actions > Deploy software/patch/script/regkey > Execute deployment. Upon successful completion of the deployment you should see Exit Code: 0 in the All Messages column.

Here’s a video demonstration of registry key deployment with BatchPatch:

Posted in Blog, General, Tutorials | Tagged deploy registry keys, deploy software | Comments closed

Deploy Software Remotely to Many Computers

By Scott | Published: February 17, 2014

This video demonstrates how to deploy software to multiple computers quickly and easily. It only takes a few clicks and a few seconds. In this instance we push install Notepad++ to 5 computers on our network.

Posted in Blog, General, Tutorials, Videos | Tagged deploy software, push install software remotely, remote software deployment | Comments closed