System Management

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 where 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 carefully today and used now to write this post:

• Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP: http://support.microsoft.com/kb/895980
• Explanation for the USEPMTIMER switch in the boot.ini: http://blogs.technet.com/perfguru/archive/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-boot-ini.aspx

Usually, extending the Active Directory schema is the last step I do when installing SCCM. This time, while installing SCCM in a virtual machine, you have to provide a path to a folder with SCCM updates or download these updates from the internet. Working in a virtual machine with a “Local only” network adapter, I couldn’t download those updates; so I switch the network adapter to an external one. After downloading the updates, next step is “Installation Prerequisite Check” and at this step I extend the AD schema.

Well, the following error was written in ExtADSch.log file:
Unable to connect to RootDSE - Cannot update Active Directory. Error code = 1355.
Failed to extend the Active Directory Schema.

Error 1355 is: ERROR_NO_SUCH_DOMAIN. That means that the specified domain could not be contacted or does not exist. The problem here is that I did not switched back to “Local only” network adapter and so the Active Directory could not be contacted. Setting the adapter to “Local only”, I could contact the Domain Controller and extending the schema was successful.

Yesterday I started to play with Hyper-V and SCVMM 2008. I added two hosts and also imported one virtual hard disk (with Windows Server 2003 SP2) to see if a .vhd created by Virtual Server 2005 SP1 works well in Hyper-V.

I noticed that I do not have an internet connection, actually there wasn’t any network adapters installed although I’m sure I had one. I installed Integration Services and it installed Microsoft Virtual Machine Bus Network Adapter. Ok, good. Looks like it doesn’t have the IP address set up. When I tried to configure the adapter, the following error occurred: “The IP address <ip address> you have entered for this network adapter is already assigned to another adapter…”

As I did not have any network adapter prior to installing Integration Services, I opened Device Manager and checked Show hidden devices from the View menu. The result: no Intel 21140-Based… adapter there. Nothing wrong here, this is by design. Installed devices that are not connected to the computer (i.e. USB device) are not displayed in Device Manager, even with Show hidden devices enabled.

So, in order to uninstall the old network adapter (Intel 21140-Based… in my case) do the following:

1. Click Start, point to All Programs, point to Accessories, and then click Command Prompt.
2. At a command prompt, type the following command , and then press ENTER:
   • set devmgr_show_nonpresent_devices=1
3. Type the following command a command prompt, and then press ENTER:
   • start devmgmt.msc
4. Troubleshoot the devices and drivers in Device Manager.NOTE: Click Show hidden devices on the View menu in Device Manager before you can see devices that are not connected to the computer.
5. When you finish troubleshooting, close Device Manager.
6. Type exit at the command prompt.Note that when you close the command prompt window, Window clears the devmgr_show_nonpresent_devices=1 variable that you set in step 2 and prevents ghosted devices from being displayed when you click Show hidden devices.

There is a KB article about this. Although the article applies to Windows XP only, the solution worked very well on Windows Server 2003.