Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DNS Error? 1

Status
Not open for further replies.

BiJae

Programmer
Oct 1, 2002
154
US
This morning when I came in to the office several users approached me stating they could not connect to the share drives. I verified that they were not able to attach using their credentials. I restarted the server and then launched my workstation. I was able to connect using the UNC path.

To further test I logged in as another user on my workstation. This time the computer reported that the server was unavailable using the UNC path. I logged out and logged back in as me. Everything connected as expected using the UNC path.

This confuses me, the same computer will resolve for one user that's logged in but not another user that logs in just a moment later?

Yet a third oddity happened a few moments later. I was reconnecting every one to the IP address when I found that one user was able to connect to \\DATA\SHARE but not to \\DATA\USER. This made me scratch my head a little harder.

Can some one shed some light on this problem for me? As it stands now I cannot run my backups because my backup server cannot locate the DATA server.

Thank you,



"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
I forgot to post the error message that I receive when I try to browse to DATA from EX1 or EXCHNG.

Code:
\\Data is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

Logon Failure: The target account name is incorrect

None of the share permissions have changed in the past two months.


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
Let me compare your findings in the _msdcs and other subzones with those on some servers that I manage. That's probably where your problem lies.

One thing I'll say though: you don't want to completely remove your DNS. Always keep a server with the records.

The errors you are getting are with DNS records within the _msdcs; their role is to facilitate Active Directory queries. Because of this, regular DNS functionality like your web browser won't have trouble. It's stuff that requires authentication and share enumeration that are going to run into issues.

And it's good that you found out about not wanting to un-DC an Exchange server. I've always shied away from Exchange/DC shared servers, and didn't know the damage would come from removal as well as promo.

ShackDaddy
 
I ran the DCDIAG tool on EX1 again. The results are still reporting that the server holding the PDC is down. However, this time it's reporting that the PDC is Ex1.
Code:
   Running enterprise tests on : tcud.state.tx.us
      Starting test: Intersite
         Skipping site Default-First-Site-Name, this site is outside the scope
         provided by the command line arguments provided.
         ......................... tcud.state.tx.us passed test Intersite
      Starting test: FsmoCheck
         GC Name: \\Ex1.tcud.state.tx.us
         Locator Flags: 0xe00001bd
         PDC Name: \\Ex1.tcud.state.tx.us
         Locator Flags: 0xe00001bd
         Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
         A Time Server could not be located.
         The server holding the PDC role is down.
         Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 135
5
         A Good Time Server could not be located.
         KDC Name: \\Ex1.tcud.state.tx.us
         Locator Flags: 0xe00001bd
         ......................... tcud.state.tx.us failed test FsmoCheck


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
I found a network similar to yours, with two domain controllers in it. Here's what the records in the _msdcs folder look like:

(same as parent) SOA [29], server.domain.com., hostmaster
(same as parent) NS server.domain.com
GUIDstring#1 Alias server.domain.com
GUIDstring#2 Alias server.domain.com
(same as parent) NS server2.domain.com
GUIDstring#3 Alias server2.domain.com

Both servers also have A records in the actual domain forward lookup zone.

That last error message you posted really makes me think that the copy of the AD on DATA is not working/synced with the one on EX1. If it weren't an Exchange server, I'd dcpromo it down and then up again to refresh the settings, but in your situation, I'm not quite sure what the next step would be. Let me ask around a bit and get back to you.

ShackDaddy
 
Would it help to dpromo DATA removing AD and then installing it again?


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
An attempt to remove AD from DATA produced the following error:

Code:
The operation failed because:

Active Directory could not transfer the remaining data in directory partition CN=Schema,CN=Configuration,DC=tcud,DC=state,DC=tx,DC=us to domain controller tcud-EX1.tcud.state.tx.us.

"The directory service was unable to transfer ownership of one or more floating single-master operation roles to other servers."

I'm unclear if the problem is with DATA or EX1. Both EX1 and Exchng cannot communicate with DATA using UNC. Now when I tried to remove AD from DATA it gave me a communication error back to EX1. Of course this could all be tied to DNS being corrupted...

I'm scratching my head...


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
The error is saying that at least one of the 5 FSMO roles are still being held by DATA. When you did the role seizures, did you sieze all 5, or just 3? Try getting all five and then dcpromo DATA again.

How did your _msdcs root records look compared to mine?

ShackDaddy
 
The _msdcs folders don't compare at all. Mine are as follows

GUIDstring#1 ALIAS ex1.tcud.state.tx.us
GUIDstring#2 ALIAS data.tcud.state.tx.us
GUIDstring#3 ALIAS data.tcud.state.tx.us

I have no SOA or NS records as you have listed.

I ran the seizure again on EX1 but still get the application directory error on DATA when I try to demote it.


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
Did you try to seize all five on EX1?

I'm actually more concerned that you seem to be missing one of the GUID records. The one that we played with earlier in this thread is in there, right?

Apparently each DC keeps two GUID records aliased to its name.

ShackDaddy
 
Yes, the one we worked with earlier is there that's the one registered to Ex1. The server Data has two registered to itself.


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
Those articles definitely sound like my situation. I've been doing some research using them. I've found that in Active Directory the properties of Data do not register Service Pack 1. When I right click on my computer it says that SP1 in installed, however, AD doesn't register it in the properties of DATA under domain controllers. Could this be a cause of the problem?


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
I've been running some of the more specific tests using DCdiag as described in the article you provided. When I run dcdiag /test:DNS /s:data from Ex1 I get the following results:

Code:
C:\>dcdiag /test:DNS /s:data

Domain Controller Diagnosis

Performing initial setup:
   [data] LDAP search failed with error 58,
   The specified server cannot perform the requested operation..
   ***Error: The machine, data could not be contacted, because of a bad net
   response.  Check to make sure that this machine is a Domain Controller.

I'm not sure how to go about fixing the LDAP error aside from deleting the server and bringing it back in to the tree under a new name. Are there any ways to update the LDAP settings for the computer already in existence?


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
I've been doing some more tests and I think I can see a direct cause of the DNS problems. When I run DCDiag on EX1 I see the following message:

Code:
The host 81db2227-71a6-494b-bd3d-4bde1934eee5._msdcs.tcud.state.tx.us could not be resolve to an IP address. Check the DNS server, DHCP, server name, etc.

Althought the GUID DNS name (81db2227-71a6-494b-bd3d-4bde1934eee5._msdcs.tcud.state.tx.us) couldn't be resolved, the server name (ex1.tcud.state.tx.us) resolved to the IP address (192.168.20.106) and was pingable. Check that the IP Address is registered correctly wtih the DNS Server.

I have run ipconfig /registerdns however it doesn't put the correct registrations in there. How can I register this address with 81db2227-71a6-494b-bd3d-4bde1934eee5._msdcs.tcud.state.tx.us in DNS?


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
I thought that was the exact GUID we talked about earlier. Wasn't it already existing in the _msdcs root? If you drill down into the other subfolders, maybe there's a place it should exist but doesn't. For it to resolve, it needs to have a CNAME record that points at EX1. Let me look at a comparable DNS tree and see if there are some other records that refer to that GUID that might be missing on yours.

Have you tried this:

On both DC's, at the command prompt, type "dcdiag /fix", then "net stop netlogon" and "net start netlogon" (again with out the quotes) to finalize the changes.

Run dcdiag one more time to check the results and see if the last errrors you mentioned go away.

ShackDaddy
 
Thank you for your continued to support, I'm kinda lost here. I really appreciate your taking the time to help me out with this.

I ran DCDIAG /FIX on both servers this morning along with net stop and start of netlogon. (oddly enough ex1 says that net is not a known command so I stopped and started using the services interface).

81db2227-71a6-494b-bd3d-4bde1934eee5._msdcs.tcud.state.tx.us is exactly the one we were looking at before. I was asked if that record was in my _msdcs folder. Indeed it is. And it appears to map to ex1.state.tx.us. I've not figured out a way to map it to an IP address.

In that same folder I have to GUID records for DATA. I'm not sure which is a good one and which can be deleted. I'm tempted to delete one of these records to see if that could be causing the communication problems with the server.

I knew these servers were a bit tangled when I got this job a few months ago. However, the more I uncover the more I realize how bad a shape they have been in.


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
I wouldn't delete anything.

Are both servers pointed at the same single server for DNS, or does each one point at itself? They should both point at a single server, which I assume would be EX1.

Make sure the DHCP CLIENT (yes, CLIENT!) services are running on both servers. That's required for the servers to properly created necessary records in the DNS. If either had the service disabled, enable it, start it, and re-do what I had you do in the last post.

Lastly, run the DNS Admin on both servers and make sure that BOTH have the _msdcs subdomain. If one of them was missing it, that might explain why one of your servers isn't resolving things that seem like it should be able to resolve.

The GUID resolves to the servername via the CNAME record. And then the CNAME record resolves to the IP in the other Forward lookup zone for your domain.

ShackDaddy
 
I have both servers pointing to Ex1 in the Network Adapter TCP/IP properties.

Both servers had DHCP CLIENT services running. And both servers have _msdcs under the forward zone.




"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
At this point, particularly if we want to worry more about the palpable symptoms than the errors, we should probably carefully examine this document:

How Domain Controllers are Located in Windows:

It includes some testing and diagnostic procedures to help narrow down problems. Many of them we've done already, but some we haven't.

ShackDaddy
 
I've run through these tests and have success with them.

1. event viewer shows problems reporting back to a dns server not in our network 141.198.136.6

2. IPCONFIG /ALL shows things as they should be

3. Ping between servers by name resolves and reports back

4. Netdiag reports several problems with DNS some of which are about registering our domain information to the server mentioned above 141.198.136.6

5. I ran netdaig /fix on both DATA and EX1

6. I used the NLTEST tool on both data and EX1. Both servers reported back that EX1 was the domain controller for the network. When I tried to run it for the DC Data it reported that only SYSVOL was up and the server itself was down. (this report was consistent when run on both servers)

7. I could use NSLOOKUP to find DATA and EX1 on the network, this worked on both servers.

8. I ran IPCONFIG /REGISTERDNS on both servers just as a precautionary measure

9. DCDIAG results are the same as they were before

10. I was able to launch the LDP tool and connect to the server, however, I wasn't able to navigate beyond that due to my own limited knowledge.

11. Netlogon debug was on for EX1. I browsed that log back to November 16 when everything was working normal. Between then and now I didn't see anything different. Is there something specific I should be looking for?

12. I haven't used network monitor to look at traffic between the two servers.

As a stop gap measure I've used the File Server Migration Utility to copy the files to another server so I have a back up copy of my files. However that disk is running low on space. I'm getting a little panicky and desperate.


"If the only prayer you said in
your whole life was, 'thank you,'
that would suffice."
-- Meister Eckhart
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top