Trust Relationship Server 2008 R2 and Win 7 Pro

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hello,

On several machines we have rolled out, we are getting the following error when trying to log on to the machine:

"The trust relationship between this workstation and the primary domain failed."​

I have logged on locally to the machines, and removed them from the domain (changed to workgroup) and also removed them from the Active Directory, restarted machines, and rejoined to the domain - this fixes them temporarily.

These same machines then get the above error intermittently, and the above process needs to be done to resolve the error.

Any ideas?

HS.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Are all the client PC's Windows 7? Also how are they connected to the network i.e. attached to a domain or workgroup.

With more information we should be able to point you in the right direction.

 

Hi onoski, thanks for your reply.

Yes all the client PC's are Windows 7 Professional, and are connected to the Domain Controller which is running Windows Server 2008 R2.

HS.

 

Sounds odd. Is the time server and time sync between DC and workstations working fine?

 

Hi LukeP, thanks for your reply.

As far as I am aware, I will double check this tomorrow however. Thank you for the advice.

HS.

 

Yeah, time sync is something one should verify. Here's another few things that come to mind (plus elaboration on the time sync issue):

- Do you have more than one machine with the same name on the network?
- Did you "ghost" images of Windows 7, and if so, did you sysprep them properly before joining to the domain?
- Time skews can cause funny issues. Check the time provider for your DC's, and that all non-PDCe's receive the correct time from the PDCe FSMO holder. Verify that the appropriate ports are open and use several of the following commands to verify time source such as:

A synchronized enterprise time is critical to the Active Directory environment. See http://technet.microsoft.com/en-us/library/cc786897.aspx for more information.
To configure the Windows Time service on CONTOSODC1 which is the DC holding the default PDC (FSMO) role, perform the following:

Code:

1) Open UDP port 123 for outgoing traffic if needed.
2) Open UDP port 123 (or a different port you have selected) for incoming NTP traffic.
3) Open a Command Prompt and type the following command to configure the PDC emulator and then press ENTER:
W32tm /config /manualpeerlist:"ntp1.contoso.com, ntp2.contoso.com" /syncfromflags:manual /reliable:yes /update
4) Verify the settings using the following command:
C:\Users\administrator>w32tm /query /source
C:\Users\administrator>w32tm /query /peers /verbose
C:\Users\administrator>w32tm /query /configuration /verbose
5) These settings will provide information on the source of the time service, the status of the configured
peers, as well as a full verbose dump of the time service configuration on the server on which the check
was run. We can also configure GPOs to set a different NTP server for specific clients. This is done by
creating a new GPO that applies only to the specific computers, using the setting under:
Computer Configuration \ Policies \ Administrative Templates \ System \ Windows Time Service \ Time Providers.

- You did not mention how many DCs you have, but if you do have several, you may have a directory mismatch/corruption, and occasionally a client machine will try to authenticate with a mal-functioning DC resulting in these errors. Use the following to do general DC troubleshooting:

1) Use DCDIAG /v on each domain controller and check for any errors
2) Use NETDIAG /v on each domain controller and check for any errors
3) Use REPADMIN /showreps on each domain controller to verify replication partners

- Considering it seems to be the client machines which are not working, I'm suspecting there's a DC conifguration error, or worse, a driver or NIC hardware error. This is not unheard of and poor network drivers are known to cause errors like this (typically on client machines). But more importantly, it might mean you need to verify several network related issues (I've seen this happen due to the following):

1) Verify duplexing/speed capabilities of your network and adjust the client machines accordingly
2) download the latest NIC drivers and apply accordingly
3) verify integrity of network cables
4) verify integrity of switches/routers

Maybe that will get you off to a start... just a few things that popped into my head. I've personally seen this issue in situations where some Cisco switches were 1gbit capable and configured as such, but the drivers on the client side were poor and did not fully support the 1gbit capabilities of the network card. It caused strange issues... Another problem has been a broken switch, but this can usually be tested by moving the machine around so that it has a succesful connection to a DC while bypassing the faulty switch.

ah well, back to work now

 

Okay, might want to check Windows firewall is switched off on the client PC's as well as the svr 2008 DC. This however, needs to be verified to make sure you have a firewall on your network i.e. Cisco pix or Nokia etc.

The reason being Windows firewall, inbuilt software is notorious for locking down lots of network and RDP related connections. Lets know how you get on

 

onoski: a default installation of Windows 2008 R2 or Windows 7 will not produce issues via Windows Firewall in a domain environment. The firewall can be enabled just fine and it will work. In fact, it would not be a recommended action to disable the firewall in the first place.

We're not talking here about XP or 2003 so please don't confuse them with R2/7. XP had some issues, but even that would work in a default installation.

(of course, if someone went and fiddled around with the Firewall, then that's another issue)

 

Another thing to keep in mind regarding time issue, if you're using ESX, make sure your ESX hosts are correctly configured with the NTP server and check the times on the host as well... We had issues with that in the past.

 

Hi Shinigami, thanks for your reply.

To answer some of your questions:

There is only one DC, and 30 Clients. There were two seperate ghost installations, we used Acronis. I am not sure whether SYSPREP was used properly, will double check with colleague tomorrow as he dealt with the OS rollout. The installations were slightly different, but fundamently the same (teacher machine and computer suite machine) - just differing software, active whiteboards, and SIMS etc. All machines are named differently, should be no conflicts there.

Will check everything you suggested tomorrow, thank you for the response!

HS.

 

Hello HangoverSpecialist,

Thank you for using Acronis products. Please accept my apologies for the inconvenience and I will do my best to assist you.

The situation that you describe is caused by a known issue in our software when you use the option to Change SID during deployment template creation. We have been assured by our Development team that this problem will be fixed in the upcoming update for Acronis Snap Deploy.

As a workaround, please do not use this option. I am very sorry for all the trouble.

If you need additional assistance or have any other issues, please let me know.

Thank you.

Anton.