Home > Hyper-V, Hyper-V R2, Infrastructure > Hyper-V Domain Controller Negative Ping Results

Hyper-V Domain Controller Negative Ping Results

This one was a little bit new for me, About 6 months ago one of my customers told me that some times his new virtual Domain Controller is giving a negative ping results.

Negative Ping

This DC was working fine and it was new installation Windows server 2003 Domain Controller. Every 5 minutes it reports an event 1054 saying that it cannot find the domain controller name.

Event ID: 1054
Source: Userenv
Type: Error
Description:
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.

everything was fine and SRV and DNS records are created fine, Clients can logon and access the server with no problem and the group policy is being applied correctly.

As per Microsoft KB This behavior may occur if the address for the configured preferred DNS server on the client is invalid or unreachable. but everything from the client side is fine as expected.

That is odd. I was sure that no problem with the system at all. After some time searching for that I start to suspect the hardware or the network and Bingoooo I was right

Problem now resolved via a HP support article below

SUPPORT COMMUNICAT

ION – CUSTOMER ADVISORYDocument ID: c01075682Version: 2
Advisory: (Revision) HP ProLiant Servers Using Dual-Core or More Than One Single-Core AMD Opteron Processor May Experience Incorrect Operating System Time When Running Systems That Use the System Time Stamp Counter
NOTICE: The information in this document, including products and software versions, is current as of the Release Date. This document is subject to change without notice.

Release Date: 2007-07-16

Last Updated: 2007-07-16

HP ProLiant servers configured with Dual-Core or with more than one single-core AMD Opteron processor may encounter Time Stamp Counter (TSC) drift in certain conditions. The TSC is used by some operating systems as a timekeeping source. Each processor core, whether it is a single-core processor or a dual-core processor, includes a TSC. The condition where the TSC for different processor cores becomes unsynchronized is known as TSC drift.

Note : The potential for TSC drift if the proper recommendations are not applied when using AMD Opteron 200-series, Opteron 800-series, Opteron 1200-series, Opteron 2200-series and Opteron 8200-series processors is not specific to HP ProLiant servers.

Whether or not the system is affected by TSC drift depends on the specific ProLiant server generation, the number and type of AMD Opteron processors installed, the operating system, and whether the AMD PowerNow! feature is being utilized. TSC drift can result in different symptoms and behaviors based on the operating system environment, as detailed below:

Microsoft Windows Server 2003
This condition affects operations such as network communications and performance monitoring tasks that are sensitive to system time. For example, Microsoft Active Directory domain controllers can report an Unexpected Network Error (Event ID 1054) with the following description:

Event Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred.). Group Policy processing aborted.

In addition, a negative PING time or larger than actual PING time may be returned after issuing the PING command. The negative PING time occurs because of a Time Stamp Counter drift occurring on AMD Opteron platforms which include more than one processor core.

SCOPE

Any HP ProLiant server configured with more than one single-core AMD Opteron processor or configured with one (or more) dual-core AMD Opteron processors running the following operating systems:

Microsoft Windows Server 2003 (any edition)
Microsoft Windows Server 2003 x64 Edition (any edition)
Red Hat Enterprise Linux 4(x86) or earlier
Red Hat Enterprise Linux 4 (AMD64/EM64T) or earlier
SUSE Linux Enterprise Server 9 32-bit (x86) or earlier

Note : The issue does not affect systems with only one single-core processor installed.

The following servers are affected when running an affected operating system:

HP ProLiant BL465c Blade Server
HP ProLiant BL685c Blade Server
HP ProLiant BL25p G2 server
HP ProLiant BL45p G2 server
HP ProLiant DL145 G3 server
HP ProLiant DL385 G2 server
HP ProLiant DL585 G2 server
HP ProLiant DL365 server
HP ProLiant ML115 server

The following servers are affected ONLY when using the AMD PowerNow! feature and running an affected operating system:

ProLiant BL25p Blade Server
HP ProLiant BL45p Blade Server
HP ProLiant DL145 G2 server
HP ProLiant DL385 server
HP ProLiant DL585 server

The following operating systems are not affected by TSC drift because these operating systems do not use the TSC as a timekeeping source:

Microsoft Windows Server 2008 (codename Longhorn)
Red Hat Enterprise Linux 5 (x86)
Red Hat Enterprise Linux 5 (AMD64/EM64T)
SUSE Linux Enterprise Server 10 (x86)
SUSE Linux Enterprise Server 10 (AMD64/EM64T)
VMware ESX Server 3.0.0 (or later)

RESOLUTION

To ensure proper operation of tasks sensitive to system time, perform either of the following actions, based on the operating system environment:

Microsoft Windows Server 2003 (any edition)
Edit the BOOT.ini file and add the parameter “/usepmtimer,” then reboot the server. Adding the “/usepmtimer” parameter to the BOOT.INI file configures the Windows operating system to use the PM_TIMER, rather than the Time Stamp Counter.

So the final solution was that

To resolve this problem, install the new AMD CPU driver. To do this, visit the following AMD Web site:

After you install the new driver, you must restart your computer.

Note The driver installation adds the /usepmtimer switch in the Boot.ini file. This switch is discussed in the above section.

Advertisements
  1. October 28, 2009 at 9:23 pm

    This can also happen to a multi-processor VM that live on an AMD hosts. Using the /usepmtimer flag in the boot.ini will fix this in the VM. There is a similar occurance for Intel based hosts with multi-processor VMs that will present very high ping times, that respond very quickly. In this case too, using the /usepmtimer flag corrects this issue.

    Rob

  2. Mohamed Fawzi
    October 28, 2009 at 10:35 pm

    Exactly… Thanks Rob for this valuable info

  3. November 8, 2009 at 4:06 pm

    Nice Post, btw do you know any good usenet archives and or mailing list archives site for unix / linux / bsd

  4. October 27, 2010 at 1:17 pm

    my blade serve cant not ping
    my odit ping not working fine

  5. Mohamed Fawzi
    October 27, 2010 at 1:42 pm

    Hi Abdoul, Can you please clarify more ?

  1. October 29, 2009 at 12:59 am
  2. October 29, 2009 at 2:31 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: