The trust is set in Active Directory Domains and Trusts, but until you can resolve the DNS / NETBIOS problem you won't be able to recreate the trust. The technology for trusts has not changed much in ages, you need a really basic NETBIOS type connection.
You have to be able to resolve by both ping and nslookup the COMPUTERNAME of the DC (not the FQDN or any other record), Your DC also has to know that this machine is a DC for the domain you want to contact. Any locally stored AD information will be out of date if replication has failed since March.
You then have to have a route to and from that IP address.
You will have to brute force the connection:
That is why I suggested the LMHOSTS file, it is a brute force method using a text file. It will override any errors in your DNS and AD and will ensure that each DC can find the DC of the other domain.
"Use the following steps to create a correctly formatted LMHOSTS file: 1.Using a text editor, for example, Notepad.exe or Edit.com, create a file called LMHOSTS, and then save it in the following folder:
%SystemRoot%\System32\Driv
Note that the file name is LMHOSTS, with no extension. If you are using Notepad.exe, Notepad.exe may automatically append .txt. If Notepad.exe does this, rename the file, using no extension, at a command prompt.
Add the following entries to the LMHOSTS file: It is important to get the exact case and number of spaces.
x.x.x.x HQ-PDC #PRE #DOM:HQDOMAIN
x.x.x.x "HQDOMAIN_NAME \0x1b" #PRE
Note also that DOMAIN_NAME in this entry is case-sensitive. Make sure to use all capital letters. Replace 10.0.0.1 with the IP address of your primary domain controller (PDC), replace PDCName with the NetBIOS name of your PDC, and replace DOMAIN_NAME with the name of your Windows NT-based domain.
Then when you resolve computer NetBIOS names to IPs you can think about going into AD Domains and Trusts to delete then recreate...
Historically trusts existed before domain controllers were always DNS servers, so to fix them you always have to go back in time.
You have to be able to resolve by both ping and nslookup the COMPUTERNAME of the DC (not the FQDN or any other record), Your DC also has to know that this machine is a DC for the domain you want to contact. Any locally stored AD information will be out of date if replication has failed since March.
You then have to have a route to and from that IP address.
You will have to brute force the connection:
That is why I suggested the LMHOSTS file, it is a brute force method using a text file. It will override any errors in your DNS and AD and will ensure that each DC can find the DC of the other domain.
"Use the following steps to create a correctly formatted LMHOSTS file: 1.Using a text editor, for example, Notepad.exe or Edit.com, create a file called LMHOSTS, and then save it in the following folder:
%SystemRoot%\System32\Driv
Note that the file name is LMHOSTS, with no extension. If you are using Notepad.exe, Notepad.exe may automatically append .txt. If Notepad.exe does this, rename the file, using no extension, at a command prompt.
Add the following entries to the LMHOSTS file: It is important to get the exact case and number of spaces.
x.x.x.x HQ-PDC #PRE #DOM:HQDOMAIN
x.x.x.x "HQDOMAIN_NAME \0x1b" #PRE
Note also that DOMAIN_NAME in this entry is case-sensitive. Make sure to use all capital letters. Replace 10.0.0.1 with the IP address of your primary domain controller (PDC), replace PDCName with the NetBIOS name of your PDC, and replace DOMAIN_NAME with the name of your Windows NT-based domain.
Then when you resolve computer NetBIOS names to IPs you can think about going into AD Domains and Trusts to delete then recreate...
Historically trusts existed before domain controllers were always DNS servers, so to fix them you always have to go back in time.
