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.
LocalAdministratorsGroup
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.
  • BatchPatchAlternateCredentials


    Additional BatchPatch Authentication Details:

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
  3. (Only required for Vista/7/8/10/2008/2008R2/2012/2012R2. NOT required for XP/2003)

  4. 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. NOT required for XP/2003)



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. NOT required for XP/2003)

  3. If the local account that you specify is 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. NOT required for XP/2003)



Further Troubleshooting:

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

This entry was posted in Blog, General, Tutorials and tagged , . Bookmark the permalink. Both comments and trackbacks are currently closed.