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

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:

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

1. 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.
2. 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)


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

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

1. The account that you specify must be a member of the local administrators group on the target computers.
2. 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)
   

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