We have been getting sporadic reports from our users of the error, "The trust relationship between this workstation and the primary domain failed." The workaround has been to dejoin and rejoin the domain, but it keeps happening and we need a permanent fix. We are primarily a laptop shop. It has been suggested we disable the automatic machine accouint password change on our domain members in GPO. While this may be a viable option with relatively low security risks, I'd really like to figure out why it's happening and try to fix it. The machines can lose the trust relationship at random. It can happen overnight, or after going into hibernation. I've had it happen to me a few times. The DCs (we have 2) both show error 5722, but one is spitting out a specific Kerberos error that the other one is not: While processing an AS request for target service krbtgt, the account kriegesh did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 2). The requested etypes : 18. The accounts available etypes : 23 -133 -128 3 1. Changing or resetting the password of kriegesh will generate a proper key. My main issue is trying to determine why this continues happening and if we can resolve it without disabling the account password. If that IS our best option, then so be it. Any thoughts are welcome. Thank you very much in advance! ~Sarah

Log on locally as a local administrator. In the Network tool of Control Panel, select Change and enter a Workgroup name, leaving the domain. Restart the computer and log on locally as a local administrator. There are two methods to rejoin the domain: You can join the domain from the client if at the same time you can provide an administrator username and password on the domain. -or- You can delete the existing computer account in Server Manager, recreate the computer account, synchronize the domain, and then on the client rejoin the domain. Regards, Kalyan.

This solves the problem for each individual machine but does not really address the issue requested. GP wants to know why it keeps happening to different machines. The machines were joined successfully. They worked. Then they stopped and gave these errors. They can be "fixed" individually, but unless we know why they broke, they may (and do...) break again. What causes a broken trust relationship?

Exactly. We can fix it for individual machines, but not on a large-scale. It keeps happening at random. There seems to be no solid reason why the machines in question are being affected, i.e. some particular reason they get this trust issue. They can go into hibernation, be locked (not logged off) overnight, or logged off the domain for maybe a week - nowhere near the 30 day expiration MS puts on the system password. Thanks for the feedback. ~Sarah

This article seems to answer your question about how machine account passwords are used and the ramifications of not having them change frequently. http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx I am having the same problem. I believe that the problem arises from using imaging software (Ghost in our case). Windows relies on the fact that either the current OR the previous password will be right. If an old image has a "wrong" password for a previous password, this might be the problem. In this case, an image older than 30 days could be considered old... I am currently experimenting with setting the password age to a long duration (365+ days) as we rarely use images older than this. If anyone can confirm whether this was likely to work, I'd take any information...

Hi there we are having the same issue but it isn't only on Windows 7 machines. It happened on my win 7 laptop but also on a win2008 server we have. Also a number of employees with win 7 laptops are reporting this issue too. Again we have done what you suggested dejoin and rejoin and it resolves the issue but really need to find out if it is a different issue that is causing it. The only thing that I can think of that we have done recently is to apply the latest round of MS patches maybe it was one of these that caused it ?? any thoughts would be very helpful ?? regards Jodie

I am also using Ghost. I am using the same password and my image is only a day old. Every time I join a laptop to the domain, it joins fine, restarts, and I go about installed the final software. Then when I need to restart again, the relationship is suddenly broken. I can't figure out why or whats doing it. The only solution is to unjoin the laptop, delete its object in AD, add a new object, and rejoin it. Then all seems fine.

I have the same issue happening on my network. I am also using ghost. It happened to my laptop and now to a workstation that I restored via a ghost image. The laptop however had not been restored from an image. The trust relationship was just broken from one day to the next. It is very annoying and I would like to know what exactly is causing this issue.

We are seeing this issue randomly as well. Can anyone report the status of IPv6 on both the clients and the domain controllers? We have IPv6 enabled on the clients, but disabled on the DC's, and we're starting to wonder if that is possibly causing issues.

we are getting the same error. We do not use Ghost. The error started appearing after a windows security update which caused problems with RDP connections as well. After we went back to a restore point to fix the RDP issue, the Trust error continues

We are running into those issues too. We are using MS Solutions as WDS, WAIK and then all new computers are Syspreped before being joined to our domain for the first time so I don't think it is related to duplicate SID like we can see more often when using Ghost without Syspreping the machine before joining it to the domain. I also found this link posted by Mr._Seven above by investigating on my own. It is really interresting so I went through it but that Registry Key they are talking about (ScavengeInterval) does not exist in Windows 7. So I wonder if everything in this article is up to date and can also be applied to W7/W2008. For us it seems like the computers are more at risk to loose there trust relationship with the domain when they are working remotely by VPN. We noted, by running a tool/powershell that scans all computers machine password age in AD, that some Windows 7 computers (XP computers too for the record) had exceeded our MAX Machine Password Age policy of 60 days (default is 30). They are connecting by VPN every day for more than an hour and their machine password is not renewed. It should based on the article. Some problematic computers are recent, some have been deployed 1 or 2 months ago but we haven't got any machine loosing their trust relashionship once they succesfuly changed it through the normal process of logging into Windows while on the network after the 60 days password age variable. But this is not a good information since we have started migrating to Windows 7 only 120 days ago so the majority of them have not renewed their machine password more than once. We will see soon if it can happen after the computer has maintained his synch with AD by itself... We were wondering if the users could do something that would make the computer loose it's trust relationship. Like what will happen if an expired user logged on by VPN then lock his session to go take a coffee and comes back to log in. Then the password is automatically synch with AD and the user gets a "Wrong user name or password" message. If he does not read the message carefully and tries to log in 50 times, will something happens, like will the computer be rejected since too many attempts would have been done from it? We noted that those who got their trust relationship lost have dome more than 20 logon attempts. I'll try to be careful at the event viewer next time it happens on the client computer to see if i can find more detials.

I have run into this error on a brand new computer that has not been imaged or ghosted. Freash install, added to the domain and as I'm sure most of you have experienced... my priorities changed and I was unable to work on this computer for over a week. I have not installed any of the corp. software, i'm not sure if I did windows update, I might have installed office... this is the first I've seen it...

Same issue happening on our network (Win 7 Pro, no imaging - OEM installation). Only one system reported so far, I find it quite coincidental that the issue starts getting reported so frequently on numerous networks as it appears in this thread. I've seen this happen in the past, albiet rarely, and local login is the only remedy. U

We had some suggestions from Microsoft (a tech was in-house and sent us these, we haven't implemented yet, so YMMV and use at your own risk). I just wanted to pass along. I will report back on any we try. 1. Some people believe that there is an issue with an imaging process, creating duplicate SIDs. Sysinternals used to have a tool called "NewSID" but it was retired a couple of years ago. Here's a blog post on it: http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx 2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs. a. GPEdit.msc b. Computer Configuration  Windows Settings  Security Settings  Local Policies  Security Options c. "Network Security: Configure encryption types allowed for Kerberos" d. Check all of the boxes and reboot Your mileage of course may vary. 3. One possible solution is making sure the "Provider Order" in network settings is set to "Microsoft Networks." Here is a blog post on it: http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed 4. Some people have been able to successfully re-enable the trust without leaving and rejoining the domain by running the "Join a Domain or Workgroup wizard." I know this won't fix the root cause, but it may keep it from happening again and it is an easier fix than having to rebuild local profiles. http://windows.microsoft.com/en-IN/windows7/What-happened-to-the-Network-Identification-Wizard NOTE: You may need to unplug the machines from the network to use the cached credentials first. 5. Symantec and other anti-virus solutions may be the problem, but obviously this creates its own security issues if you have to disable them. 6. You can disable the machine account passwords as instructed per your Microsoft ticket. Most people believe that removing the passwords won't be a huge security risk, but it will however remove one layer of protection from the equation. Please let us all know if you have any luck. ~Sarah

This is happening on well over 140 PCs on one floor in our building. The other floors are fine, however the floor with the problems was recently imaged (using ghost) and all the windows updates were up to date on the image. Other floors are not affected, yet this trust relationship is coming up randomly on that single floor of 140 pcs. Its a complete pain manually going to each PC to rejoin the domain, but having kept logs, some of the ones we have fixed are again coming up with the trust relationship error.... Nothing in the pc logs, nothing server side. DHCP is the same for all floors, so not that. The client PCs all have a unique SID which is done as part of the sysprep process, so its not that. Only thing I can think of is a recent rogue windows update, but i'm getting it in the neck for all these broken PCs. Any word from the Microsoft people on this issue? I can't even test any theories on this because of the complete randomness of this error occuring....

We are experiencing the same thing with sporadic machines losing their trust relationship periodically. Our "solution" is to have the users back up their data, and reimage them. It is absolutely NOT an ideal solution, but it's working for our sporadic problem. Has anyone found a real solution to this, or a cause??

Make sure that you Domain Controller running PDC FSMO role is set to sync the time with reliable time source. Kerbors will always have problem if the computer and DC have time off by more than 5 minutes. http://support.microsoft.com/kb/816042 http://support.microsoft.com/kb/307897

I am getting the same issue. Mainly running Windows 7, original deployments are done using SCCM 2007 R3. So no SID issues to get in the way. I am about to do a full review of the GPOs for the workstations so will have to see what is happening. Does anyone have some hints where to look to see what is causing the errors?

Is there anymore info on this? I have just started to have the exact same issue. If a Windows Update issue should I be looking on PDC or client? We havent changed our GPOs for a while so why would one become corrupt all of a sudden?

I am dealing with the same issue as well for the last 5 months. It seems to happen every time a users password expires they get the trust realtionship error, we also get it randomly as well. I have been just taking the computer off of the domain and deleting their computer account and re adding the computer back to the domain, Its really a pain in the butt. This is not a real solution. You can check out this article to see if this will help http://portal.sivarajan.com/2010/05/workstation-trust-relationship-issue.html I just tried it out on a couple of my computers today. I will just have to wait to see if we get the error again.

We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync. When the time is out of sync between client and server you then get problems with the password age for machine accounts. ref: http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx Also we now have disabled system restore by policy, but it is not stopping restore by startup repair. We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449. This will probably help if you have this issue on wireless clients that rarely connects on LAN.

We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync. When the time is out of sync between client and server you then get problems with the password age for machine accounts. ref: http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx Also we now have disabled system restore by policy, but it is not stopping restore by startup repair. We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449. This will probably help if you have this issue on wireless clients that rarely connects on LAN.

i have the same issue too but i know what i just did! active directory users and computers> computers> then right click in my clone7(my computer joined to my domain) then I clicked in reset account. now when i try to login in that windows 7 pc, it says the same>> the trusts relationship between this workstation and .... but i use the local adminsitrator in that pc i still can see that compyter joined to the domain... any one knows how can i login in the domain with my other user?...reset the pc, the server, disable and enable that pc in the server, still...

We are having the trust relationship error on our Windows 7 machines only. XP machines don't have the problem. Both XP and Win7 laptops are on the same domain.

hi, this isn't a lasting solution, but at least you don't have to resoft the computer each time it happens: undock and/or disconnect the computer from any network connection and then log in. after you have logged in you can reconnect the computer to any network, cable or wireless. e.g. if you have a laptop, make sure to switch the wireless button off as well as undocking it from any cable. regards, untz Same solution here. Laptops only affected, unplug, logon, plug back in. Win 7 only, XP fine.

We had some suggestions from Microsoft (a tech was in-house and sent us these, we haven't implemented yet, so YMMV and use at your own risk). I just wanted to pass along. I will report back on any we try. "2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs. a. GPEdit.msc b. Computer Configuration  Windows Settings  Security Settings  Local Policies  Security Options c. "Network Security: Configure encryption types allowed for Kerberos" d. Check all of the boxes and reboot Your mileage of course may vary. Please let us all know if you have any luck. ~Sarah" Hi Everyone, Same issues here but a hybrid 2k3 and 2k8 R2 environment where Win7 client and several of the 2k3 servers have the above issues! I think the Win7 x64 client is pointing me in the right direction in that it is a Kerberos authentication mismatch that occurs. Win 7 error: "cannot change password, the encryption type specified is not supported on the KDC." above is the info Sarah G. posted on Mar 28, 2012 the key is SPECIFICALLY - 2 c. Not necessarily a corrupt policy, but a new default that turns off DES for authentication on the new 2k8 R2 DC's! i have found through several tech articles that Win 7 (vista) and 2k8 and up(?) use AES encryption and disable DES encryption by default, but 2k3's use DES and cannot run AES for login/DC access. Sarah's tech may be on track w/ #2c, but may not be the complete solution. Any info anyone can add would be appreciated, not a guru on this subject at all. ~R.Bman *going to try adding DES to 2k8r2's and Win7 to see what happens.

I manage several networks both 2008 DC and SBS 2008 and mix of windows xp and windows 7. This is getting out of hand. Over the last 4 weeks I have had 5 businesses call be up with atleast one machine doing this at each network.

I'm not sure this fix will work for everyone. Still have to do the domain off, domain on to get it to connect. But to get it to stop I un-checked the "allow the computer to turn off this device to save power" on the network adapter. I think this is the default value for Windows 7.

Hi, I tried to use the method of unplug the network cable, restart the computer and login with user credentials. It fixed the issue of logging. Rejoin domain after that. But here is the other solution to perform at Win 7 machines. Just go to control panel, then users and click on Manage your credentials. Create/ reset / your user credentials there and you will be able to logon. Thanks

I have seen this issue happen with systems which have identical machine names, you may want to check this and see if this is causing your trust relationship failures. I Hope this helps you.

Check to see that these machines do not share a common computername, this has been known to cause trust issues with the server. Click start, right click computer, click properties, click change settings, and change the computername to something unique, you will still have to exit and rejoin the domain but at least you will stop this from happening in the future. Please let me know if you have success with this. Cheers.

I have posted the solution on my website: you have to log in with a local user, leave the domain, and rejoin it. It's not as hard as it sounds, I assure you. http://nuangel.net/?p=931 - full disclosure: yes, it is my website, but I have gotten very positive feedback that the solution works. You can see it for yourself in the comment, and if it helps you, don't be afraid to let me know! NuAngelDon't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution! NuAngel.net

Hi R.Bman I also have a hybrid domain enviroment. I use landesk to copy the netdom files required to reset the machine account password, reboot the machine and the PC can log back in as per normal. I agree with your thinking regarding the various authentication types, have you found out any more information on this? Cheers Chris

Garrett, Read the posts above yours. Everyone here knows how to leave and rejoin the domain. The problem is that the computers keep losing the trust relationship and we a re trying to find a fix to that issue.Jeff Speirs

So Microsoft . . . any thoughts? Want to admit this might be an error or issue and give us an answer? Everyone, your ideas are much appreciated, thank you.

Garrett, Read the posts above yours. Everyone here knows how to leave and rejoin the domain. The problem is that the computers keep losing the trust relationship and we a re trying to find a fix to that issue. Jeff Speirs With all due respect, that article is and has been the most popular on my website for months... and I can even see that at least 10-20 people a day tend to click the link to read the steps, to mention the plethora that come from Bing and Google. I wouldn't say that "everyone here knows how." I'm just offering some help to people finding their way in to this thread. As far as "why" it happens, I've developed a long list of potential reasons since first running in to the issue several years ago, but I do not think there is any sure fire reason. If you have a computer that was recently imaged and keeps losing the trust relationship, sysprep it. If you have a computer that has changed names, delete the old name from the Computers OU in Active Directory. If you've activated a new domain controller, did you properly DCPromo it or demote the other? And other times people have sworn to me that absolutely nothing changed... it's just one of those issues... like why do I have to restart my print spooler from time to time? Haha... -GarrettDon't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution! NuAngel.net

Has anybody tried this? Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2 http://support.microsoft.com/?id=976494 -GarrettDon't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution! NuAngel.net

Hi Sarah In the middle of a MS support case, with a similar problem (not excatly the same as yours). I got the important information, that AES is per default enabled on Win 7 Machine Accounts. This mean that if you have defined allowed kerberos types, and have not enabled AES128 and 256 as trusted types the you are asking for trouble. Authentication rejection wil happen at random. So... If you have defined allowed kerberos types, and have windows 7 in your domain, then make sure you also allow AES 128 and 256 Regards Claus

Hi Guys, I think this has already been posted on here but I found if you login to the local machine (not a domain user) > disconnect from the domain > rename the local machine to something unique > restart as required > log back in to the local machine and join the domain > restart > log in as any domain user. This worked for a problematic windows 7 machine as a permanent fix for me. It seemed like it was because this host name had been used on the domain before as an XP machine and only started to happen after the machine had been wiped with Win7 and then named to what it was previous. I think that there may have been something on the DC side that had been missed out before the wipe like the Host had not been removed from the domain before the wipe and the DC was not allowing it to register because it was using a different SID, but this is only a theory I may be worng. Thanks Anthony-b

I believe the general consensus is to disjoin and rejoin the PC to the domain to correct the issue, but I think I've found the way to prevent this from happening anymore. You can check out the details here: http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/ but I created a script that does what this article says to do. The only problem is that you need to do this on all systems that have Win7 or 2008 Server on them. Another option would be to add this script to a GPO as a login script (just comment out the msgbox lines and remove the comment character on the "On Error Resume Next" line so the users don't call and ask you about the messages). The code is below, just copy it into notepad and save it as "ProviderOrder.vbs" (with quotes). *NOTE: You must be logged in as an Admin to run it as a standalone, but it should work in a GPO for anyone who authenticates to the domain. 'On Error Resume Next const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ strComputer & "\root\default:StdRegProv") strKeyPath = "SYSTEM\CurrentControlSet\Control\NetworkProvider\Order" strValueName = "ProviderOrder" oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue arrList = Split(strValue, ",") strSelection = False If LCase(arrList(0)) <> "lanmanworkstation" Then For i = 0 to UBound(arrList) If LCase(arrList(i)) <> "lanmanworkstation" Then strOther = strOther & "," & arrList(i) Else strSelection = True End If Next If strSelection = True Then strChange = "LanmanWorkstation" & strOther oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strChange msgbox "Modification Complete!", vbokonly + vbinformation, "Complete" Else msgbox Chr(34) & "Microsoft Windows Network" & Chr(34) & " is not available on this system", _ vbokonly + vbcritical, "Invalid" End If Else msgbox "This computer does not need this modification", vbokonly + vbinformation, "Not Needed" End If

Just a question to pose an observation to this thread group - I am performing an Active Directory migration for a enterprise-class client. This isn't my first migration, and I doubt it will be my last. The client AD is 2003 Forest and Domain Functional Levels comprised of both Windows Server 2003 and Server 2008 R2 DCs globally. Client provides both DNS and WINS name resolution. DNS is AD-Integrated for forward lookup and BIND for Reverse lookup. Name resolution is always a challange to reach the workstations from our Migration Consoles, but we manage. Here's the rub - With every AD Migration I've done, I've seen some fallout. When the Computer joins the Target Domain, sometimes it thinks it's there, but it's like Secure Channel gets hosed and we get a machine with trust relationship issues. Like many on here, our remediation has been to remove the host from the Domain and rejoin it manually. Works like a charm. The problem we're seeing with this migration is that the rate of incident for this is abnormally high. We've got Sites in Canada we're migrating from where the rate of incident is Approx 80%. Clients are primarily Win7 with some XP mixed in. So, here's what we've observed - If we select the option to "Enable NetBIOS over TCP/IP" the Domain Joins (via Quest RUM Move) are much more reliable. Has anybody else experienced this? (Can I get a witness?) Realizing that WINS is theoretically a dated technique for Name Resolution, it appears to me that the Join operation are more reliable when NetBIOS is involved. Now, I've done a bit of reading here at the Microsoft Sites. I found a thread or a Technet Article that mentioned NetBIOS over TCP/IP relies on the standard Windows RPC ports (137, 138, and 139) while operations over "pure" TCP/IP use port 445. I've always understood 445 to be used for file transfer operations, but is SMB traffic used for Domain Joins as well? Is it as reliable a mechanism as RPCs? Am I off-base here? Any takers who can explain to me the Domain Join process from a networking level and what implications are added by enabling or disabling NetBIOS over TCP/IP? Thanks in advance! Kind Regards, - Rick Gregson rick.l.gregson@hp.com rick.gregson@convergenttechonline.com

We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync. When the time is out of sync between client and server you then get problems with the password age for machine accounts. ref: http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx Also we now have disabled system restore by policy, but it is not stopping restore by startup repair. We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449. This will probably help if you have this issue on wireless clients that rarely connects on LAN. We had Microsoft to look into the case and they agreed it was the best solution to avoid the problem. Ref: "Hi, I have gathered more information about startup repair, I have seen cases where it brings the system to an old system state , this happens in the background and it is not noticed by the users. If repairs are not successful, you'll see a summary of the problem and links to contact information for support. Your computer manufacturer might include additional assistance information. Did you see this when it breaks the secure channel? I still think that disabling startup repair is the best way to go in this case Best Regards, <u5:p> </u5:p> Microsoft Premier Platform Desktop Engineer " In other words, this is a design failure of win7 because there are no fix to the problem and it's only related to clients in domain. Therefore we are now depolying a program to disable startup repair on all our 24.000 Win7 clients. Make a package without source files. Programs are as follows: Command line for x86 without Bitlocker: bcdedit /set {default} bootstatuspolicy ignoreallfailures x64 without Bitlocker: %windir%\sysnative\bcdedit /set {default} bootstatuspolicy ignoreallfailures With Bitlocker x86 run 3 steps: 1. manage-bde -protectors -disable C: (deactivates bitlocker protection) 2. bcdedit /set {default} bootstatuspolicy ignoreallfailures (disable startup rapair) run with dependency to step 1. 3.manage-bde -protectors -enable C: (enables bitlocker protection) run with dependency to step 2. With Bitlocker x64, 3 steps: 1. %windir%\sysnative\manage-bde -protectors -disable C: 2. %windir%\sysnative\bcdedit /set {default} bootstatuspolicy ignoreallfailures (run with dependency to step 1.) 3. %windir%\sysnative\manage-bde -protectors -enable C: (run with dependency to step 2) Program settings: specify plattforms on respective clients run wheter or not a user is logged on with admin rights unc name Collections: You need to find and sort all the clients in the above 4 groups Advertisement settings: Mandatory, scheduled When on LAN Run the program from distribution point When unreliable Run the program from distribution point Allow users to run independently Allow clients to fall back to unprotected dps when connection is not available I hope this will finally put rest to your minds (and bosses). Good luck! -Fowler

Hey Everyone, I thought I could give a little insight. I ran into this problem recently. However, we can certainly rule out with 100% accuracy any software installs, updates, upgrades etc. The reason I know this is because I have a test server that this just happened to. The good news is that this server is a virtual server, that being said, I just reverted back to a clean server state, with a snapshot after joining the domain. Hmmm, still getting the error. Although not resolved, I have eliminated all the above. What I believe it is, is another DC on the domain has lost its trust. This has nothing to do with the PC giving the error, but rather the PDC. Thoughts? PaulDuramaxster