Trust relationship cannot be established between workstation and server

[knc]

Two workstations out of about 20 just started having this problem where they try to logon onto their workstation and they get the trust relationship message and can't login. The client found a work around... disconnect the network, log on to the workstation and then plug in the network.

So reviewing the even tviewer I am finding that the workstation in question have some anomalies in regards to the DNS and DHCP records. One workstation has one IP address in the DNS list and in the DHCP lease is showing TWO completely different IP's

The other workstation is showing an IP address in the DNS table, and NOT showing in the DHCP lease, however another workstation is showing the used ip to that workstation in question..

First off think this is the problem?

And should I just delete entries in the DHCP table? Should I leave the HOST A records for these devices alone, or delete them?

 

[YeOldeStonecat]

Make sure you secure the local Administrator password of the workstation.
Ensure DHCP is giving the correct TCP/IP properties...server as only DNS.
Unjoin from the domain
Reboot workstation...log in as local Admin
Join the domain again...reboot and log in as domain Administrator.
Reboot and log in again as domain Administrator. (I just like logging in again as domain admin to make sure the tokens settle in correctly)
Reboot and log in as the domain user. The domain users prior user profile will be perfectly intact.

 

[mraikes]

Make sure you secure the local Administrator password of the workstation.
Ensure DHCP is giving the correct TCP/IP properties...server as only DNS.
Unjoin from the domain
Reboot workstation...log in as local Admin
Join the domain again...reboot and log in as domain Administrator.
Reboot and log in again as domain Administrator. (I just like logging in again as domain admin to make sure the tokens settle in correctly)
Reboot and log in as the domain user. The domain users prior user profile will be perfectly intact.

Every few months I'll have a small handful of our 160+ workstations pop up with the OP's exact problem. I go through a process similar to this (basically drop off the domain and re-join it) and it fixes whatever went wrong.

And that leads me to my question - what has gone wrong on those workstations that causes this kind of problem to begin with?

 

[YeOldeStonecat]

Every few months I'll have a small handful of our 160+ workstations pop up with the OP's exact problem. I go through a process similar to this (basically drop off the domain and re-join it) and it fixes whatever went wrong.

And that leads me to my question - what has gone wrong on those workstations that causes this kind of problem to begin with?

I had that problem happen a few times with Vista.....at a few different clients. Very very rarely with XP, and I don't think with 7 yet. So I blamed it on Vista.

 

[knc]

Well this is Win 7 pro 64bit... Umm I'm concerned about re-joining the domain as it would be important to get the users profile back again...
Too many practice management apps and settings.. and it is an accountant last thing they need is not having their profile..

 

[mraikes]

I had that problem happen a few times with Vista.....at a few different clients. Very very rarely with XP, and I don't think with 7 yet. So I blamed it on Vista.

LOL, well our machines are a combination of XP and 7 - no Vista. So there goes that theory!

And KNC, follow Stonecat's instructions and the user profile will be intact. If you aren't sure, test the process on a machine with a test user first. You'll see it doesn't affect the profile.

 

[Metanis]

DNS issues in general can cause this, but also issues when the "nearest" AD PDC quits authenticating workstation requests and they traverse a slow link to some other PDC. Time Sync issues can also cause it. If the workstations or the servers didn't both jump for DST last weekend for example.

 

[knc]

LOL, well our machines are a combination of XP and 7 - no Vista. So there goes that theory!

And KNC, follow Stonecat's instructions and the user profile will be intact. If you aren't sure, test the process on a machine with a test user first. You'll see it doesn't affect the profile.

YES 99.99999% of the time the profiles remain intact... but this is the owner of the company, what are the chances the profile will get corrupted? LOL

 

[mraikes]

YES 99.99999% of the time the profiles remain intact... but this is the owner of the company, what are the chances the profile will get corrupted? LOL

The owner? Then it's guaranteed to screw up his profile somehow. And even if it doesn't - he'll think it did.

 

[knc]

The owner? Then it's guaranteed to screw up his profile somehow. And even if it doesn't - he'll think it did.

But what about the workstation showing up in the DHCP lease pool with two different ip address'? I don't usually root around the DHCP pool but I would think that might cause a problem..

 

[mraikes]

But what about the workstation showing up in the DHCP lease pool with two different ip address'? I don't usually root around the DHCP pool but I would think that might cause a problem..

Dropping a machine from the domain and then rejoining the domain has nothing to do with its IP address. It shouldn't change a thing.

 

[computertech]

YES 99.99999% of the time the profiles remain intact... but this is the owner of the company, what are the chances the profile will get corrupted? LOL

I've run across this a few times after performing a system restore and with time issues. Removing a PC from the domain and adding it back will not corrupt a profile. If you're really worried about profile corruption, you can always mount the disk in another machine, copy his profile, and if anything happens to it you have what you need to get him back up and running. But I'll say it again, removing from the domain and re-adding it will not corrupt a profile.

 

[YeOldeStonecat]

YES 99.99999% of the time the profiles remain intact... but this is the owner of the company, what are the chances the profile will get corrupted? LOL

There is no guarantee with computers. But in my entire career of working with computers (i'm going back to DOS and Win3) in networks...I've never seen a user profile deleted due to removing a workstation from a domain.

 

[daverichards]

There is no guarantee with computers. But in my entire career of working with computers (i'm going back to DOS and Win3) in networks...I've never seen a user profile deleted due to removing a workstation from a domain.

I have never seen one deleted either.

 

[oldtech]

We are seeing this issue only on Win7 x64 workstations and very rarely. In all cases to date the dns, time of day, server, network etc. have all been fine. These have been in single and multi-server installations running varying MS - OS's. The only common thread for us seems to be Win7 x64. To echo the others, leave and rejoin the domain has cured it in every instance without profile loss.

 

[bits-n-bytes]

Even being a newb, Ditto on this, I've done it a few times, migration takes its toll.

 

[pceinc]

I had this happen once on a Windows 2000 DC with a Windows 7 workstation. I figured it was due to the changes I had to make to get the Windows 7 machine to join a 2000 domain in the first place. It only happened once or twice to the same machine, and all I did to correct it was rejoin the domain. I don't even think I removed it from the domain first. The client now has primary and secondary 2008 servers and the issue has never resurfaced.

As others have stated, the profile will be fine.

 

[lsi]

I've seen profiles get deleted. Only twice but of course they were 2 of the worst possible computers that could have happened on. So now I always make a backup.

When I've seen this particular problem, though, I don't leave the domain (drop it into a workgroup). I just re-run the wizard to join the domain again and it often re-establishes the computer acct or whatever was broken. No profile issues if you do it this way.

 

[bluecoast]

I was having this issue on a number of laptops in an environment. The cause appeared to be the machine token that is handed out. They expire after 30 or 60 days by default. At the time, the machines were using standard wireless and were not authenticating before login. Setting up a RADIUS server allowed the machines to authenticate with the server before the user logged on. This allowed the machine to renew its token with the server.

There was a way from the workstation to force a token renewal, but I found it easier to just re-join the domain.

I found you do not need to drop off the domain, you can simply rejoin the domain assuming you are using the same machine and machine name.

Never had any problems with it messing with profiles.