Possible DNS issues with SOHO Domain Controller and Terminal Server



    We administrate two servers on our SOHO LAN, including one Domain Controller, and a Terminal Server.
    Joined to the domain is: the Terminal Server, and all Windows XP and Windows 7 workstations in the office.

    Network Overview
    # of workstations: 6 (Windows XP), 12 (Windows 7)
    # of servers: 1 Domain Controller (SBS 2008), 1 Terminal Server (SBS 2008)
    # of infrastructure equipment: two 24 port unmanaged switches, one WiFi Access-Point (not shown), ISP Modem, and a D-Link DSR-250 router

    Two nights ago we had a power outage that resulted in all equipment going down (the duration of the outage exceed our 30 minute UPS window) and fried the primary router (A Linksys RV series small business router).

    Soon after, the Linksys router was replaced with a brand new D-Link DSR-250 small business router. We reconfigured it as close to the Linksys as we could remember, ie: just admin password change, address and subnet configuration to 10.0.20.x, DHCP lease set at default (1 thru 254), and router DNS set to the domain controller

    Things worked okay for while. However, the next day no workstations were able to log onto the domain. Error "Windows cannot connect to the domain either because the domain controller is down or otherwise unavailable, or because your computer account was not found. Please try again later. If this message continues to appear contact your System Administrator for assistance." was thrown every time we tried to log onto a work station. No matter what credentials we tried.

    Some employees were able to log on because of their roaming profiles, and the terminal server log on was working for some users too because of roaming profiles.

    The bigger issues is that when logged onto the terminal server, it initially threw errors about accounts not existing or something, or accounts not having the proper privileges, as well as the same domain controller is down error as mentioned above. But after logging on with the local TS Administrator account, we were able to get in to the Terminal Server.

    At this time I was not aware of the workstations also being affected in the office, it was 11:00 at night. So, I figured that it was an isolated issue with the Terminal Server experiencing a certificate or authentication error with Kerberos or something and attempted to re-join it to the domain. So I went to the the System Properties and unjoined/re-joined to the domain. However, the domain controller kept throwing me errors again about permissions and accounts not existing. I tried both the NETBIOS (ex: DOMAIN) and the FQDN (DOMAIN.COM) type identifiers and used a variety of credentials including the DC's inbuilt Administrator account.

    I thought that this was funny and had experienced similar issues because of some DNS problems before at another site. So, I went to the DC Active Directory Users and Computers MMC snap-in and removed the Computer account for the Terminal Server. I then tried re-joining the domain from the TS. I had luck and the TS joined to the domain without issue.

    I then tried logging into the TS with various accounts. Only some worked. Log in was slow at first, but I related this to again to DNS issues. At this point I wasn't even sure if the TS was even handshaking with the Domain Controller at all. I was later convinced that this was the case when I noticed that the TS Computer account had not been re-created under the DC Active Directory MMC snap-in. I decided to recreate the TS computer account myself manually with default settings that Windows recommended to me using default "Domain Administrators" permissions and the same host name of the TS.

    I had some luck logging in and testing the connectivity with the DC from the Terminal Server by using some Active Directory user accounts that I changed the access permissions on (ie disable account, and password changes) and attempted to log back into the TS with those credentials. Some users failed to log in (the ones I disabled) as expected. However, it simply denied access when entering in the user name from the Windows 7 MSTSC (RDP) Client, it did not throw an error commonly expected like "Error: Cannot log in user. Insufficient privileges." However, when I disabled the user's TS access, I got the error like "Cannot log in. You do not have sufficient privilege to use remote access to this server." So I assumed this was normal because I was in the RDC client and not at the actual Windows Log-In where you need to press "CTRL-ALT-DEL".

    But this wasn't the end of my problems. The office workstations still cannot get in, and there are problems accessing user's home shares (that's the biggest problems of them all) that maps at log-on. I get the error "Failed to connect to network drive Z:" as a little bubble popup in the system tray. Our home shares are redirected to the user's My Documents folder so it's really important that they have access to it.

    I tried going to My Computer and clicking on the mapped share Z:, it had a red "X" over it and could not be accessed. I then tried to re-map the share manually to another drive letter like Y:, this too failed with thrown error like "Share cannot be found. The host cannot be contacted/resolved."

    I then tried my last line of hope, I manually entered in the UNC path into the address bar as "\\corp-pdc1" and it died with the same error. I also tried a full path of "\\corp-pdc1\Users\Brian" and that failed too.

    Now, I am thinking that this is somehow all DNS related. The DNS error log is full of warnings saying something about the DNS service could not start because of Active Directory synchronization was in progress or the like. I never got around to checking if the DNS services was started in Services.msc.

    Everything is dependent on the DNS server installed on the DC box and if it's down, nothing get's Internet. From what I can tell, the configuration is quite close to the default "DCPROMO" configuration done when setting up a domain controller. IE DNS and entries being created and installed automatically. All workstations and the TS have DNS entries (under the NIC options) added that reference to the Domain Controller The NIC NetBIOS on TS is set on automatic configuration.

    The only thing changed was the router, that is all. Nothing else was adjusted or changed, other than the modifications to resolve the issue on equipment mentioned in this post. I am lost and can't figure out what's causing these problems. The only configuration added to the router was what was mentioned at the beginning of this post. Beyond that, it's all defaults.

    Any help or sense of direction would be greatly appreciated.

    Thank you.
    Brian D.

    Sunday, August 25, 2013 3:32 AM

All replies

  • Please post unedited ipconfig /all of DC and problem client.




    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Sunday, August 25, 2013 3:44 AM
  • Brian,

    DNS is very critical piece in AD environment. Issues in DNS means unstable AD environment.

    In your case, I would fire DNS queries via nslookup from few client machines. Check if DNS is resolving LDAP and Global Catalog service records. You have to change the query type to SRV.

    As you have only one DC, those records should resolve to DC's IP address.

    Please try and share the results.


    Viral Dalia System/Network Administrator MCSA, MCSE, MCDBA, CCNA

    Sunday, August 25, 2013 3:56 AM
  • Okay, I am aware of the importance that DNS has with LDAP/Active Directory.

    I've posted the NSLOOKUP command as you requested here.
    Sunday, August 25, 2013 4:45 AM
  • Here is the ipconfig /all dump from the DC

    Here is the IPConfig /all dump from the client (the Terminal Server since it's all we have access to at this moment)

    Sunday, August 25, 2013 4:48 AM
  • It seems like that this result is from DC. I would like to see something from client machine.

    Viral Dalia System/Network Administrator MCSA, MCSE, MCDBA, CCNA

    Sunday, August 25, 2013 5:00 AM
  • Hi,

    No, this is from the only client machine we have access to. Which is our terminal server since it's after hours and we're accessing remotely. We are not on site.

    This is not from the Domain Controller. And the TS is not configured as a secondary domain controller.
    If you'd like something from a workstation, we will need to go in at some point later after the weekend.
    Sunday, August 25, 2013 5:05 AM
  •   If you are expecting the network to look like your description and your network diagram, I am not surprised that it is not working. Your network diagram says that the servers are at and but the ipconfig shows that they are and with the gateway at . 

      I think that you are going to have to wait until you are onsite and look at exactly what is happening. If the workstations are using 10.0.1.x IP addresses they certainly won't be able to see the DC at ! Check on what exactly the DHCP server is offering its clients. It should be offering the IP address of your DC as the DNS address for you clients and it should be offering addresses in the same IP subnet as the DC and the TS server.


    Sunday, August 25, 2013 6:54 AM
  • My sincerest apologies for my error, today has been a really hectic day without too much straight thinking.
    Don't know where 10.0.1.x came from..... The sub-net is indeed 10.0.20.x

    Yes, the IP's are indeed as the IPCONFIG dumps show they are and as you document them to be.
    With a DC IP of:, a TS IP of:, and a Router IP of:

    I've re-posted an updated network diagram with the modifications.
    Sunday, August 25, 2013 7:29 AM
  • Couldn't tell from that but make sure that neither are multi-homed. Also check that forwarders are set correctly.




    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Sunday, August 25, 2013 2:46 PM