Month: December 2009

How to create a Windows Image (.wim) file

~ Vitalie Ciobanu ~ 4 Comments

Depending on what you need the .wim file for, you can create it manually or automatically.

– To manually create a .wim file (capture image) you need a bootable CD with Windows PE (with ImageX.exe included) that you can create using Windows Automated Installation Kit.

The basics steps are:

  1. Boot your computer using Windows PE disk.
  2. In the Windows PE command prompt navigate to the folder with ImageX.
  3. To capture the C: partition, use the following example:
    imagex.exe /capture C: D:\CapturedImage.wim “My captured image”Where: C: is the partition to be captured; D:\CapturedImage.wim is the place of the captured file; “My captured image” is the name of the file.
    More switches can be found on the ImageX Command-Line Options page.

If you need the image for deployment, do not forget to run sysprep before capturing the image!

– To automatically create a .wim file you can use a capture media created using Configuration Manager.

If you want to capture a Windows XP OS, copy sysprep files to C:\sysprep. Newer operating systems have sysprep files installed by default.

To use capture media:

  1. Insert the CD into your CD/DVD drive and shortly autoplay will open Image Capture Wizard.
  2. Clicking Next will show you Image Destination page. Select where to save the wim file.
  3. On the next page enter some information about the image.
  4. On the Summary page click Finish. The task sequence will start sysprep and restart the computer. After restart, the computer will boot to Windows PE and will capture a image of the machine.

Windows cannot obtain the domain controller name error

~ Vitalie Ciobanu

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: