In this case the answer was point 5. But the other points are here for others who might have similar questions.
From your screen shot the user icons with the question mark indicate that the SIDs for the user accounts can not be resolved, which is fundamental. This could either be that the user accounts have been deleted from your Active Directory or there is a connectivity problem between the file server and your domain controller. Based on that you are having other issues I will assume the account do still existing in Active Directory.
To resolve this I would go back to the basics. Check the following:
1. DNS Resolution
Can you resolve you domain controller (DC) by DNS name.
i.e. Run > Cmd.exe and use nslookup .
If you can’t resolve check that local network settings are point to the DC as the DNS server and that there is nothing between the two servers like Windows firewalls or devices that would prevent this type of connectivity. Also check that you can resolve DNS on the DC itself.
2. Time in Sync
Is the local time and time zones on both the DC and file server synchronised. They should be ideally exactly the same, and the file server should be getting it’s time off the DC. The following can help resolve this:
w32tm /config /syncfromflags:domhier
w32tm /resync /rediscover
net stop w32time
net start w32time
When running Windows domain connected servers as VMs on ESX, disable host time sync for all VMs. This is done ether by:
- editing the
.vmx file directly by browsing the datastore from the command-line or downloading the file from the datastore making the changes and uploading the file again.
Configuration Parameters option from the VM's settings in the vSphere or VI client to Add a row.
See http://kb.vmware.com/kb/1189 for more information.
Also it is also good practise to:
- Configure an external time source for you Windows DC. See http://support.microsoft.com/kb/816042
- Configure youyr ESX/vSphere hosts to get time from the DC. See http://kb.vmware.com/kb/1035833
3. Check Event Logs
There would most likely be a lot of errors and warnings logged in the event log.
4. Re-establish Trust
If all else fails you can re-establish the trust between the file server and the DC be disconnecting it from the domain, rebooting and rejoining it again.
Don’t do this though if you have outstading time or DNS issues.
5. VM might have duplicate SIDs with another
When you build a Windows VM from a template in VMware vCenter you can choose to "customise" it. This reseals the operating system with sysprep when it starts for the first time after it is deployed from a template. Resealing an operating system when cloning or deployment templates is important because each Windows install has unique information such as security identifiers (SIDs) that is uses when connected to a domain. These can't be duplicated on another VM.
To read more about customisation in VMware vCenter see Sysprep file locations and versions.
If you don't have this option you can do it manually by using sysprep and using the generalize option, which will remove the computer SID and put the computer into the welcome wizard. Sysprep can be found
As a note, don't generalise your base template, because you can only do it 3 times and most people want to apply updates to their template on a monthly basis.
RDP to DC
It’s hard to say exactly without more information, like event logs (may be you can post some error event IDs). But I would suggest that you check the file server issue first because it may be indicative of another issue. When the file server is working try to RDP from the file server to the DC.
I would also check http://technet.microsoft.com/en-us/library/cc794832(v=ws.10).aspx if you are attempting to connect to the DC using an older RDP client or operating system.
If that doesn’t help please provide more information like where you are trying to connect from (is it across a RAS connection?) so we can help.
Hope that helps.