Trust relationship between workstation and domain fails. Help me ??

you need to remove that PC from Active directory and add it again

enter Administrator as login (you will logon direct to PC) remove it from domain, restart, add it again. make sure to delete from active directory before adding it back

Rejoin your system in AD using your client system  or Reset your System in AD

Dear,

you need to go to system properties on client pc and there will be a wizard for joining domain or work group. Before that please check there is any name conflict in you domain pcs. Mostly this issue is will arise due to name conflict.

This is common issue and following reasons will be the root cause

So this issue appears to be related to a few things happening:

1. System decides that it needs to run system repair tool (SRT) most likely due to unclean shutdown process or actual data corruption.
2. User clicks repair which performs a background system restore.
3. Machine account password sync with DC is broken and user does not report to IT that they ran the SRT.
4. DC and machine are not able to re-sync the machine account password. (I'm intrigued by the DES/AES situation mentioned above.  Will need to look into that further).
5. System may be able to operate until a particular period of time/failed logins transpires. (Usually over a weekend or at6PM on a Friday) :-)
6. Admin has to rejoin PC to the domain or use NETDOM to reset the machine account password.

It amazes me that some people re-image to resolve this issue.  I guess if you have a super-fast imagine process, but what a waste of time.

I had a user email me today with the above problem and she had run the SRT.  Tech onsite was able to rejoin to the domain to fix the issue.

So sorting through all of the chaff in the posts above, it appears that running (at least for us enterprise users with AD with GPOs):

bcdedit /set {default} bootstatuspolicy ignoreallfailures

will prevent the SRT from running?  My question is what is the impact besides preventing users from having access to this tool?  Does something go "un-fixed" as a result?  Is it something that we need and can be useful?  Is it still accessible by holding down F8 (haven’t been able to test yet).

I had another user who had a two year old PC.  They reported system was booting to SRT.  OEM diags indicated the HD was dying.  OEM sent out new HD and after running Spinrite on the drive, I was able to image over user's config.  I only did this because they had a very specific set of settings and programs installed.  I normally like to install clean and deploy apps via scripts that we use.

Two days later it happened again.  Again it appeared the HD was dying and the onboard system diagnostics pointed to the HD.  Again the OEM sent us out a replacement drive, but issues persisted.  A few days later a second tech was looking at the system and noticed a system hang with diagnostic codes that pointed to the motherboard.  Everything looked fine and we had a hard time reproducing but as machine was under warranty OEM sent out new MB as we were able to produce failure codes.

After new motherboard install the machine has been solid.  The moral is that sometimes the cause of users getting the SRT screen can be a much bigger problem.  I’ve been burned a few times trying to find the needle in the haystack until I think to run memtest86+ and discover I have bad RAM in the system.

Sure would be nice if there was a way to alert us when a user runs the SRT so we could just run NETDOM or if the OS was smart enough to sync with the AD somehow after running a restore.  I guess we can again write scripts to check the C:\\Windows\\System32\\LogFiles folder for SRT activity but it isn’t clear to me what this would look like.  Would it be in a \\SRT directory?  Doesn’t appear to be there by default.  Perhaps only after use of SRT.

First This scenario use it on windows7

1- from your server side go Active Directory user and computer 

select the PC then r.click " Reset Account "

2- from PC side log in to computer as local administrator - R.click on my computer - properties

- advance system settings - computer name - change

3- change from domain to work group then restart

4- log again to same place and select domain and write your domain name he will ask you for user and password which has access to network fill it and restart .

the problem sovled ,

put if the problem appears so many time in different computer , you must check3 main options that depends on your network infrastructure ,

a- your Antivirus ex :Symantec may case problem on network connectivity

b- DNS and if migarte on active directory , check if case any errors 

c- network security policy if you have though you switches routers you use it and if there any security on ports or data traffic

Dear Khuram & Dhaval, your solution is correct but as I practiced its not necessary to remove it from active directory.

You can unplug the workstation from the network and then log in using the cache account with admin privileges. I assume that you have logged in an account with admin rights before while installing it with applications. And once you have logged in, insert the network back and rejoin it in the domain.

Hope this helps.

Reset your computer object in AD and then rejoin the system to domain. It will work perfectly and you will get all your earlier settings.

login to system as local admin and remove system from domain, restart and again add it to domain.

you can remove the system from domain, logging as domain user also

This happens because of multiple attempt with wrong password, simply you need to remove the particular system from the domain controller and again rejoin it you will be able to log in now. 

You can login with the existing user by unplug the network cable, then login using the this user. after that reconnect the network cable and rejoined the computer to domain. you might need to delete the computer name from your AD server if you will keep the same computer name.