tes1966

Ah... I should have added that detail. Sorry. I have no exclusion list for imagex so it's incluing everything in the folder. The users have full read, write and execute permissions to the folder that contains the files that need to be included in the WIM. For example I create a folder called "E:\Work\Office2007" and then copy the contents of the Office 2007 CD into this folder. The users have full rights to the folder. They run imagex and nothing happens... no errors... no WIM file created. Log in as as an Admin and all works fine. We started out with imagex.exe 6.0.6000 and are now using 6.0.6001.

Hello... I have a Windows Server 2003 system. We have have a dozen or so users on this system. Each user is in the Users group. We are trying to get imagex to run for these users but it's not working. We are basically trying to make packages of files using imagex for use in our Windows XP and Vista images. When a user tries to run an "imagex /capture" it starts and ends with no error messages but does nothing. When logged in a a power user or admin all is fine. Would anyone know what to set (policy or other) on the system to get imagex to work for standard users?

Hey There... Try adding this... [unattended] Unattendmode=FullUnattended

I'm wondering if anyone has tried the Sysprep solution that I outlined above? I would like to know if this works for anyone other than me. Maybe I didn't document it correctly? This has nothing to do with Microsoft doc 309283. It has everything to do with IRQ's as I previously stated. If you don't have the correct HAL on the machine you will never be able to properly deploy an image on a machine that has this hardware. Also, this Microsoft doc is not entirely correct when it talks about what HAL can be depoyed on what type of machine. What they are doing is covering their a**. You can really screw things up by changing the HAL to something that the hardware doesn't like. Just like modifying the registry. Microsoft shows you how to do, gives you the tools to do it, but will not be held resonsable when you screw it up. The same goes here. You either have to start with the correct HAL or change it to the correct HAL with Sysprep. Modifying the IRQ that the driver uses doesn't really help you create an image that works on all your target hardware. If you want to create an image that can be deployed on 99% of Dells, HP's, IBM, white box, desktop, notebook's you need to start with an "Advanced Configuration and Power Interface (ACPI)" and then change it, when needed, to an uplevel HAL like the "ACPI Uniprocessor PC".

Sorry but you don't. Windows XP has to have an "ACPI Uniprocessor PC" or "ACPI Multiprocessor PC" HAL. If you don't, the TPM driver will hang the machine and the only way to change it is to run SYSPREP.

Hey There... I got this working a couple of weeks ago. Here is what I did. Do an unattend setup of Windows XP on you donor machine. Change the HAL (the device listed under Computer in the Device Manager) to "Advanced Configuration and Power Interface (ACPI)". Setup your SYSPREP directory as usual but in addition create a subfolder called "HAL". EXPAND from your i386 source the following files unto the "HAL" directory: hal.dll hal.inf halaacpi.dll halacpi.dll halapic.dll halmacpi.dll halmps.dll halsp.dll Add the following line into your SYSPRE.INF file under the [unattended] section: UpdateUPHAL = "ACPIAPIC_UP,%SystemDrive%\Sysprep\Hal\Hal.inf" Make sure that the NSC TPM driver files are included on your donor machine but in a directory that will not be accesed by Windows XP during it normal PnP device detection. ie. not in the OemPnPDriversPath= in your SYSPREP.INF file. Create a batch file that will copy the NSC TPM drivers into on of the directories that you have listed in the OemPnPDriversPath= in your SYSPREP.INF file. eg. OemPnPDriversPath=Drivers\TPM;. Add a line in the SYSPREP.INF file under the [GuiRunOnce] section that will call this above created batch file. eg. "c:\temp\copytpm.bat" Run SYSPREP Clone the donor machine (Ghost, DriveImage, etc) Try it on the S51 When the system first boots on the target machine SYSPREP will up the HAL to what is needed. Then SYSPREP will copy the driver over so Windows PnP can install it. Windows may say something like it's finished installing new hardware and needs to reboot. Reboot and you should be good to go. The TCM chip in the S51 needs an "ACPI Uniprocessor PC" or "ACPI Multiprocessor PC" HAL on the machine. If you don't have this HAL the driver will lock the system up bacause it will access an IRQ that is not available to it and Windows being Windows it locks up. Hope this help and works for you. We beat are heads on this for over a week and finally got this to work and it works great for us. By the way, I work for IBM and we are using IBM's ThinkVantage tool called ImageUltra Builder to automate the above process.

Yes are seeing that same problem. We have S51 here that are having the issue. We can setup an unattended installation of the OS and have Windows setup install the driver with no issues. But, if we take a sysprep'd image and try have minisetup do the install or do a manual install of the driver after minisetup the system freezes. Have you been able to find a fix for you problem?