MAP DIAGRAM UPDATED
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.
# 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 10.0.20.4.
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 10.0.20.4. 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.
- Edited by GamelordGames Sunday, August 25, 2013 7:29 AM
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
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.
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 10.0.1.1 and 10.0.1.2 but the ipconfig shows that they are 10.0.20.4 and 10.0.20.5 with the gateway at 10.0.20.3 .
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 10.0.20.4 ! 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.
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: 10.0.20.4, a TS IP of: 10.0.20.5, and a Router IP of: 10.0.20.3
I've re-posted an updated network diagram with the modifications.
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.