Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I seem to be experiencing a problem with a virtualized Windows 2008 domain controller. We are running Hyper-V on a powerful server (dual quad core Nehalem Xeon, 48 GB of ram), and all of the VMs are mostly idle. We only have a bunch of users for testing, and less than 6 machines joined to the domain.

What happens is that any type of access to another server seems to take for ever during initial logon negotiation. Symptoms:

  1. It takes around a minute to access something like \\someserver\c$. Afterwards, file transfers are fast, at 1 Gigabit sustained transfer speed, so it's not a network issue.
  2. If I open the Security tab to see which users have access to a folder, I can see the SIDs unresolved (S-1234-...) for a long time before they eventually get resolved.
  3. The following appears in the Event Log on some of the client computers:

Winlogon Warning 6005:

The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (Logon).

Winlogon Warning 6006:

The winlogon notification subscriber <GPClient> took 89 second(s) to handle the notification event (Logon).

The primary domain controller also has RRAS installed, and is a VPN server if that makes any difference. It's average cpu usage is 0% and there is no resource contention as far as I can tell.

There are two virtual NICs configured, one going to the public internet, and one on an internal LAN.

Any ideas on what I could try?

Solved:

Thanks to Farseeker and Zypher I resolved the problem. The primary domain controller had two NICs configured. One for internet, and one for the LAN.

The internet NIC had a public IP which was being registered in DNS for it (verified with nslookup from a guest computer). All the other computers that were experiencing the problem did NOT have access to the public IP subnet, so they couldn't hit the DNS' public IP. I assume they would wait for a timeout on the public IP before trying the private LAN IP which they could access.

Unchecking "Register this connection in DNS" on the public interface of the PDC fixed the problem, only the private IPs show up in nslookup now. Thanks Zypher.

Also had to do an ipconfig /flushdns on client computers after the change on the PDC.

share|improve this question
    
Does your VM DC have multiple NICs defined for it? –  Ryan Fisher Jun 12 '09 at 0:56
    
There are no "Primary Domain Controller" computers in Active Directory. All domain controller computers host fully writable copies of the Active Directory database. There is a computer in each domain that performs a role called "Primary Domain Controller Emulator", but that doesn't make its copy of Active Directory "special" or "primary". –  Evan Anderson Jan 28 '12 at 22:09
add comment

3 Answers

up vote 7 down vote accepted

I've seen similar symptoms, but in a 'real' environment, rather than a virtualised one. Our problem in the end was that the DNS was configured incorrectly, and the machines were doing some sort of crazy round-robin for ages before it would respond. It was a very long time ago, so I don't remember the exact resolution...

share|improve this answer
3  
Does sound like the problem. Check that DNS auto registration is off by going to the advanced tab of your NIC that you don't want showing up in your internal DNS then go to DNS and uncheck "Register this connection in DNS" is the most likely solution, I've had this happen to me a couple of times :) –  Zypher Jun 12 '09 at 1:37
    
Internal NIC DNS registration hit us as well. +1 –  Matt Rogish Jun 12 '09 at 2:54
    
Thanks guys, you steered me in the right direction! :) I have edited my answer to include the solution. –  legenden Jun 12 '09 at 12:02
add comment

It definitely sounds like a DNS issue, but we've never had any errors or performance problems related to auto registration like Zypher has.

share|improve this answer
add comment

In my experience, delays like that are more attributable to protocol mismatches than VM. Check the LanManager Authentication levels on the DC's and the server. It could be that the server is having to time-out a negotiation before it can connect or look up SIDs.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.