![admt 3.2 unable to determine the local path for admin share admt 3.2 unable to determine the local path for admin share](https://cdn.statically.io/img/www.starwindsoftware.com/blog/wp-content/uploads/2017/05/1-Intraforest-migration-behavior.png)
Workstation's event log show successful processing of GPO objects each time after reboot or after GPUpdate. My apologies for the duplicate post, but I felt it was necessary as it is 3 years later. I had added my question to that thread, but as of yet no one has replied, hence me posting as a new thread.
ADMT 3.2 UNABLE TO DETERMINE THE LOCAL PATH FOR ADMIN SHARE HOW TO
The same issue, and while there are links to how to correct it (adding the target Domain Admins account to the Restricted Groups GPO), there is not an explanation on why this does not get resolved automatically during the migration process, as it does with I have seen another posting from 2011:, which seems to describe Group to GP…"Restricted Groups", but the key question is why would this be necessary, as a normal joining a machine to the domain does this automatically? Nothing is specified in group policy for this, so I do not know how this gets pushed to the workstation when a normal domain join is performed. If I disjoin and then rejoin the machine to the new domain, the "\Domain Admins" group DOES become a member of "\Domain Admins" group is NOT a member of the machines Local Administrators group. Most all seems well except for one thing.Īfter completing the migration and the workstation is in the new forest / domain, I have noticed that I cannot use domain administrative accounts during a UAC elevation prompt to perform some management function. I have only so far tested with a few test user accounts and groups and 1 workstation. I am doing an ADMT migration between Win 2003 & Win 2012 R2 domains in a cross forest environment.