Jump to content

Big Problems with Clients contacting DCs


Recommended Posts

Posted (edited)

Having rather large problems across the whole school, any advice would be really helpful here:

 

Background

 

Our old network included 4 Server2000 DC's and some other member servers. We have moved over to a completely new network with xenserver running on three physical servers connected to a SAN.

 

We updated the schema, dcpromo'd a 2008 r2 VM, moved over FSMO roles, and then demoted the 4 old 2000 boxes to member servers.

 

We then added another r2 DC so we are now left with DC1 with all FSMO roles, DNS and DHCP, and DC2with DNS. Both are GCs.

 

Problems

 

Now connecting clients to the domain has been a nightmare. Lots of "No (DOMAIN) Available" messages on logon.

 

Some PCs are showing in the event log the following events:

 

Event 1054

 

Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or could not be contacted. ). Group Policy processing aborted.

 

Event 4356

 

The COM+ Event System failed to create an instance of the subscriber partition:{41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}!new:{6295DF2D-35EE-11D1-8707-00C04FD93327}. CoGetObject returned HRESULT 8000401A.

 

Logon times are nowhere near acceptable at the moment, clients can sometimes take 45 seconds or longer to logon, other times they'll logon as expected within 15-25 seconds.

 

Things I've checked

 

I have run DCDIAG on the first DC and all tests have passed with exception to its ability to read Event logs (due to not creating hole in firewall).

 

Checked DNS entries in both DNS servers and they both appear to be replicating properly. All SRV records for the DC's appear to also be correct.

 

When I gpresult a machine after logging in, unless I have previously forced a gpupdate, it will show one of the old DC's as its source for applying policy which is odd. If I do run a gpupdate, then it connects to one of the new DC's and pulls the correct policies.

 

Also, on the clients i have logged into local administrator, flushed the dns cache, and can succesfully resolve DC1, and DC2s names still through nslookup.

 

It appears that pulling the machines completely from the domain and rejoining them seems to help but we are still experiencing massively increased logon times.

Even after being completely removed from the domain and re-added, clients are still sticking at 'Applying User Settings' for a good 30-45seconds occasionally more...

 

If anyone is able to shed any light to why this might be happening, and what to check Id be most appreciative!

Edited by Crispin
Posted
Sounds like it's still trying to connect to the old servers first, and getting bumped up the list until it finally reaches a DC -- timeouts on the old servers are increasing your login times as it's searching the for DC?
Posted (edited)
Did you rebuild your pc's (ie format / re-image) as clients for the new domain, or just disjoin & re-join?

 

It's not a new domain, therefore it shouldn't require rejoining to the domain. Although new images would have been nice, the stability of the network would have meant WDS would not have been viable.

 

Double check sites and services make sure the old servers have gone

 

Checked that. They're definitely gone!

 

Check your DHCP is issuing the IPs of your new DNS servers, you do not mention swapping IPs of old servers to the new...

 

Yeh thats configured properly.

 

 

Turns out I made some progress on this;

 

It appears there were a couple of problems. First off. The second DC had 127.0.0.1 as its Primary DNS and 10.0.9.2 as its Secondary. That was obviously wrong, but what we stupidly didn't notice is that ipv6 was turned on, and it was looping back to that address. :doh:

 

Also, after correctly configuring the second DC we ran /flushdns /registerdns and then DCDIAG /fix. No errors returned still.

 

Secondly, WINS. We've installed WINS on our Pri DC to make sure that wasn't the problem.

 

Lastly, the few remaining local profiles that were left on the clients after delprofing them during summer were caching some of the old server information which was causing problems. Deleting the local profiles cleared up a lot of the problems relating to those users. ie. the 'supervisor' profile that was left on the machines as we used it as logon for delprofing.

 

Roaming appdata has caused a few problems as well with applications looking for the old servers.

 

Hopefully, the worst is over.

 

Now...onto ConfigMgr 2007. The fun begins!

Edited by Crispin

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...