AD Trust Relationship
7 replies, 359 views
Posted on April 24, 2013
aechols
Registered user
Joined: June 20, 2011

All of our desktops are persistant, but I just got a "The trust relationship between this workstation and the primary domain failed" error.  It's been years since I've had something like this happen, and the first time with a virtual machine.  I'm going to see what I can do to get it connected again, but if the last resort is to remove the computer account from the domain and re-add it, how would this work?  Is it even possible with a VM like this?  Are there any other suggestions?

Posted on April 24, 2013
Ron Oglesby
Unidesk employee
Joined: April 20, 2010

with a persistent desktop, you're right that is very odd. Or with any of our desktops really (as for non-persistent desktops we set the computer password settings and what not).

Couple of things I have seen (in VDI) that could cause this, duplicate computer names is one of them. Cloning of the VM (not likely in our environments).

Have you tried the remove from the domain and re-add. What happens then?

Also did this start all at once on all the destkops? If you take one desktop it just started on and look at its event in eventvwr can you see when it started?

 

Posted on April 24, 2013
Ron Oglesby
Unidesk employee
Joined: April 20, 2010

OH, And one more of my favorites that caused this... DNS. DNS was pointing the machines in one environment to a domain controller that had stopped syncing (because its DNS settings were jacked).

See what DC they desktops experiencing this problem are talking to, see if you find commonality there. In the DNS case the DC was not syncing and therfore didnt have the computer objects for the VMs, BUT they knew they were part of the domain even though they joined the domain through another DC.

 

Posted on April 24, 2013
tcooney
Registered user
Joined: July 8, 2011

I have also run into this issue a couple of times and resolved it by simply re-joining the desktop to the domain (you don't have to remove it from the domain first).  I agree with Ron, I believe it has to do with duplicate computer names and exitsting DNS records.  If I want to re-use a computer name, I first go to the domain controller(s) and delete that computer name if it exists (and of course no longer in use), then I will delete any records (if they exist) related to that computer name in the DNS server(s).  Finally, I'll re-create the desktop in Unidesk, this process seems to avoid the problem you mentioned.

Posted on April 24, 2013
aechols
Registered user
Joined: June 20, 2011

I really wanted to try and not remove from AD and readd it back.  I found this suggestion online and it worked like a charm.  I'll still have to see what happens when I update the image and if it'll stay connected to the domain.   I'll be doing that tomorrow night.  I logged on locally as Admin using the vSphere client to do this:

1. Control Panel - System
2. 'Change Settings' under Computer Name, domain, and workgroup settings
3. In System Properties, click 'Network ID...'
4. 'This computer is part of a business network...'.  Next
5. 'My company uses a network with a domain'. Next.  Next
6. Type in Domain Admin credentials
6a. You should see a dialog that the computer account has been found in domain...'would you like to use this'?  Yes.
7. Do not add any accounts
8. Finish and restart

Posted on April 24, 2013
tcooney
Registered user
Joined: July 8, 2011

I may not have been clear in my response but your steps are exactly what I was referring to in re-joining the domain.

Posted on March 19, 2014
Edited by snakedoc on March 19, 2014
snakedoc
Registered user
Joined: August 7, 2013

Sorry to revive an old post but I'm seeing this problem all of a sudden on our persistent desktops too.

Initially, I thought it was because I reset and restored desktops but slowly the ones that had not been reset or restore were showing this sympoton.

As far as I can tell, the service principle name and DNS are all registered correctly. The problem seems to be an expired computer account password. There are no dupliate computer names. The workaround of re-joining back to AD manually works fine. This is not happening on our physical machines.

Should I be doing something like this for the persistent desktops? http://www.unidesk.com/support/kb/technical-note-disabling-automatic-password-change-nonpersistent-desktops

In terms of the process where an UniDesk desktop is being updated with new version of app layers, does it do a "re-join" to AD after the boot image is created?

TIA!

Posted on March 19, 2014
Gunther Anderson
Unidesk employee
Joined: May 17, 2010

You shouldn't have to disable the automatic machine account password change on persistent desktops.  Nobody else has to (certainly none of my machines have ever had to, and they're still happily in their domain), but it also can't hurt if you want to go that route.  Changing layers does not cause a domain rejoin, because it's still the same machine in the same domain.  The machine account password stored in the registry should still be the same, and because it's in the personalization layer, it should supersede anything coming up from a layer.  About all I can think of that might somehow cause this is if you have a layer that you left joined to the domain and you checked the Reinstall box for it when editing a desktop.  That might remove the domain stuff from the desktop and substitute in the information from the layer.  I've never seen that happen, but it sounds plausible.  And if it is that, disabling the automatic password change won't help.

Login to post comments