RSOP resolves wrong computer name

group-policywindows 7windows-server-2008

I have imaged a computer using Acronis Snap Deploy.

The source computer from where the image have been taken is SOURCEW7, and the computer created with this image is W7TEST

When I do a RSOP (Resultant Set of Policies) of W7TEST, the report says that the computer name is SOURCEW7, and the domain of the computer is Local. Though, the domain isnt called "Local", it's another domain name. And of course the GPOs doesnt applies.

The source computer (SOURCEW7) was in a workgroup at the moment of taking the image of it. I have added W7TEST on the domain after the image has been pushed into it.

I dont understand why the RSOP says the computer name is SOURCEW7, because there is no entries in the DNS for SOURCEW7, and in Windows, the computer name is shown as "W7TEST" and is on the domain.

I have an error also in the RSOP saying "GP core failed".

How can I troubleshoot this issue? Thanks.

EDIT: Picture representing the issue: http://i.imgur.com/XlQnWdg.png

Best Answer

I came across this forum post while browsing for answers on the same issue - in my case the computers generated from a VDI master showed the computer name of the master rather than the clone in RSOP. I came across the following discussion that seems to indicate the credentials had become cached under the local system account, preventing computer group policy processing:
http://www.networksteve.com/forum/topic.php/Group_Policy_Access_Denied_for_computer_policy_only/?TopicId=39534&Posts=2

To remove the rogue cached credentials:

  1. Use SysInternals PsExec to open a command prompt under the Local System account [http://technet.microsoft.com/en-us/sysinternals/bb897553]: From an Administrator command prompt: PsExec.exe -i -s cmd.exe
  2. Open the Stored User Names and Passwords app under the Local System account: From the System account command prompt: rundll32.exe keymgr.dll, KRShowKeyMgr
  3. You should now see the credentials that are cached under the Local System account. Review the list for rogue suspects, and remove them. For me, this was straightforward. There were two credentials listed: one rogue cred (from my old WHS2011 config I suspect), and a second called virtualapp/didlogical. When I reviewed the credentials on machines that were working, they only had the virtualapp/didlogical credential listed.

This seems to have worked for me in the VDI environment.

Related Topic