trust relationship bet. this workstation & the primary domain failed

[temmari]

trust relationship bet. this workstation & the primary domain failed

Hello, I need help again. We have several computers withWin7 Ent and Pro 64 and 32 bit. . For some i-dont-know reason, it showed 'the trust relationship between this workstation & the primary domain failed' when we login. It happened few times already. The issue is resolved if we reconnect the pcs to the domain. Please lhelp me understand why this keeps happening and the if there is a permanent fix. I will appreciate all ideas.

 

[WindowsStar]

A client had the same problem; here is what we did to fix it.

Step 1: Make sure the Date/Time/Time Zone are correct on all DC's. Connect to the internet and update the time.
Step 2: Get and take all Microsoft Updates. Reboot as required. Do one DC at a time.
Step 3: Shutdown (i.e. power off) all but one DC. Wait about 5 minutes and then shutdown the Last DC.
Step 4: Wait about 5 minutes and then turn ON the Last DC that was turned off.
Step 5: Wait about 5 minutes and then turn on all remaining DCs.
Step 6: Wait 30 minutes and then unjoin and reboot any computer that was not working. Set the Time/Date/Time Zone and rejoin it to the domain.

The above should correct the problem and prevent other machines from dis-joining.

 

[temmari]

thanks a lot.. will try it first and i will let you know...

 

[temmari]

Sorry, i was thinking of all clients being affected. So we cant do what you advise. What about if there are only few users who are affected? Like 2-5 users? PLease share ideas.

 

[xarden]

We had this problem too. Now Resolved. The easy way.

Firstly, an explaination of the situation:
I image the same PC many times in a week. To make it simple, I'l refer to only one of my (four) machines.
Now when I have an image on this machine, the Computer Name is MFBOX2 as assigned by the DNS. It is connected to the domain as MFBOX2 in an OU.
I then downloaded another image onto that PC. The computer name was also called MFBOX2, again from the DNS.
I then removed that 2nd image from the domain, and renamed the computer to IMAGING-SCMS4.
I uploaded that image (for my backups) and downloaded the first image again.

This is where you'll run into the above problem.

Problem Explained:
Windows thinks it is still connected to the domain.
The domain no longer holds MFBOX2 anymore, as it was removed previously.
Windows says to the DC, "Hello, log this person in please."
The DC replies, "Who are you? Im sure you just left." and does not trust the windows machine anymore.

The issue is resolved if we reconnect the pcs to the domain.

Your right.

Windows then says, "Ok, whatever. Bye." and produces the error message.
By rejoining windows to the domain, the Domain Controller now recognises it again, and the trusted relationship is regained.

In short, what I believed happened with you, assuming you dont image, is that somehow the computer object was removed from the DC manually and not from the PC in question.

Sorry, I did try to make it technical, but analogies are more fun.

 

[WindowsStar]

Sorry, i was thinking of all clients being affected. So we cant do what you advise. What about if there are only few users who are affected? Like 2-5 users? PLease share ideas.

http://www.sevenforums.com/network-...tation-primary-domain-failed.html#post1076360

The above will work for 2 or 3 machines as well.

What we have seen happen is that for no reason the AD database is out of sync or has some very minor corruption that cannot be auto-corrected while the DC is on or it is really something we could never figure out what it was (all speculations). Microsoft's Engineers could not directly find the problem. But complete rebooting your Domain Controllers works. If you know one DC is running better than another that may be the last one you want to turn off.

If you want to try an interim step you could just power cycle each DC one at a time waiting 15 minutes between each DC reboot. Assuming you are cannot shutdown all your DCs at the same time.

All this is inherent of Windows needing to be rebooted every once and a while. We assume this is why the complete Domain Shutdown fixed all issues. Currently on all my accounts I have the DCs setup to reboot once a week at different times. Say DC1 reboots on Friday late at night, DC2 reboots on Saturday and DC3 Reboots Sunday on a 3 DC Domain. This has resolved a lot of issues, before the DCs would run 24x7x365 with no reboot unless there was a critical Microsoft Update. Microsoft Updates for DCs sometimes it could be months before you get a reboot. -WS

 

[WindowsStar]

We had this problem too. Now Resolved. The easy way.

Firstly, an explaination of the situation:
I image the same PC many times in a week. To make it simple, I'l refer to only one of my (four) machines.
Now when I have an image on this machine, the Computer Name is MFBOX2 as assigned by the DNS. It is connected to the domain as MFBOX2 in an OU.
I then downloaded another image onto that PC. The computer name was also called MFBOX2, again from the DNS.
I then removed that 2nd image from the domain, and renamed the computer to IMAGING-SCMS4.
I uploaded that image (for my backups) and downloaded the first image again.

This is where you'll run into the above problem.

Problem Explained:
Windows thinks it is still connected to the domain.
The domain no longer holds MFBOX2 anymore, as it was removed previously.
Windows says to the DC, "Hello, log this person in please."
The DC replies, "Who are you? Im sure you just left." and does not trust the windows machine anymore.

The issue is resolved if we reconnect the pcs to the domain.

Your right.

Windows then says, "Ok, whatever. Bye." and produces the error message.
By rejoining windows to the domain, the Domain Controller now recognises it again, and the trusted relationship is regained.

In short, what I believed happened with you, assuming you dont image, is that somehow the computer object was removed from the DC manually and not from the PC in question.

Sorry, I did try to make it technical, but analogies are more fun.

I think what xarden is talking about here is:

If you take an image of a machine that has already been added to a domain and then use it on another machine you will have issues, and there can be many.

“Best Practice” is to never add your image machine to the domain. Work out your entire configuration; make an image, then test the image by adding that machine to the domain. If it works then you are done and you have your non-joined image. If it does not, you dis-join the test machine from the domain, wipe it, and put your saved non-joined image back on that machine in the un-joined state and fix your configuration. You keep doing this until you get an image that works on the domain but is not joined to the domain.

Next: If you image a machine join it to a domain, then rename it to another name of a machine what is no longer in use but the machine name is still in AD (in other words the old machine was never dis-joined from the domain) you will run into issues because AD stores the GUID of the machine. So even though the machine has been added to the domain and is named, a name that is in AD the GUID will not match and you will have issues. You should always dis-join any machine you are going to remove from the domain and make sure its name is deleted out of AD. If you wish to re-use a machine name then it is not problem when you add the new machine to the domain. (wordy sorry about that) -WS

 

[xarden]

I think what xarden is talking about here is:

If you take an image of a machine that has already been added to a domain and then use it on another machine you will have issues, and there can be many.

Only if the image is used on multiple machines with the same name, at the same time.

Next: If you image a machine join it to a domain, then rename it to another name of a machine what is no longer in use but the machine name is still in AD (in other words the old machine was never dis-joined from the domain) you will run into issues because AD stores the GUID of the machine. So even though the machine has been added to the domain and is named, a name that is in AD the GUID will not match and you will have issues.

Also true.
However, I have successfully managed to move a joined-domain image from one machine to another without problems, as long as the original machine gets wiped.
If it doesnt get wiped, then you've got the problem in the first quote.

You should always dis-join any machine you are going to remove from the domain and make sure its name is deleted out of AD. If you wish to re-use a machine name then it is not problem when you add the new machine to the domain. (wordy sorry about that) -WS

You dont necessisarily need to dis-join... rather than remove from AD once the machine no longer exists, or has been reimaged and exists under a different name.

 

[WindowsStar]

I think what xarden is talking about here is:

If you take an image of a machine that has already been added to a domain and then use it on another machine you will have issues, and there can be many.

Only if the image is used on multiple machines with the same name, at the same time.

Same image on many machines with the same name. You cannot do that unless they are all on different domains????

Next: If you image a machine join it to a domain, then rename it to another name of a machine what is no longer in use but the machine name is still in AD (in other words the old machine was never dis-joined from the domain) you will run into issues because AD stores the GUID of the machine. So even though the machine has been added to the domain and is named, a name that is in AD the GUID will not match and you will have issues.

Also true.
However, I have successfully managed to move a joined-domain image from one machine to another without problems, as long as the original machine gets wiped.
If it doesnt get wiped, then you've got the problem in the first quote.

You should always dis-join any machine you are going to remove from the domain and make sure its name is deleted out of AD. If you wish to re-use a machine name then it is not problem when you add the new machine to the domain. (wordy sorry about that) -WS

You dont necessisarily need to dis-join... rather than remove from AD once the machine no longer exists, or has been reimaged and exists under a different name.

Respectfully this is a rookie mistake. If you pull a machine and don't remove it from the domain you will most likely forget to remove the name from AD. It is best if you are removing a machine to just un-join it that way you are sure you have done it right. I know there are times you CANNOT do this hard drive crashes (etc.) but in that case you would be removing the name from AD manually while re-imaging the machine to get it back on line. I see so many AD's that are polluted with all kinds of names that never get removed because they don't un-join the machine or forget to remove the name from AD. This gets much much worse when you have 4, 5 or 10 Administrators and everyone is just removes the machine without any thought to AD. Then you get some junior admin trying to add a machine with a name that is already in AD and they don't know why and spend 3 days trying to figure it out, huge waste of time. -WS

 

[xarden]

Same image on many machines with the same name. You cannot do that unless they are all on different domains????

An example would be to build on machine A, join AD, make image, drop image onto another machine, use both machines.
Ensuring both machines are of exact motherboard specs/chipsets, this will work without the disk or OS crashing.

Perhaps I should specify two terms we also use regarding images: Gold, and Prep.
Gold images are build on 3 machines, all identical. These images do not get deployed anywhere except these three machines, solely for the purpose of using Box2 to build ImageA, Box3 for ImageB, Box4 for ImageC. When finished building ImageA, deploy ImageD to Box2. When finished with ImageB, but need more work on ImageA, deploy ImageA on Box3.

Prep images, are the above mentioned Gold's, which have run through the sysprep procedure. At reboot, the image is taken before restarting.
The Prep images are the ones that get deployed to the field.

Respectfully this is a rookie mistake. If you pull a machine and don't remove it from the domain you will most likely forget to remove the name from AD. It is best if you are removing a machine to just un-join it that way you are sure you have done it right. I know there are times you CANNOT do this hard drive crashes (etc.) but in that case you would be removing the name from AD manually while re-imaging the machine to get it back on line. I see so many AD's that are polluted with all kinds of names that never get removed because they don't un-join the machine or forget to remove the name from AD. This gets much much worse when you have 4, 5 or 10 Administrators and everyone is just removes the machine without any thought to AD. Then you get some junior admin trying to add a machine with a name that is already in AD and they don't know why and spend 3 days trying to figure it out, huge waste of time. -WS

I agree.
Our dev domain is full of obsolete machines that have been reimaged without prior disjoining.

The senior site techs who do the imaging in the production labs/classrooms should be aware of the proper procedure you describe. They should be disjoining the current machine before deploying a new/updated Prep image.
We dont do this in dev.

Once deployed, the machine is restarted. During sysprep, several custom scripts are run. One picks up the machine name from DNS, and attempts to join AD. But if it already exists in AD (error 5?), then a random alphanumeric name is created and used instead.
This is partly to ensure the machine gets joined flawlessly for the enduser in the morning.
2nd partly, if a machine fails to boot due to whatever error (tweaking failed, virus, etc.) and the machine cannot boot to the OS to be able to be disjoined, The machine simply get reimaged.
The latter is what would be most contributing to any obsolete items in the production AD.

So you're most certainly not wrong.
But we also have several systems that need to work together, so we do have a couple 'less than ideal' ways of going about things. But it all works, and it all works very well in the end.

 

[pparks1]

For my images, I build the reference machine, put it on the domain, set up all of the apps that I need...then I run sysprep and set it to OOBE (out of box experience). When the image is deployed elsewhere, upon first boot you choose a machine name, username and whether or not to put it on the domain. Sysprep removes the unique identifiers from the machine....and the mini-setup puts new ones in place. So, rather than a a multi-hour install, you answer about 5 questions and you are done.

 

[xarden]

Thats also right. The unattend.xml should be able to answer most of those questions for you.

5 questions on each 7000 machines is a lot of questions.

 

[WindowsStar]

Same image on many machines with the same name. You cannot do that unless they are all on different domains????

An example would be to build on machine A, join AD, make image, drop image onto another machine, use both machines.
Ensuring both machines are of exact motherboard specs/chipsets, this will work without the disk or OS crashing.

Perhaps I should specify two terms we also use regarding images: Gold, and Prep.
Gold images are build on 3 machines, all identical. These images do not get deployed anywhere except these three machines, solely for the purpose of using Box2 to build ImageA, Box3 for ImageB, Box4 for ImageC. When finished building ImageA, deploy ImageD to Box2. When finished with ImageB, but need more work on ImageA, deploy ImageA on Box3.

Prep images, are the above mentioned Gold's, which have run through the sysprep procedure. At reboot, the image is taken before restarting.
The Prep images are the ones that get deployed to the field.

Respectfully this is a rookie mistake. If you pull a machine and don't remove it from the domain you will most likely forget to remove the name from AD. It is best if you are removing a machine to just un-join it that way you are sure you have done it right. I know there are times you CANNOT do this hard drive crashes (etc.) but in that case you would be removing the name from AD manually while re-imaging the machine to get it back on line. I see so many AD's that are polluted with all kinds of names that never get removed because they don't un-join the machine or forget to remove the name from AD. This gets much much worse when you have 4, 5 or 10 Administrators and everyone is just removes the machine without any thought to AD. Then you get some junior admin trying to add a machine with a name that is already in AD and they don't know why and spend 3 days trying to figure it out, huge waste of time. -WS

I agree.
Our dev domain is full of obsolete machines that have been reimaged without prior disjoining.

The senior site techs who do the imaging in the production labs/classrooms should be aware of the proper procedure you describe. They should be disjoining the current machine before deploying a new/updated Prep image.
We dont do this in dev.

Once deployed, the machine is restarted. During sysprep, several custom scripts are run. One picks up the machine name from DNS, and attempts to join AD. But if it already exists in AD (error 5?), then a random alphanumeric name is created and used instead.
This is partly to ensure the machine gets joined flawlessly for the enduser in the morning.
2nd partly, if a machine fails to boot due to whatever error (tweaking failed, virus, etc.) and the machine cannot boot to the OS to be able to be disjoined, The machine simply get reimaged.
The latter is what would be most contributing to any obsolete items in the production AD.

So you're most certainly not wrong.
But we also have several systems that need to work together, so we do have a couple 'less than ideal' ways of going about things. But it all works, and it all works very well in the end.

Thanks for the update and sharing!

 

[WindowsStar]

For my images, I build the reference machine, put it on the domain, set up all of the apps that I need...then I run sysprep and set it to OOBE (out of box experience). When the image is deployed elsewhere, upon first boot you choose a machine name, username and whether or not to put it on the domain. Sysprep removes the unique identifiers from the machine....and the mini-setup puts new ones in place. So, rather than a a multi-hour install, you answer about 5 questions and you are done.

We used to do this, however SysPrep does not seem to undo Group Policy Settings correctly if at all, or return the machine back to a pre-domain state. This may not be an issue in a Single-Domain but in a Multi-Domain it is a nightmare, because the machine is tattooed with the domain you joined to, and all that domains information and GPOs. I am not saying this does not work just that we found that super clean images that have never added to any domain work the best and we get least amount of down time and least amount of maintenance, repairs, strange issues, unknown issues, etc. creating and using the images this way. Just a matter of preference I am sure. Thanks for sharing!

 

[pparks1]

We used to do this, however SysPrep does not seem to undo Group Policy Settings correctly if at all, or return the machine back to a pre-domain state. This may not be an issue in a Single-Domain but in a Multi-Domain it is a nightmare, because the machine is tattooed with the domain you joined to, and all that domains information and GPOs. I am not saying this does not work just that we found that super clean images that have never added to any domain work the best and we get least amount of down time and least amount of maintenance, repairs, strange issues, unknown issues, etc. creating and using the images this way. Just a matter of preference I am sure. Thanks for sharing!

You could be right. For me, the boxes that I image always go back into that very same domain...so the group policy components and such would always need to be in place anyway.