When you are working in a network environment without a domain– that is to say there are no domain controllers and no member servers because all computers are simply part of a workgroup, authentication can be a challenge when trying to perform operations remotely. Generally speaking, if you have a network with enough computers where there is a need to perform any tasks remotely, you should ask yourself “Why is there no domain established yet?” because realistically there probably ought to be one. However, let’s assume that for whatever reason there is not already a domain and there is not going to be a domain, but you have tasks to perform on remote computers, then what?
OK, so the main issue you need to be aware of when dealing with remote WMI connections is User Account Control (UAC). In a workgroup/non-domain environment there will never be domain logon accounts, so all accounts that one needs to deal with are going to be local accounts. However, when working with local accounts, in order to execute many (not all) remote WMI queries or methods, remote UAC actually needs to be disabled on each target computer that is being operated on.
Disabling Remote UAC
Remote UAC is controlled by a single registry value. If the local account you are using to run the query (or in the case of BatchPatch, the account you are using to run BatchPatch or the account that you specify in the ‘alternate credentials’ field in 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 in order to disable remote UAC the following registry DWORD must be set to 1 on the target computers. If the DWORD does not exist or is set to 0, then remote UAC is enabled, and you will generally get ‘Access Denied’ when trying to perform a remote WMI query. To disable remote UAC, set the value of the following registry DWORD to 1. 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 targets. NOT required for XP/2003 targets)
Disabling Admin-Approval Mode (Enabling Full-Token Mode) for the Built-in Administrator Account
Unfortunately that’s not everything. What if you are using THE built-in administrator account (as opposed to a regular named local account that is a member of the local administrators group on the target computers)? If the local account you are using to execute the WMI query/method 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 WMI queries (including WMI queries executed through BatchPatch) will work propertly. However, if it’s set to 1, the built-in administrator account is put in admin-approval mode, which will prevent most remote WMI actions (including 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 targets. NOT required for XP/2003 targets)
Microsoft discusses remote UAC in more detail here. We discuss more about authentication options for BatchPatch here.
