Month: January 2009

Error When Trying to Demote a Windows Server 2008 Domain Controller via the Command Line

If you’ve deployed a Windows Server 2008 core install running AD DS, you’ll be familiar with the promotion process. If you’ve ever demoted a Domain Controller from the command line, you may have come across an issue which makes your heart skip a beat (the last thing you want is for a Domain Controller promotion or demotion operation to fail, because you never know what you’re going to be left with). It’s actually a pretty easy “fix” which is handy to know before you try going crazy in adsiedit or anything like that.

The error can occur while the demotion process is attempting to stop the NETLOGON service, however the stop request times out, you get a message indicating that the operation has completed, but then an error on the next immediate line and your demotion stops.

Stopping service NETLOGON

……………………………………..
The attempted domain controller operation has completed
Failed to configure the service NETLOGON as requested

When I first did this, I figured that the dcpromo process would be aware of the last failure, and retry, which is sort of the case except you get the following error

The wizard cannot access the list of domains in the forest. The error is: the interface is unknown.

Another error which sounds particularly ominous, but it’s not. During the first demotion attempt, the demotion failed because either the NETLOGON service didn’t stop in time, or didn’t return the success code to the stop request, however by the time you run the second demotion the service has stopped. The demotion isn’t going to work with the NETLOGON service stopped.

The solution is as simple as just starting the NETLOGON service again by typing “net start netlogon” from the command, and then retrying your demotion. The dcpromo will pick up from where it was before, and nearly always complete successfully this time around.

Unrealistically Fast (or Negative) Ping Responses in Server 2003 Hyper-V Guests

I came across an interesting problem the other day while I was doing some unrelated troubleshooting on one of my Hyper-V guests.

The symptoms were that my Windows Server 2003 machine would return very strange results when pinging hosts, both internally and externally, such as returning all four responses within about half a second, yet measuring them at over 3000ms (which means they should have timed out, rather than given me a reading in milliseconds) as well as occasionally providing negative values for response times.

Obviously the results were completely inaccurate, but I couldn’t work out why the issue was only happening on a handful (not all) Hyper-V guests running Windows Server 2003 and none on Server 2008.

Turns out that this is an issue if all of the following are true:

  • You are running an operating system prior to Windows Vista or Windows Server 2008
  • You are running the current implementation of Microsoft Hyper-V (i.e. at the time of writing)
  • You have presented multiple processors to the Hyper-V guest

The issue occurs because the multiprocessor HAL in Hyper-V causes the guest’s operating system Time Stamp Counter (TSC) to skew. According to this blog the problem wouldn’t ordinarily occur if you were running Windows Server 2003 with SP2 unless the BIOS check fails to determine if the TSC should be used. More specifically, if I understand correctly the issue occurs because the processors (or cores, if we’re talking about a single multicore processor) are not in sync with each other, which produces sporadic out-of-time results where time sensitive operations (such as ping responses) are in use.

The resolution is to force the guest to use the PM timer instead of the TSC, by adding /USEPMTIMER in the boot.ini file and then restart. You can easily test this by running a ping -t to a host and checking for drastically abnormal results.