Today a client called me and said that his second domain controller, which is on Hyper-V, is having connectivity problems. For example, running the ping command from DC2 results in very bad response times or timed out requests.
Searching the event viewer, I saw many errors with Event ID 1054: “Description: Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted.”
Found a Knowledge Base article on Microsoft website that basically says this is happening if the computer has some AMD technology enabled in the BIOS. Well, my client only has computers with Intel Xeon processors, so this is not the case. Anyway, having experience with such articles vs. errors, I read the article till the end. This way I found similarities with my client’s environment: computers with more than one processors.
Basically, Dual Core or multiprocessor processors may encounter Time Stamp Counter (TSC) drift if certain conditions are met:
- number of processors
- operating system
- technologies enabled in the BIOS
- BIOS version.
This conditions can affect important operations like network communications and performance monitoring tasks that are sensitive to system time
Windows XP, 2000 and 2003 servers use the TSC as a timekeeping source. Each processor core (whether it is a single-core processor or dual-core processor) includes a TSC. When the TSC for different processor cores are not synchronized, the above symptoms and behaviors can occur if the operating system is using the TSC as a timekeeping source.
The KB article’s resolution is to install a newer CPU driver that modifies the boot.ini file by adding a switch in order to force the computer to use the PM_Timer instead of TSC. Also, it says that the boot.ini file can be manually modified.
So, to manually modify boot.ini file follow the following steps:
- Log on to the computer by using an account that has administrative credentials.
- Click Start, click Run, type notepad c:\boot.ini, and then click OK.
- In the Boot.ini file, a line that starts with “default” is located in the “[boot loader]” section. This line specifies the location of the default operating system. The line may appear as follows:multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=”Windows Server 2003 Enterprise x64 Edition” /fastdetect /NoExecute=OptIn
- At the end of the line, add a space, and then type /usepmtimer. The line should now resemble the following.multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=”Windows Server 2003 Enterprise x64 Edition” /fastdetect /NoExecute=OptIn /usepmtimer
- Save the file, and then exit Notepad.
- Restart the computer
This resolved the connectivity problem, however I wanted to test one more thing. As DC2 was a virtual machine with 2 cores assigned, I changed it to use only one processor and modified the boot.ini file to its original state. After restarting the VM and monitoring the server for bout 20 minutes, looks like the problem went away. So this can also be a workaround. I used the first method as client preferred this one.
These are the articles I read during troubleshooting and used now to write this post: