Deploying Windows Defender Antivirus Definition Updates to Offline Computers

If you need to push Microsoft Windows Defender definition updates to offline computers, here’s how to do it:

  1. Download the version of the Microsoft security intelligence file that is appropriate for your target computers’ operating systems. On the following page Microsoft has links to all of the various flavors that this file comes in. At the time of this writing, those files cover updates for the following different products:

    • Microsoft Defender Antivirus for Windows 11, Windows 10, Windows 8.1, and Windows Server 32-bit | 64-bit | ARM
    • Microsoft Security Essentials 32-bit | 64-bit
    • Windows Defender in Windows 7 and Windows Vista 32-bit | 64-bit
    • Microsoft Diagnostics and Recovery Toolset (DaRT) 32-bit | 64-bit
    • System Center 2012 Configuration Manager 32-bit | 64-bit
    • System Center 2012 Endpoint Protection 32-bit | 64-bit
    • Windows Intune 32-bit | 64-bit
  2. After you download the appropriate security intelligence file, you’ll have one of the following three executeable files: mpam-fe.exe, mpam-feX64.exe, or mpas-fe.exe. The executable can be manually installed on a given computer by simply running it (double-click on it or execute it from the cmd prompt). However, to deploy this file to numerous offline computers through BatchPatch you need to setup a BatchPatch Deployment. For the sake of this example I will be using mpam-fe.exe. If you are using a file with a different name, please adjust the instructions below accordingly to match your filename.
  3. In BatchPatch select Actions > Deploy > Create/modify
  4. In the Deploy window, add a title, then browse to the path of the mpam-fe.exe file on your computer. Your deployment configuration should look similar to mine in the screenshot below. Note, the parameters field is empty because the mpam-fe.exe file is built to be executed as-is without any additional switches/parameters.
  5. Click the double-right arrow button to save the deployment. Then close the Deploy window.
  6. You’re now ready to execute your deployment. Highlight the desired target computers in your grid, and then select Actions > Deploy > Execute saved deployments > Defender Definitions. This will execute the deployment for all selected/highlighted hosts. When the deployment is executed, BatchPatch will copy the mpam-fe.exe file to each target computer and then execute it, remotely, to apply the update definitions contained in the file. That’s all there is to it.
Posted in Blog, General, Tutorials | Tagged , , , , , | Comments closed

BatchPatch Windows update: Error 1601

There are two primary flavors of error 1601:

Windows Update: Error 1601: Failed to retrieve WMI info. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

“Access is denied” means that you have a permissions problem. Please follow the steps outlined on the following page to rectify the issue: BatchPatch Authentication In Domains And Non Domain Workgroups

Windows Update: Error 1601: Failed to retrieve WMI info. The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

“RPC server is unavailable” is typically caused by one of the following things:

  1. The large majority of occurrences of “RPC server is unavailable” are due to a firewall blocking communication. If BatchPatch makes a query to a remote server but does not receive a response, this is the error that you will see. Windows firewall, a third-party software firewall, or a network firewall is likely preventing communication to the target host. Make sure your firewall is set to allow the appropriate communications to pass through. In the case of this particular error, WMI communications must be allowed. While you could, of course, disable the firewall altogether, this is generally not recommended in most cases unless it’s just to do a quick test to determine that the firewall is, in fact, the cause of the issue. Depending on your environment, it might be ok to briefly turn off the firewall as a test, but be mindful that there are many situations where a firewall should not ever be turned off even for a moment. For instructions on configuring Windows firewall to work with BatchPatch, see this page: Using BatchPatch With Windows Firewall
  2. The second most common reason why you might experience this “RPC server is unavailable” error is due to the remote computer being offline. This RPC error is what you’ll see if there is simply no response to the initial query that BatchPatch makes when you attempt a Windows Update action. Make sure the target computer is online. If the computer is online, try the IP address instead of the host name to ensure that isn’t some kind of name resolution issue. If the computer is definitely online but you’re still getting this RPC error even when using the IP address instead of the host name, refer back to the item above and check the firewall since this error is almost always due to a firewall blocking communications.
  3. Check to make sure that RPC (Remote Procedure Call) service is running on the target computer. The service should be started and set to ‘Automatic’. If the RPC service is not running on the target computer, not only will BatchPatch not be able to connect to it, but it’s likely that you’re going to be experiencing a lot more issues with that target computer in addition to BatchPatch not working. It’s highly unlikely that you’ll ever find this service NOT running since Windows needs it to be running for so many reasons, but do a quick check just to make sure.

If you’ve gone through each of the items above and you’re still having issues, please see Troubleshooting Common Errors in BatchPatch

If you’re seeing a different 1601 error message, such as Windows Update: Error 1601: Failed to retrieve WMI info. Invalid class, or Windows Update: Error 1601: Failed to retrieve WMI info. Invalid namespace, then you might have an issue with WMI on the target computer. The first best bet is usually just to reboot the target computer to ensure that the issue wasn’t transient. Assuming the reboot does the not resolve the problem, please review the various steps at this page for resolutions to many/most WMI failures: WMI: Missing or Failing WMI Providers or Invalid WMI Class

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

BatchPatch Custom Script Integration – Wait for Service to be Running Before Proceeding to Next Step in Job Queue

In the current version of BatchPatch there is not a built-in job queue method to wait for a particular service to be running on the target host before proceeding to the next step in the queue. However, it’s possible to still accomplish this by integrating a custom script. In a future version we will likely incorporate this kind of functionality into the app itself so that no custom scripts are required, but at the time of this writing, below is how you could do it in the current version of the app.

The Goal

Use a create a custom script deployment in your job queue to control when the job queue advances to the next step based on whether or not a particular service is running or stopped on the target computer.

  1. I’ve created a very simple vb script that returns 0 if the specified service is started, 1 if the specified service is stopped. The contents of my script are below:
    'Checks the status of the specified service and returns 0 if it's running, 1 if it's not running
    'Cocobolo Software LLC September 2022.
    'Usage: cscript.exe "C:\Your Script Repository\CheckServiceStatus.vbs" "Your service display name goes here"
    'The first argument from the command line is assigned to strServiceDisplayName
    strServiceDisplayName = WScript.Arguments(0)
    on error resume next
    Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
    Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'")
    	For Each objService in colServices
    		If objService.Started = True Then
    			'wscript.echo 0		
    			'wscript.echo 1				
    		End If
  2. Save the script. The contents of the script above need to be saved in a text file with a .vbs file extension. For the sake of this example my script is called “CheckIfServiceIsStarted.vbs”
  3. Create a deployment. The deployment will be used to copy the vbscript to the target computers, execute it, and retrieve the exit code. To create your deployment select Actions > Deploy > Create / modify.
  4. Browse to the location of your CheckIfServiceIsStarted.vbs file, and then give the deployment a title. Click the ‘>>’ button to save the deployment. The screenshot below shows the configured deployment. Note, the DisplayName of the desired service to be checked is in the Parameters field in quotes.
  5. With your deployment created and saved you can now setup your Job Queue. Go to Actions > Job Queue > Create / modify.
  6. Select the desired steps of the queue.
    Wait 1 minute
    Deployment (Check if DNS Client Service Is Started)
    If previous action failed/errored (returned non-0), goto label:BEGIN
    Download available updates
  7. All we have to do now is execute the queue. Click Execute now (or alternatively save the queue first and then execute it directly from the BatchPatch Job Queue menu or from within a scheduled task). When the queue executes, the effect is that if the ‘DNS Client’ service is not running on the target computer, then the queue loops back to the beginning and waits 1 minute before checking again. The queue will keep looping, waiting a minute, and checking the service again until the ‘DNS Client’ service is found to be running on the target computer, at which point the queue will advance to the next step to ‘Download available updates’. By the way, there is no special significance to the ‘DNS Client’ service. I have simply used it for the sake of creating this tutorial. You will, of course, specify the display name of service that you care about. Or you might alternatively modify the script slightly to check for multiple services at once.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Recommended Group Policy Settings for BatchPatch Standalone Usage with No WSUS

One of the questions that arises for some users who are using BatchPatch without a WSUS (Windows Server Update Services) server, is how should Group Policy be configured for target computers? The main detail here to consider is that if your computers are not setup to get their updates from a WSUS server then there is a good chance that you’re using the default Windows Update configuration where Windows Updates are automatically installed on target computers. However, if you’re now considering using an app like BatchPatch (or if you’re already using BatchPatch) to manage your monthly Windows Update process, you’re going to want to disable the automatic update functionality that your computers are currently using so that you can have BatchPatch initiate the download and/or installation of updates on all target computers. This is where Group Policy comes in. Or if you don’t have a domain environment and instead have all computers running standalone or in a Windows workgroup, then you’ll use Local Policy on each target computer instead of Group Policy since Group Policy is configured at the domain level. (Local Policy is configured on a given computer by launching the Group Policy editor locally by typing gpedit.msc in an administrator elevated command prompt)

  1. Create/edit a group policy that is linked to the OU containing your target computers. Or if there is no domain and you are just using Local Policy for non-domain computers, then simply launch gpedit.msc from an administrator elevated command prompt directly on the computer that you are configuring
  2. In Group Policy editor (gpedit.msc) go to Computer Configuration > Administrative Templates > Windows Components > Windows Update and set the Configure Automatic Updates setting to 2 = Notify for download and auto install. The effect of this setting is essentially to disable the Automatic Updates feature on the target computers. It doesn’t turn off the Windows Update service. It simply tells Windows to stop automatically downloading updates. Since you want to use BatchPatch to perform the download/install process on-demand on your target computers, you need to stop the target computers from automatically downloading and installing updates. Or if you prefer to have Windows automatically download updates but not install them until you initiate the installation process with BatchPatch, then select 3 = Auto download and notify for install. However, please note we typically do *not* recommend using setting 3 unless you are using a WSUS in your environment because if you use setting 3 with no WSUS, then you might end up with updates downloaded to target computers that you don’t intend to install. This is because with WSUS you would use the WSUS to filter which updates the target computers see as available, but with no WSUS you will use BatchPatch to control which updates are downloaded and installed. Since you might sometimes need or want to skip a particular update in a given month, if you are configured to use setting 3 instead of 2 then the update will still be automatically downloaded by the target computer even though you never plan to initiate the installation of that update through BatchPatch. While this isn’t the end of the world by any means, any such updates will waste bandwidth to be downloaded and will waste hard drive space when they sit downloaded in the Windows Update cache directory without ever getting installed. Having updates downloaded but not installed might also cause Windows to pop excess notifications about this fact at least until or unless the updates are deleted from the Windows Update cache manually or hidden so that they no longer appear as available for installation.

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

Creating Custom Email Notifications for the Job Queue

In the most recent release of BatchPatch we added a new form for custom email notifications so that instead of having a singular email notification as the only option for any time an email notification is sent in the application, you can now create as many custom email templates as you want, which enables you to have different emails go to different people at different times and based on different triggers in your job queues.

Use Actions > Email notification > Create/modify email notifications

If I then want to create an email notification that will only be used for database admins, perhaps in the cases when I am updating the SQL servers, then I can do that here with something like this:

Then once I’ve created a custom email notification I can use it a particular job queue:

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

Retrieving Logon Information from Active Directory Local Administrator Password Solution (LAPS) and inserting it into the BatchPatch Grid

In the July 2022 version of BatchPatch we added integration for Microsoft’s Local Administrator Password Solution (LAPS), so now you can easily highlight a group of target computers in your BatchPatch grid and then retrieve the LAPS password stored in Active Directory for each of the selected hosts/rows. The rows will then be automatically populated with the corresponding LAPS username/password for each selected host.

If you’re reading this tutorial then you probably already know what LAPS is, but in case you don’t… Microsoft describes that the “Local Administrator Password Solution” (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset. You can download LAPS here. Microsoft provides a complete configuration tutorial for LAPS here.

The installation and configuration process for LAPS is actually pretty quick and painless. Follow Microsoft’s instructions or pick another tutorial on the web (there are many). Once you have it working, it’s very easy to import logon account information from LAPS into BatchPatch.

  1. Highlight the rows in the BatchPatch grid for which you want to retrieve the LAPS password from Active Directory
  2. Select Actions > Specify alternate logon credentials > Get LAPS password from Active Directory…
  3. In the Get LAPS Password form you have to first enter the LAPS username. This is the name of the local administrator account being managed by LAPS for a given computer. When LAPS is configured for an organization, there is a Group Policy, Computer Configuration\Administrative Templates\LAPS\Name of administrator account to manage, that tells LAPS which local administrator account it should manage. Since LAPS only stores the actual password value in Active Directory, you need to tell BatchPatch the username so that when BatchPatch retrieves the password from Active Directory, it can then be inserted with the username into the Alternate Credentials field for a given row. It’s probably the case that in most environments the LAPS username will just be administrator, but of course it really all depends on your particular environment and how LAPS has been configured.
  4. You’ll also have to specify the credentials that BatchPatch should use to query Active Directory for the LAPS password values. When BatchPatch runs the PowerShell query to retrieve the LAPS password for a given computer, it needs to run under an account that has read/view permission on the ms-Mcs-AdmPwd attribute for that computer in Active Directory. If you choose Integrated Security instead of supplying credentials, BatchPatch will execute the query as the account being used to run BatchPatch. If you instead specify credentials here, note that these credentials are *not* saved to disk, but they will be remembered for the life of this BatchPatch.exe instance. When you close and re-open BatchPatch you will be required to re-enter the credentials.
  5. Finally, you’ll need to select the PowerShell query to execute.
    Get-AdmPwdPassword requires the Local Administrator Password Solution (LAPS) PowerShell module, AdmPwd.PS, to be installed on the BatchPatch computer.
    Get-ADComputer requires the Remote Server Administration Tools (RSAT) Active Directory module to be installed on the BatchPatch computer.

    Both of the above queries accomplish the same task, so you can simply pick the one for which you already have the required toolset installed.

  6. That’s pretty much all there is to it. When you click Execute BatchPatch will connect to Active Directory and retrieve the LAPS password for each of the selected rows in the grid, and then BatchPatch will insert the corresponding password along with the LAPS username into the Alternate Credentials field for each selected row in the grid.

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

New Version of BatchPatch Released July 2022

This week we released a new version of BatchPatch. Along with miscellaneous fixes and enhancements, the primary features/functionality we added are:

  1. Custom email notifications that can be saved and added to job queues or scheduled tasks. Now you can have different email notification settings for different purposes. So, for example, if you need to have one email notification that goes to one group of users at the beginning of a maintenance period, while a different email notification goes to a different group of users in the event of a problem or error, now you can do that. You can create as many different email notifications as you want or need, and then you can insert whichever ones you want into your job queues and scheduled tasks as desired. See ‘Actions > Email notifications > Create/modify email notifications
  2. Local Administrator Password Solution (LAPS) integration is now available under Actions > Specify alternate logon credentials > Get LAPS password from Active Directory. If you are using LAPS, now you’ll be able to highlight a group of computers in your BatchPatch grid in order to query Active Directory for each computer’s administrator password all at one time. The username/password will then be auto-filled into the ‘Alternate Credentials’ column in your BatchPatch grid for each selected computer.
  3. A new Windows Update search setting for updates where ‘DeploymentAction = Installation’ is now available in the BatchPatch settings. Up until recently if you wanted to emulate the Windows automatic updates search for updates so that BatchPatch would display the same group of available updates as the Windows Update automatic updates control panel interface in Windows, you would have done that by selecting ‘Important’ and ‘Recommended’ in BatchPatch. However, recently Microsoft has made a change to which updates are displayed in the Windows Update control panel interface, and we have accordingly added a new search setting in BatchPatch to emulate how Windows is doing things now in the newer versions of Windows. If you notice that BatchPatch ‘Check for available updates’ is no longer displaying the exact same search results that appear in the Windows Update control panel on the target computer, try the new search setting under Tools > Settings > Windows Update > Search Preferences > Search for updates where ‘DeploymentAction = Installation’
Posted in Blog, General | Tagged , , , | Comments closed

‘Access is denied’ in BatchPatch After Installing the June 2022 Cumulative Windows Update

The problem: After installing the June 2022 cumulative Windows Update (2022-06 Cumulative Update for Windows) OR any future cumulative update that is released from this point forward, if the previous patch level of the system was some date prior to June 2022, and the newly installed patch level is June 2022 or newer, you might experience BatchPatch all of a sudden returning an error for no apparent reason: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

( For general ‘Access is denied’ issues that aren’t specific to the June 2022 cumulative update, please see )

Why this is happening: Toward the end of 2021 (the specific date varies depending on the operating system – see below for details) Microsoft released an update that added security hardening to the Distributed Component Object Model (DCOM) remote protocol in Windows to address the security vulnerability CVE-2021-2614. The hardening was available for administrators to enable, but it was not enabled by default… until June 2022 when Microsoft flipped the switch and enabled it for everyone.

The specific dates of release are as follows:
Windows Server 2022 – September 27, 2021
Windows 10, version 2004, Windows 10, version 20H2, Windows 10, version 21H1 – September 1, 2021
Windows 10, version 1909 – August 26, 2021
Windows Server 2019, Windows 10, version 1809 – August 26, 2021
Windows Server 2016, Windows 10, version 1607 – September 14, 2021
Windows Server 2012 R2 and Windows 8.1 – October 12, 2021

Important reading: In the following posting, Microsoft explains the detail of KB5004442, which was released in June 2022. When the Aug/Sept/Oct 2021 update (date depends on OS, as noted above) is installed it makes available a new registry DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel, which when created and set to value data 1 will enable DCOM security hardening configuration that enables the administrator to test and see what, if anything, it breaks in their environment. In the June 2022 KB5004442 update, the DCOM security hardening configuration was then enabled by default, such that if you did not previously set the aforementioned registry value to 1, Windows would now begin behaving the same as if the value had been set to 1, which could cause some things to break. And now in order to disable the DCOM hardening changes you would have to create and set the value data to 0. Furthermore they note that in March 2023 the DCOM hardening changes will become permanent with no registry value available anymore to disable the configuration.

KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)

Temporary workaround: Use the registry value described in the link above (set to value data 0) to disable the DCOM hardening changes temporarily until March 2023. In March 2023 after installing the cumulative update for that month it will be permanently enabled with no further ability to be disabled anymore.

Permanent resolution: BatchPatch will only break and start producing the ‘Access is Denied’ errors described at the top of this posting in the case where the BatchPatch computer is running a Windows operating system at a patch version that is *older* than Nov 2021 AND when at the same time the target computers are running a Windows operating system at a patch version of June 2022 or newer (or if the aforementioned registry value data is intentionally set to 1 by the administrator, then the problem will manifest as soon as the target computer has the Aug/Sept/Oct 2021 update installed).

So, if you began to experience this problem after installing the June 2022 or newer cumulative update on target computers, the simplest resolution is to make sure your BatchPatch computer is updated to the latest Windows cumulative update (or at a bare minimum to a patch level of Aug/Sept/Oct 2021 or newer – The specific date is dependent on the particular version of Windows that you are running. Please refer to the OS version list above as well as the aforementioned link for the specific date for your particular version of Windows).

( For general ‘Access is denied’ issues that aren’t specific to the June 2022 cumulative update, please see Troubleshooting Common Errors in BatchPatch )

Posted in Blog, General | Tagged | Comments closed

Remotely Deploying Monthly Windows Updates to Multiple Computers

BatchPatch can do quite a few things, but at the core of the software is the functionality for managing Windows Updates on numerous computers without having to install any permanent remote agents, and with only minimal setup and configuration. In many environments BatchPatch will just work right out of the box, without any configuration. In other environments, minor initial setup/configuration will be required.

Once you have BatchPatch setup in your environment, it’s extremely simple to put it to work. Let’s say you want to start the Windows Update process on 100 target computers all at the same time so that you can download and install any applicable updates to those computers, then reboot the computers and monitor them while they go offline and come back online to make sure everything completes successfully… Here’s all you need to do:

  1. Add your computers to a BatchPatch grid by manually typing them in, importing a text file list (or just copy/paste it), or by adding computers directly from your Active Directory groups and OUs. Choose the option that you desire from the Grid menu. I’ve selected to just add mine manually for now. I’ve added just 9 computers, but you can add as many as you want.

  2. Once the grid contains your computers, to perform any action you just need to select/highlight the desired target computers, and then from the Actions menu pick the action that you want to execute. For the sake of this example we are going to use ‘Actions > Windows Updates > Download and install updates + reboot if required

That’s pretty much all there is to it. You can sit back and watch your computers through the entire process. The settings that control which types of updates are searched for, downloaded, and installed, are located under ‘Tools > Settings > Windows Update‘.

What else can BatchPatch be used for? Well, in general the most important thing to know is that whichever actions you desire to execute on a single computer can be executed just as easily across numerous computers. You can…

  • Deploy third-party software
  • Run scripts and commands
  • Retrieve inventory information
  • Schedule tasks (pretty much anything that you execute manually in BatchPatch can also be scheduled to run at a desired time)
  • Execute a multi-step job queue that includes numerous individual commands to be executed sequentially on each target system
  • Execute an advanced multi-host sequence where you not only execute a multi-step job queue on each target host, but you link the target hosts together in such a way that enables you to perform actions on certain computers before or after other computers. If you have machines that are dependent on one another, this is a great way to update them all with a single click, while still ensuring that they don’t all go offline at the same time
  • Deploy updates to offline computers

The list above only represents a portion of what BatchPatch can do. We have numerous tutorials posted to help you get going. If you think that BatchPatch should be able to do X, but you aren’t sure how to do it, search the tutorials because that functionality probably already exists. If you can’t find something or if you think it’s not available, feel free to ask us a question or submit a feature request.

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

Get the ‘Location’ Property of a Computer Object in Active Directory

Recently someone asked us how he could import the ‘Location’ property value on computer objects from Active Directory for a group of computers in a BatchPatch grid.

BatchPatch enables you to run a script and view the output of the script, which is how we’ll accomplish this task. And while there is more than one way to write a script to retrieve the location value of computers in Active Directory, the simplest method is to use the Get-ADComputer PowerShell cmdlet that’s included with the Active Directory PowerShell module in the Remote Server Administration Tools (RSAT) for Windows, so that’s exactly what we’re going to do here.

  1. On the BatchPatch computer you’ll need to make sure you have installed the Active Directory PowerShell module so that we can take advantage of the Get-ADComputer cmdlet. Microsoft has installation instructions here.
  2. Test the Get-ADComputer cmdlet in a PowerShell prompt to ensure that you’ve installed the module successfully. I have a computer called WIN10_TEMP_TEST, so I’ll run the following command to get its Location value:
    Get-ADComputer WIN10_TEMP_TEST -Properties location | select -ExpandProperty location

    You can see in the screenshot below that it worked.

  3. Now that we have a working command, we can essentially just insert that into BatchPatch so that we can use it to query for the location value of numerous computers simultaneously. In BatchPatch we’ll create a Local Command for this purpose. When you execute a Local Command for a given row (or group of rows) in your BatchPatch grid, the command will execute on the BatchPatch computer itself (whereas a Remote Command would execute on the target computer(s)). To create a Local Command in BatchPatch click on ‘Actions > Execute local process/command > Create/modify local commands

    The command syntax that we’re going to use in BatchPatch is:

    powershell.exe Get-ADComputer $computer -Properties location | select -ExpandProperty location

    However, note that depending on your OS and PowerShell version, if you have problems with the command above, try this instead:

    powershell.exe -ExecutionPolicy Bypass -command "Get-ADComputer $computer -Properties location | select -ExpandProperty location"

  4. Now that we’ve added the command, it’s simple to run it for the selected hosts in the grid. Just select the desired hosts, and click on ‘Actions > Execute local process/command > Execute saved local commands > Get location

    When the command is executed, the $computer variable in the command is replaced by the actual host name for the corresponding row. This way you can select a large number of rows to obtain this information for each row all at the same time. I only have two computers in my lab at the moment, but you can see that I was successfully able to obtain the location info for them:
Posted in Blog, General, Tutorials | Tagged , | Comments closed