DNS Error? 1

[BiJae]

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,

http://www.bijae.net

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

 

[BiJae]

I'm still on my squeegy hunt, trying to ferret out the problem with this DNS Server. I decided to run a displaydns from the IPCONFIG command. Here's what I get

C:\>ipconfig /displaydns

Windows IP Configuration

    exchng
    ----------------------------------------
    Record Name . . . . . : exchng.tcud.state.tx.us
    Record Type . . . . . : 1
    Time To Live  . . . . : 397
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 192.168.20.105

    1.0.0.127.in-addr.arpa
    ----------------------------------------
    Record Name . . . . . : 1.0.0.127.in-addr.arpa.
    Record Type . . . . . : 12
    Time To Live  . . . . : 93092
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    PTR Record  . . . . . : localhost

    wpad.tcud.state.tx.us
    ----------------------------------------
    Name does not exist.

    _ldap._tcp.ex1.tcud.state.tx.us
    ----------------------------------------
    Name does not exist.

    tcud-bdc
    ----------------------------------------
    Name does not exist.

    data.tcud.state.tx.us
    ----------------------------------------
    Record Name . . . . . : data.tcud.state.tx.us
    Record Type . . . . . : 1
    Time To Live  . . . . : 1009
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 192.168.20.100

    data
    ----------------------------------------
    Record Name . . . . . : data
    Record Type . . . . . : 1
    Time To Live  . . . . : 93092
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 192.168.20.100

    wpad.state.tx.us
    ----------------------------------------
    Name does not exist.

    _ldap._tcp.default-first-site-name._sites.ex1.tcud.state.tx.us
    ----------------------------------------
    Name does not exist.

    91de8727-9580-44db-b90b-5d1798b45451._msdcs.tcud.state.tx.us
    ----------------------------------------
    Record Name . . . . . : 91de8727-9580-44db-b90b-5d1798b45451._msdcs.tcud.sta
te.tx.us
    Record Type . . . . . : 5
    Time To Live  . . . . : 397
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    CNAME Record  . . . . : tcud-data.tcud.state.tx.us

    100.20.168.192.in-addr.arpa
    ----------------------------------------
    Record Name . . . . . : 100.20.168.192.in-addr.arpa.
    Record Type . . . . . : 12
    Time To Live  . . . . : 93092
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    PTR Record  . . . . . : data

    localhost
    ----------------------------------------
    Record Name . . . . . : localhost
    Record Type . . . . . : 1
    Time To Live  . . . . : 93092
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 127.0.0.1

    exchng.tcud.state.tx.us
    ----------------------------------------
    Record Name . . . . . : exchng.tcud.state.tx.us
    Record Type . . . . . : 1
    Time To Live  . . . . : 397
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 192.168.20.105

What I find most interesting about the return on the results of this command is the record for "91de8727-9580-44db-b90b-5d1798b45451._msdcs.tcud.state.tx.us"

As we discussed earlier we found it odd that I had two entries for data in my _msdcs records. What I find peculiar is that here we have only one of those _msdcs records appearing instead of a response for all three. When I run the same command on DATA (Also acting as a DNS server) I get only two entries for localhost and one entery for EX-1.

Does any one know if this record is causing the authentication issues between my two servers?

http://www.bijae.net

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

 

[BiJae]

SOLUTION!

I always like to end my posts with a solution for others to reference. I found the solution to this long drawn out problem today. The solution was to reset the kerberos passwords for the domain controller. Some how when The new server DATA was installed it received an invalid password from a server that didn't exist on the network at the time of installation? Not sure how or what on that, but here's the microsoft document and the instructions on how to resolve a similar issue.

http://support.microsoft.com/kb/260575

1. Install the Windows Support Tools from the Support\Tools folder on the Windows CD-ROM on the domain controller whose password you want to reset.
2. If you are attempting to reset the password for a Windows domain controller, it is necessary to stop the Kerberos Key Distribution Center service and set its Startup type to Manual prior to continuing with step 3.

Note: After you restart and verify that the password has been successfully reset, you can restart the Kerberos Key Distribution Center service and set its Startup type back to Automatic. Doing this forces the domain controller with the bad computer account password to contact another domain controller for a Kerberos ticket.
3. At a command prompt, type the following command:
netdom resetpwd /server:Replication_Partner_Server_Name /userd:domainname\administrator_id /passwordd:*
where Replication_Partner_Server_Name is the fully qualified DNS or NetBIOS name of a domain controller in the same domain as the local computer, and domainname\administrator_id is the NetBIOS domain name and administrator ID respectively, in the Security Accounts Manager (SAM) account name credentials format.

The "*" value to the /PasswordD: parameter specifies that the password should be typed using hidden characters when the command is submitted. For example, the local computer (which happens to be a domain controller) is Server1 and the peer Windows domain controller name is Server2. If you run Netdom on Server1 with the following parameters, the password is changed locally and is simultaneously written on Server2, and replication propagates the change to other domain controllers:
netdom resetpwd /server:server2 /userd:mydomain\administrator /passwordd:*
4. Restart the server whose password was changed (in this example, Server1).

Thank you ShackDaddy for sticking through this with me. Your assistance was invaluable!

Brian

http://www.bijae.net

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