Ask the Core Team : Deployment

MDT 2010: Incorrect wimgapi.dll version causing WIM mounting issues

jeffhugh — Thu, 19 Nov 2009 13:18:03 GMT

Today’s blog will cover an issue we have seen with Microsoft Deployment Toolkit 2010. You may see one or more of the following error messages when generating or updating boot images and other actions in MDT that involve the Lite Touch Images:

Unable to mount the WIM, so the update process cannot continue.
Unable to load DLL 'wimgapi.dll'
Mount did not succeed

You can also run into errors when Windows System Image Manager tries to catalog an image. This issue can occur because we are finding an incorrect version of WIMGAPI.DLL first in the path

Steps to Resolve

At a command run the following command

Where wimgapi.dll

For the first location listed in the page verify that the .DLL Version is correct. If MDT 2010 is installed on Windows 7 or Windows Server 2008 R2 you should see wimgapi.dll in two locations because it ships with the operating system and with the Windows Automated Installation Kit (WAIK).

C:\windows\system32\wimgapi.dll
C:\program files\windows imaging\wimgapi.dll

Both versions should be 6.1.7600.16385. The version could be later than this if any updates have shipped that replace this file at a later date

Notes:

This issue can occur if you installed a beta version of the WAIK or System Center Configuration Manager (SCCM)
You may find other versions in locations like Program Files(X86) or other directories.
If MDT is installed on Windows XP or Windows Server 2003 wimgapi.dll should only be found in C:\Program Files\Windows Imaging
The version of WIMGAPI.DLL may be updated in later releases of the Windows AIK or updates to Windows.

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

KMS Host Client Count not Increasing Due to Duplicate CMID'S

jeffhugh — Fri, 16 Oct 2009 11:32:19 GMT

Hello, my name is Scott McArthur. I am a Senior Support Escalation Engineer in the Windows group and today’s blog will cover an issue involving KMS activation and deployment of images. This issue seems to be more prevalent today due to the various tools used to clone images, create images based on a templates, Physical to Physical (P2V) tools, etc...

Generally the symptom you will see is that the count on your KMS host will not show the correct number of clients or it will not increase. There are a number of reasons why this can occur but a common reason is that sysprep was not used when preparing images for deployment.

Any time you use imaging as your deployment method it is required that you run sysprep to prepare the image for deployment.

This policy is outlined in the following KB article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;162001

To determine if you are encountering this you can use the Key Management Service Log do the following:

1. On your KMS host open Event Viewer
2. Right click the Key Management Service Log and choose “Save all events as”
3. Change the Save as type to Text(Tab Delimited)(*.txt)
4. Save the file as KMS.TXT
5. Close out of the Event Viewer completely
6. Open Excel
7. Click File, Open, and browse to KMS.TXT
8. You should see the Text Import Wizard. Choose the following options
    Delimited
    Start Import at Row: 8
    Delimiters: Comma
9. When complete the data may look all messed up. Don’t worry we will correct that
10. Click the upper left of the spreadsheet to select the entire spreadsheet
11. Click Data, Sort, In the Sort By selection choose “Column D”
12. When complete you should see the data sorted in columns.

The Client Machine ID (CMID) is how we uniquely identify a KMS client. When sysprep is run one of its jobs is to generalize this GUID so when the image is deployed every machine has a unique CMID. Here is an example output

Column C-Computername

Column D-CMID

TEST-03.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

TEST-04.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

TEST-02.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

TEST-01.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

From this output you can see that multiple computernames have the same CMID. Each computer should have a unique CMID. This means that sysprep /generalize was not used to prepare these computers for deployment. So to KMS those 4 machines appear as one. That what be why the count would not be increasing or not reflect the true number of machines deployed.

While it is possible to run slmgr.vbs /rearm to reset the machines CMID that does not leave the machine in a supported state. Images deployed without using Sysprep to prepare the image are not supported by Microsoft. Sysprep executes ~30 sysprep providers. These providers are written to correct issues with various components when you duplicate the installation. By not running sysprep it is unknown what types of issues you could encounter and many components will be in a broken state. The supported solution is to rebuild the image using the Sysprep /generalize switch and redeploy the systems.

Thanks for your time. Stay tuned to our blog for more Activation and Deployment Topics.

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

How to run a Sysprep and Capture Task Sequence From MDT 2010

jeffhugh — Tue, 06 Oct 2009 17:18:13 GMT

Hello, my name is Kevin Ledman. I am a Support Escalation Engineer in the Windows group and today’s blog will cover how to run the new Sysprep and Capture Task Sequence included with MDT 2010.

If you choose to deploy an operating system manually or need to make customizations outside of the MDT task sequencer, you can still use MDT to automatically sysprep and capture the image for future use.

To configure the task sequence, launch the MDT 2010 deployment workbench and create a new task sequence using the sysprep and capture template. Answer the remaining wizard items, making sure to choose an OS source that matches the OS you are going to be capturing.

Update your deployment points and switch to the reference computer to start the task sequence. **A common mistake at this point is to boot the reference computer from your LiteTouch image and start this task sequence. The sysprep and capture task sequence is designed to be run from the desktop of the reference machine similar to a post OS installation task sequence. To launch this, you will need to establish connectivity to the deployment share and launch LiteTouch.WSF manually. Because you are logged in to the reference machine as a local administrator and not joined to a workgroup, be sure to establish the session under the same security context that will be used for the task sequence:

net use * \\mdtserver\DeploymentShare$ /user:domain\username

Once the connection is established, execute LiteTouch.WSF:

cscript \\mdtserver\DeploymentShare$\Scripts\LiteTouch.WSF

The MDT Wizard Screens will launch and prompt for the information required to complete this task sequence. **Note – we will still process customsettings.ini for this task sequence. If you have modified customsettings.ini to skip wizard screens, those settings will be honored with this task sequence as well.

Choose the task sequence you have created.

Choose the capture option and supply the location and file name.

Supply the credentials that LiteTouch will use to connect to the deployment share.

View the summary and click ‘Begin’ to start the task sequence. If you receive error “A connection to the distribution share could not be made” see the following blog:

http://blogs.technet.com/msdeployment/archive/2009/09/18/fix-for-multiple-connections-to-a-server-or-shared-resource-by-the-same-user-using-more-than-one-user-name-are-not-allowed-problem-with-mdt-2010.aspx

MDT will copy the necessary files to the reference computer, launch sysprep, apply the LiteTouch Image and reboot the machine

LiteTouch boots and begins the capture of the image. Depending on the size of the installation, this may take a significant amount of time.

Once the capture has completed, you can now import the captured image as a custom image file in MDT and use it for future task sequences.

Add new operating system and choose custom image file.

Point to the “Captures” path and move it to the to the deployment share.

Include the setup files for the OS which you are importing and complete the wizards.

The operating system is now ready for use with new task sequences.

Kevin Ledman
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Invalid Product Key Error Specifying MAK key in unattend.xml

jeffhugh — Mon, 05 Oct 2009 18:31:32 GMT

Hello, my name is Scott McArthur. I am a Senior Support Escalation Engineer in the Windows group and today’s blog will cover an issue involving specifying MAK Product Keys during setup of Windows 7 and Windows Server 2008 R2.

When deploying a Volume License (VL) version of Windows 7 or Windows Server 2008 R2 you may encounter the following error message:

The unattend answer file contains an invalid product key. Either remove the invalid key or provide a valid product key in the unattend answer file to proceed with Windows Installation

The setuperr.log will log the following

2009-10-01 12:52:38, Error      [0x060551] IBS    Callback_Productkey_Validate: EditionID for product key was NULL.
2009-10-01 12:52:38, Error      [0x060554] IBS    Callback_Productkey_Validate: An error occurred writing the product key data to the blackboard.
2009-10-01 12:52:38, Error      [0x06011a] IBS    Callback_Productkey_Validate_Unattend:Product key did not successfully validate.[gle=0x00000490]
2009-10-01 12:52:38, Error      [0x0603c7] IBS    Callback_Productkey_Validate_Unattend:Did not pass validation; halting Setup.[gle=0x00000490]
2009-10-01 12:52:38, Error      [0x060120] IBS    Callback_Productkey_Validate_Unattend: An error occurred preventing setup from being able to validate the product key; hr = 0x80300006[gle=0x00000490]

This error can occur if you have specified a Multiple Activation Key (MAK) in your answer file in the WindowsPE phase of setup. VL versions do not prompt for a ProductKey so they do not need a ProductKey during the WindowsPE phase of setup. The ProductKey can be specified by clicking “Change Product Key”, SLMGR.VBS /IPK, or specifying it in the answer file.

The ProductKey entry is found in 2 places in Windows System Manager:

Microsoft-Windows-Setup in WindowsPe phase

The above entry would be used when using retail media.

Microsoft-Windows-Shell-Setup in Specialize phase

To resolve this issue use the Microsoft-Windows-Shell-Setup component in the Specialize phase. In order to get the ProductKey entry you must right click the Microsoft-Windows-Shell-Setup component under Windows Image and add it to the Specialize phase.

ProductKey will not show up under the component(On the Answer File pane) until you actually add it. The unattend.xml will look like this

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <ProductKey>xxxxx-xxxxx-xxxxx-xxxxx-xxxxx</ProductKey>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="catalog://server/catalogs/win7/enterprise/x86/install_windows 7 enterprise.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

Note: If you are using Microsoft Deployment Toolkit 2010 for your deployments you can enter the MAK key during the ProductKey prompt during the Lite Touch Wizard. Hope this helps with your deployments and keep an eye on our blog for other activation issues.

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Adding New Timezones to Windows XP/Windows Server 2003 Sysprep.inf deployments

jeffhugh — Mon, 13 Jul 2009 14:32:45 GMT

Hello, my name is Scott McArthur. I am a Senior Support Escalation Engineer in the Windows group and today’s blog will cover specifying new and updated timezones in sysprep.inf for Windows XP and Windows Server 2003.

When deploying Windows XP or Windows Server 2003 with a sysprep image you must specify the timezone entry. For example

[GuiUnattended]

Timezone=035

The deploy.chm that ships in the deploy.cab has a listing of timezones but there have been changes since those helpfiles were created. For example there is a new time zone called “Morocco Standard Time”. To determine the entry to add do the following

1. Install Windows XP/Windows Server 2003 and install all updates including the latest Daylight Savings Time (DST) update. See http://support.microsoft.com/gp/cp_dst for more information

2. Open regedit.exe

3. Browse to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones\

4. Choose the timezone you are looking for

5. Under the timezone click the Index registry key and note the decimal number in parenthesis

6. In your sysprep.inf add the following

[GuiUnattended]

Timezone=-2147483725

Note: The minus in front of the number needs to be included

If you have the hex value for Index you can also convert it using calc.exe using the following steps

1. Open calc.exe

2. Click Hex

3. Input the hex value. For example 0x8000004d

4. Click Dec

5. You will get the decimal value, 2147483725

Using this process you can add any new timezones to your sysprep.inf. Note that Windows Vista and later uses a different syntax for timezones so this issue only applies to Windows XP and Windows Server 2003

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Error Message: Windows cannot access the required file d:\sources\install.wim when replacing install.wim with custom install.wim

jeffhugh — Mon, 13 Apr 2009 17:08:33 GMT

My name is Scott McArthur, a Senior Support Escalation Engineer who focuses on deployment issues. My topic for today’s blog entry involves an issue where a customer was deploying Windows Server 2008 by replacing the default install.wim on the Windows Server 2008 media with a custom install.wim.

When booting up the DVD they encountered the following error

Windows cannot access the required file d:\sources\install.wim. Make sure all files that are required for installation are available, and restart the installation.

The x:\windows\panther\setuperr.log contained the following:

SetWindowsImageInfoOnBB:Failed while updating EditionID for volume PID.[gle=0x00000057]

CallBack_SetImageInfoOnBB:Failed to read and cache the Windows image's metadata; GLE is [0x0]

CallBack_SetImageInfoOnBB:An error occurred while trying to read and cache the images' metadata;

This error can occur if default install.wim located in the sources folder is replaced with a custom install.wim but the image was not captured by using the /flags switch.

When you deploy a custom install.wim with Image Based Setup (IBS) it must know the edition of the image.

You can verify this by running the imagex /info command with the install.wim. For example

imagex /info d:\sources\install.wim

The image metadata must contain an entry similar to this. If you do not see the following metadata entry then you know it was not captured by using /flags

<FLAGS>SERVERENTERPRISE</FLAGS>

When capturing the image you must use the following syntax

Imagex /capture c: z:\data.wim "drive c" /flags "EditionId"

Where EditionID is:

HomeBasic, HomePremium, Starter, Ultimate, Business, Enterprise, ServerDatacenter, ServerEnterprise,

ServerStandard

To fix this without re-capturing the image do the following on computer that has the WAIK installed

1. Click Start, All Programs, Microsoft Windows AIK, and select “Windows PE Tools Command Prompt”

2. Copy whole contents of DVD to c:\flat

3. Run the following command to add the EditionID to the metadata

Imagex /info c:\flat\sources\install.wim 1 "image-name" "description" /flags "EditionID"

4. Run the following command to recapture the ISO

oscdimg.exe -betfsboot.com -n -h -m c:\flat c:\2008.iso

Note if you use Microsoft Deployment Toolkit to create and capture your images it automatically adds the /flags switch. Microsoft Deployment Toolkit is the preferred tool to use for deploying Windows.

Additional information on the /flags switch can be found in the Windows AIK help files. Specifically the WAIK.CHM in the imagex command line options.

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Installing A VM Operating System Using a Legacy Network Adapter and PXE-boot

jeffhugh — Tue, 25 Nov 2008 20:53:26 GMT

Virtual machines can be deployed to Hyper-V using Windows Deployment Services (WDS). To accomplish this requires the proper WDS infrastructure be in place and that the VM PXE boot using a Legacy Network Adapter. Windows Deployment Services can run on Windows Server 2003 or be installed as a Role in Windows Server 2008. It is not the purpose of this blog to detail setting up WDS but to document the process for entering information in Active Directory when using Pre-staged Computer Objects.

Windows Deployment Services can be configured to respond to all clients or only to known clients. Virtual machines configured for PXE boot using a Legacy Network Adapters will respond correctly when a WDS server is configured to respond to all clients. However, when the WDS server is configured to respond to only known clients, the Hyper-V server may not obtain a DHCP assigned IP address and be presented with a boot menu option. When a WDS server is configured to respond to only known clients, the VM computer account must be pre-staged in Active Directory. Part of configuring this Computer Account requires using a unique ID to identify the computer. There are two methods that can be used:

MAC address
Globally Unique ID (GUID)

To obtain this information from a VM, configure the VM to use a Legacy Network Adapter and then in the VM settings change the boot order such that the Legacy Network Adapter is listed first. Start the VM and then 'Pause' it to obtain the above pieces of information as shown here:

In the above screenshot, we see both the VM MAC address (assigned from the Hyper-V pool of MAC addresses) and its GUID.

The Information is entered in the Remote Install tab for the Properties of the pre-staged Computer Object in Active Directory as shown here:

In the screenshot above, I used the MAC address obtained by booting the VM. The MAC address must be preceded by twenty (20) zeroes to be considered valid. If the choice is to use the GUID, the first 16 bits must be reversed when entering the information in the Remote Install tab. For example, the GUID displayed when booting the VM was - E767FFB0-82D2-4AE5-9A88-ABBB6322BC5E. When entering it in the Remote Install tab you would have to enter - B0FF67E7D282E54A9A88ABBB6322BC5E. The highlighted portion has been reversed (first 16 entries). After selecting Apply, the first 16 bits will be reversed and the entry will appear as it did during the PXE boot. There is a KB article that explains the reason why the entry may appear differently:

KB228905 - GUID of Pre-Staged Computer Appears Different Than as Typed.

With the information entered for the pre-staged Computer Object, the VM should boot correctly and you will be presented with a menu selection (depending on how many images were added to the WDS server) for completing the installation.

I hope you found this Hyper-V tidbit informative should you decide to use WDS to deploy VMs in Hyper-V. As always, we would appreciate your feedback.

Chuck Timon
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Automating the OOBE process during Windows Server 2008 Sysprep Mini-Setup

tomac — Fri, 31 Oct 2008 18:09:14 GMT

One of the more common questions we have with Windows Server 2008 deployment revolves around the basic components needed in our answer file to automate the OOBE process during Sysprep mini-setup.

Let’s start out with a few basic facts.

· Sysprep is no longer in the deploy.cab on the operating system CD. Instead, it’s installed by default to %systemroot%\system32\sysprep.

· The options for Sysprep have changed from those available in legacy operating systems such as Windows Server 2003 and Windows XP.

· The common switches you will need to use are OOBE, Generalize, and Shutdown. Generalize is a required switch for the majority of scenarios.

· All answer files for Windows Server 2008 and Windows Vista are created with Windows System Image Manager. Windows System Image Manager is installed as part of the Windows Automated Installation Kit. This can be downloaded from the Microsoft Download Center at the following location:

http://www.microsoft.com/downloads/details.aspx?FamilyID=94bb6e34-d890-4932-81a5-5b50c657de08&DisplayLang=en

When first opening Windows System Image Manager, you must first select a Windows image or catalog file. Contrary to popular belief, one does not have to generate a catalog for the install.wim. A quicker practice is to use the catalog files included on the Windows Server 2008 DVD in the Sources directory. Unlike the install.wim, these files do not need to be copied locally and if you do wish to have them local, they’re a much smaller footprint.

Make sure you change the file type dropdown to Catalog files(*.clg) when browsing to see this files.

For this blog topic, I have selected to use the SERVERENTERPRISE catalog to create my answer file. After you have selected your catalog (or generated a catalog using the install.wim) and selected the option to create a new answer file, Windows System Image Manager should look similar to the following:

Now let’s get down to the four basic components you need to add to automate the OOBE process during Sysprep mini-setup. For this basic Sysprep deployment, please note that we will only be configuring the Specialize and oobeSystem configuration passes.

The first page we need to automate during OOBE is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your answer file, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region.

REMEMBER: Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.

Secondly, we need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem . Under Settings, select the drop down next to HideEULAPage and select true.

The third page we need to automate is the Product Key Selection page and the Computer Name Selection page.

If you are working with volume license media you can either leave the product key blank if you are using KMS host for activation or you can enter your MAK key. If you are using MAK key for activation you can also just enter the MAK key on the machine prior to running sysprep to create your image. That way the product key is not in your answer file. The key is removed automatically but during setup it is possible to see the key in the answer file.

Please make sure to note that you must have a KMS Server setup in your environment in order for your KMS clients to activate. For Windows Server 2008, you have 60 day grace period to get KMS configured and to the appropriate count. For more information on Volume Activation, I highly recommend reading the documentation available on Microsoft TechNet on the following website:

http://technet.microsoft.com/en-us/library/bb892849.aspx

To automate the Product Key Selection page, right-click on the Microsoft-Windows-Shell-Setup component and add the settings to the Pass 4 specialize configuration pass of your answer file. Under Settings, enter your Product Key in the space provided next to ProductKey. Furthermore, to automate the Computer Name Selection page, under Settings, specify a computer name next to ComputerName.

If no computername is entered you will be prompted for the computername on bootup of the image Also, you may notice the TimeZone. However, do not configure it here. We do not prompt for Time Zone on Windows Server 2008. If you wish to configure it, configure it on the top level of the Microsoft-Windows-Shell-Setup component we added to the 7 oobeSystem configuration pass of your answer file.

The forth and last page we need to automate is the Change Administrator Password page. Windows Server 2008 automatically prompts for you to specify the Administrator password prior to first logon. To automate this, expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.

Click on File and Save Answer File. You can save the file as unattend.xml in the c:\windows\system32\sysprep folder and sysprep will automatically use the answer file or you can specify /unattend switch if you are running it from the command line to point to the path and name of the file.

During the saving process, Validation is run in Windows System Image Manager. Do not be concerned by any of the following sorts of Validation messages as it is simply stating that any of the settings we did not modify will not be saved to our answer file. These will automatically be removed:

You are now DONE! Obviously there are many, MANY more settings you can configure. The customizable settings are extensive. However, these four settings are the only ones that need to be added to your sysprep answer file in order to avoid any prompts during Sysprep Mini-Setup.

Author: Charity Shelbourne
Microsoft Enterprise Platforms Core Support
Sr. Support Escalation Engineer
Deployment Subject Matter Expert

Technorati Tags: Windows Vista,Windows 2008,Windows System Image Manager,WSIM,OOBE,Generalize,sysprep

KMS 1.1 For Windows Server 2003 Installation Issues

jeffhugh — Thu, 07 Aug 2008 17:26:31 GMT

KMS 1.1 For Windows Server 2003 Installation Issues

Hello my name is Scott McArthur and I am a support escalation engineer in the Windows Platforms group and specialize in activation issues. We have had a number of support calls around issues with KMS 1.1 for Windows Server 2003. There are two different versions of KMS for Windows Server 2003.

KMS for Windows Server 2003 1.0 only works with Vista RTM KMS host keys.
KMS for Windows Server 2003 1.1 works with both Vista RTM KMS, Vista SP1, and 2008 KMS keys

One of the symptoms is that when you install the KMS host key on your KMS host

slmgr.vbs -ipk <kms host key>

You receive a error such as 0xC004F050. This error equates to "The Software Licensing Service reported that the product key is invalid."

Turns out that there is some confusion to how to install KMS 1.1 although the documentation is very clear on the steps:)

When you download the KMS 1.1 update, KMSW2K3_EN-US_x86.zip

http://www.microsoft.com/downloads/details.aspx?FamilyId=81D1CB89-13BD-4250-B624-2F8C57A1AE7B&displaylang=en

You get the following files

Key Management Service v1 1 for Windows Server 2003 Step-By-Step Guide.doc
KMSW2K3.exe
WindowsServer2003-KB948003-x86-ENU.exe

You must install the KMS 1.0 version(KMSW2K3.exe) first then install the update for 1.1(WindowsServer2003-KB948003-x86-ENU.exe). Some customers have only installed the KMS 1.0 version(KMSW2K3.exe) and not WindowsServer2003-KB948003-x86-ENU.exe which updates it to KMS 1.1. Additionally the update doesn't prompt for a restart but one may be needed

More information on installation of KMS 1.1 can be found in Key Management Service v1 1 for Windows Server 2003 Step-By-Step Guide.doc which is included with the update or in http://support.microsoft.com/?kbid=948003

Scott McArthur
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Product Key not accepted after Integrating SP3 media

tomac — Thu, 15 May 2008 06:52:28 GMT

This blog entry covers a issue that some customers have encountered with the release of SP3 for Windows XP. The service pack supports the use of the /integrate command to integrate(or also called slipstream) SP3 into a Windows XP flat. It is supported to run the command with the following media

Windows XP Professional RTM

Windows XP Professional SP1

Windows XP Professional SP2

The problem arises if the /integrate command is run under Windows Vista or Windows Server 2008. The /integrate process will not report any error and appear to work but if you try to install from the media your product key may not be accepted. Luckily the fix is easy. Run the /integrate command under Windows XP or Windows Server 2003. For more information around this issue see http://support.microsoft.com/default.aspx?scid=kb;EN-US;950722

Author:
Scott McArthur
Support Escalation Engineer
Microsoft Corporation Enterprise Support

Network Settings provided through unattend.txt fail to take effect on Servers if NIC resides on virtual Bus

JamesShamblin — Thu, 20 Mar 2008 23:04:00 GMT

Hello my name is Nitin Mishra and I am working with Platforms Core Team in Product Support Group. This article discusses an issue with latest Broadcom NC Series VBD drivers coming with DL360 G5 and DL380 G5, which prevent the Network Settings, provided in Unattend/sysprep answer file, to take effect. When attempting a unattended installation of Windows Server 2003 with this particular network card any settings specified in the unattend.txt will fail to apply due to how this network card uses a virtual bus driver (VBD).

RESOLUTION

To use netset03.exe to specify network information as per KB 920293
Extract KB920293 and locate file netset03.exe. To extract the file to a location (e.g C:\Netset) use the following commandWindowsServer2003-KB920293-x86-ENU.exe /X
This will pop up the extraction wizard asking for a location to extract files. Once you have the netset03.exe file, create a file named netset.txt (You can choose any name).
Now copy all the adapter specific settings in this file and save.

Now you can use any one of the below mentioned methods to specify Network Settings:

1. Use [SetupParams] in unattend answer file to specify settings.

Create a Folder named Netset under $oem$\$1\Netset (This can be any name and not necessarily Netset). Copy netset03.exe and netset.txt file under

$oem$\$1\Netset Folder. Now add below entry in unattend.txt answer file.

[SetupParams]

UserExecute = “C:\Netset\Netset03.exe C:\Netset\Netset.txt”

You can add the above section just below [GuiUnattended].

2. Use cmdlines.txt to specify settings.
Create a Folder named Netset under $oem$\$1\Netset (Again, this can be any name and not necessarily Netset). Copy netset03.exe and netset.txt file under $oem$\$1\Netset Folder. Now create another file named cmdlines.txt under $oem$ folder. Populate following entry in cmdlines.txt

[Commands]

“C:\Netset\Netset03.exe C:\Netset\Netset.txt“

If you want to install the NIC drivers along with this, you can use the following
[Commands]

“cmd.exe /c {location of nic driver executable} [/switch to make the install silent]”

“C:\Netset\Netset03.exe C:\Netset03.exe\Netset.txt”

The benefit of using cmdlines.txt is that it executes commands in a seqential order and the second command would wait for the first to finish before it can execute. In case of

SetupParams you can only run a single command. In case you’ve added more than one command, the second and subsequent will be ignored.

Note: In case you’re using Netset03.exe, make sure that you use PCIBusNumber, PCIDeviceNumber, PCIFunctionNumber to specify settings for each NIC. In case you’re using

the InfID to specify NIC settings you may see that NIC settings are not getting implemented. If you manually run that command after installation you will see below error:

Network Card {guid} not found in the answerfile.

Author: Nitin Mishra
Technical Lead
Platforms Core

Troubleshooting PXE Boot Errors with ADS Clients

JamesShamblin — Thu, 06 Mar 2008 23:18:00 GMT

It can be very frustrating getting a client machine to boot to ADS if things don't run perfectly and you aren't familiar with any of the troubleshooting methods. I thought it would be a good idea to go over some of the more common causes of PXE boot errors on the client machines and ideas on how to troubleshoot them.

PXE E53: No Boot FileName Recieved

and/or

PXE E55:ProxyDhcp service did not reply to request on port 4011

The first thing you need to check for is if the DHCP server is hosted on the same box that hosts ADS.

1. If DHCP and ADS are hosted on the same box you would need to configure both DHCP and ADSPXE service to be co-located on this box. For this purpose ADSDhcpconfig.wsf tool is provided along with ADS install files. you can locate this tool under %program files%\Microsoft ADS\bin

In order to co-locate ADS and DHCP services you need to run following on command prompt

adsdhcpconfig /add

Above command will give an output stating the ADSPXE and DHCP services are now configured to be co-located. Notice the DHCP scope after running this command. This commands enables scope option#60 and adds PXEClient string to DHCP scope.

If you are planning to move DHCP services to a different box and need to disable the co-location you can run the same tool again with remove switch.

adsdhcpconfig /remove

2. In case of cross subnet communication you need to ensure that the connecting router or switches have IPHelper enabled.

3. Ensure that there is no firewall blocking the port on ADS server.

4. Check if the client machine is added to ADS Console and you've taken control of the device.

5. If you've changed the IP of ADS server you can get this error message. You can contact Microsoft Support for getting ADSBind.exe tool to configure the ADS server to use the new IP.

6. If you've multiple NIC cards on ADS server, changing NIC card settings may leave stale entries in registry binding ADS services to previous MAC address. ADSBind.exe is your friend in such a situation.

More information on ADSBind.exe

On the controller run this command and reboot the controller:

adsbind.exe /A /B:a

This will set the services to the current IP address. Check the event log to make sure all services startup successfully

Note: If the ADS controller has multiple network cards its recommended to bind ADS to a single NIC only. The command you should use is:
adsbind.exe /N /B:a /ip:xxx.xxx.xxx.xxx

7. If none of the above resolve your issue, collect Netmon trace while reproducing the error.

You can download Netmon from below link

http://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8-4213-8d17-2f6dde7d7aac&DisplayLang=en

Author: Nitin Mishra
Technical Lead
Microsoft - Windows Server - Enterprise Platforms Support - Core team (Setup, Cluster and Performance)

Microsoft Assessment and Planning Solution Accelerator Releases Today

tomac — Tue, 26 Feb 2008 04:12:07 GMT

Assess Infrastructure Readiness for OS Migration and Virtualization with the Microsoft Assessment and Planning Solution Accelerator! No IT project can be successful unless the specific network environment is well understood. To help IT professionals and Microsoft Partners solve common migration issues and assist them in planning their virtualization efforts, the Microsoft Solution Accelerators team is proud to announce the release of the Microsoft Assessment and Planning Solution Accelerator in support of the Windows Server 2008 Launch Wave.

How to set up Windows Deployment Services on 2003 SP2 Servers for Installs of Windows 2003 and XP

tomac — Sun, 21 Oct 2007 23:00:00 GMT

Service Pack 2 for Windows Server 2003 ("W2K3" in this post) includes Windows Deployment Services ("WDS"). WDS replaces Remote Installation Services (“RIS”) on W2K3 SP1 and Windows 2000 servers. Upgrading from RIS to WDS is NOT covered here (see: Windows Deployment Services Update Step-by-Step Guide for Windows Server 2003 on TechNet Below is how to set up WDS from scratch, when RIS was not used previously. In other words, WDS in Mixed Mode on a 2003 SP2 server can:

1) install Legacy operating systems (Windows 2003, XP, and 2000) without an existing RIS infrastructure

2) use the WDS management tools, and

3) install Windows Vista and Windows 2008 server from the same 2003 server.

For an in-depth discussion of WDS Server Modes (Legacy, Mixed, and Native) see the TechNet link above. That article also sets forth the requirements for WDS to work, and readers should be familiar with these requirements. However, the article does not cover how to install WDS in Mixed Mode without first installing RIS on an SP1 2K3 server. Why does this matter? In Native mode (as well as Mixed mode, without following steps in this article) only the RIS toolset is available for unattended and over the network installs. By following the procedures here, you will be able to use the WDS Interface and management tools.

Let's get started!

To use the WDS Interface we'll need boot.wim and install.wim from a Vista Install DVD. The wim (Windows Imaging Format) files (WIMinfo for more) are in the "Sources" folder of the DVD.

After installing SP2 on W2K3, you'll install WDS using "Add/Remove Windows Components." After rebooting, the Start menu will have two new applications under Administrative Tools, "Windows Deployment Services" and "Windows Deployment Services Legacy." We want the latter, Legacy choice. This will open the WDS Setup Wizard

The wizard will default to using C:\RemoteInstall as the folder to contain the O/S install and boot files, Microsoft recommends using a separate spindle from the your server 's system partition, so we'll change to D: on the demonstration server.

And select Next. Leave the "Respond to client computers requesting service" blank in the next box, we'll configure this later. Then, you'll be prompted for the i386 folder from your setup source, and you'll be prompted for a folder name in WDS, the default is "WINDOWS" we'll change it to "W2K3" to be more descriptive, but, in the next pane, accept the default, "Windows Server 2003, Enterprise." Next, you'll have the opportunity to review your settings; selecting Next will start the installation of WDS. The wizard will display progress; you'll want to see all blue check marks next to each item. Technically, the wizard is running risetup.exe, the executable that will be familiar to those who used the prior version of WDS, Remote Installation Services or RIS.

When finished, you'll have a "Legacy" RIS server. To manage RIS, you'll need to have the Active Directory Users and Computers snap-in installed. Then right-click your server and select properties, then the Remote Install tab. You'll see the RIS property pages as below. Since this blog is about WDS, not RIS, we'll not go into this, but it's a worthwhile check to be sure everything is working so far.

On the images tab, you'll see our "Windows Server 2003, Enterprise" present under description.

Now, we'll configure the new WDS, by going to the Windows Deployment Services (withOUT "Legacy") in Start /Run /Administrative Tools. This will open the WDS management console.

When you expand "Servers" you'll see an icon with your servers name. There will be a yellow bang (!) triangle, indicating the server is not yet configured. If your server is not there, right click the "Servers" node and follow the prompts to add it. To configure your server, right click on it and select "Configure Server" which will display the Welcome Page of the WDS Configuration Wizard, with the WDS requirements.

The next page will display our Remote Installation Folder Location, set previously, D\RemoteInstall and select Next, where you'll be prompted for the PXE Server Initial Settings. This can be changed after the wizard completes, so for now leave the default "Do Not respond to any client computer" and select Finish. The wizard will configure your server and prompt for installation of your images.

Leave the box checked and select Finish. You then browse to the location of your boot.wim and install.wim files on the Vista DVD. If your DVD is on F:\ you'll configure this page as below. WDS is looking for the "Sources" folder which contains the WIM files.

You'll then be asked to create an image group, the default being "ImageGroup1" Let's change this to something more descriptive, say "VistaImages" and select Next. You'll be given the opportunity to review your settings; Next will add the boot image (boot.wim) and the installation WIM files to your WDS image group

If you select "click here" on the pane shown above, the WDS help files will be opened, since adding the image files will take a few minutes, now's a good time to look. This help file is an outstanding resource for performing installations of Windows, you'll want to be sure to review it carefully if deployments are of interest to you. Its default location is %SystemRoot%\Help\wds.chm.

After the images are loaded, you'll be prompted to complete, and your WDS console (with the folders expanded) will look like this. Notice our "VistaImages." You can include as many images into this group as you like, or create more descriptive groups with their install images. We can change the name, by right-clicking on the folder.

Notice also (not pictured) that when Boot Images is selected, "Microsoft Windows Vista Setup (x86)" is present. Before adding our Legacy Images, let's explore the server property pages (right click on your server, and select Properties). First is the General tab; notice our "Remote installation folder" as "D:\RemoteInstall" then go to the "Boot" tab. Here, the default boot programs that run when a client machine connects to the WDS server are listed. We'll cover the connection and installation later. For now note that the default files are indicated here.

Where are these files in the file system? D:\RemoteInstall\Boot\<Architecture> or for 32 bit systems, D:\RemoteInstall\Boot\x86\pxeboot.com.. Why does it matter? Having the wrong file and/or directory identified is a common misconfiguration.

In the PXE Response Settings, check the box appropriate for your security preferences, and make sure your DHCP settings are correct. Since our Microsoft DHCP server is on another machine, we'll leave both boxes UNCHECKED. This is the default setting, WDS setup assumes your WDS and DHCP servers are separate. The configuration of your MS DHCP server is automatic (you don't need to configure option 60 on it).

If your WDS server is also a DHCP server, you'll want to check both boxes. This is sometimes an area of confusion. The help files are your friend - "For more information, click here" will take you to the help files, with configuring these options as the open page (i.e. the help files are "context sensitive").

The pane below shows the default "Directory Services" tab, configuration. You can create client machine names to most any scheme imaginable, in any trusted domain.

When we select "Legacy Images" in the WDS console we'll see our image created during the legacy install.

In explorer, you'll find the legacy files here: D:\RemoteInstall\Setup\English\Images\WINDOWS\i386 Why does this matter? It doesn't, unless you already know RIS, and want to keep using it and modifying your Setup Information files. RIS is covered here:

RIS Overview and Tools Requirements

Now we're ready to begin installation on a network attached system. You may need to modify the machine's BIOS setting so it will boot from the Preboot Execution Environment ("PXE") network card installed. Most modern NICs are PXE-enabled, but you may need to install one if not. On boot up, you should see the following

After pressing F12, you'll be presented with the following options (RIS is the debault)

you'll then be presented with the Client Installation Wizard, an you're on your way to installing Windows 2003 server.

Conclusion

Enabling a new WDS server, on a server where RIS was not previously installed, requires utilization of the next generation Windows image files (boot.wim and install.wim) for us to be able to use the WDS console. We can use the legacy RIS tools without doing the image installs, but the WDS console is much more powerful and adds additional boot and install options for both legacy and Vista and Longhorn servers.