Ifm63x64.sys

[Asdrubal Dagreat]

Asweird as it may sound this is what happens to me.

I use Config Mgr 2012, SP1.

I'm currently OSD'ing 6-7 different type of machines, one of those is the Lenovo T520.

I went to Lenovos site and picked up their drivers for this model for Windows 7 x64.

It aborted though during the task sequence, after downloading and applying windows, halfway through installing the driver pack

that I assigned for the model.

It said the file : ifm63x64.sys was missing or corrupt.

a bit of googling told me that several other people have had issues with this driver..

"Intel Ethernet FCoE Virtual Storport Miniport Driver Version 1.14.12.0"

The sites I checked seemed to have 100% succes rate by simply removing this specific driver from the package.

They also stated its not an essential driver.

So I completely deleted the driver from config mgr, and of course updated my driver package to the distribution point.

Then got the same error during task sequence

Thought that was pretty weird, to get an error on a driver that was now supposedly non existent..

So I googled some more and saw that some had issues with the driver pack did not actually update even though it said it did.

they fixed this by completely removing it and making a new one.

So I did the following:

1: Deleted the driver Pack

2: Went to the directory and made sure the driver pack had no files left on the server.

3: I created a brand new Driver Pack, I added all the drivers, without the previously deleted 'FCoE Virtual Storport miniport Driver'

4: I make sure the task sequence uses the correct new Driver Pack

And I still get the error. This is where I'm lost.. I attached a photo of the remaining drivers in the pack.

I was hoping someone could take a look at these drivers and go 'ifm63x64.sys' could also be hiding in this one

which doesn't make much sense.. I deleted the driver.. so whats going on?

Did you ever come up with a solution to this? I'm having a very similar issue but I'm using MDT 2012. I have a Lenovo 20A8 and it goes all through the task sequence and reboots then I get the error ifm63x64.sys is missiing or corrupt. It's not in my driver package on MDT but it is in the drivers folder that I downloaded from Intel.

Updated MDT from MDT 2010 Update 1 to MDT 2012 Update 1, uninstalled WAIK, Installed MDT 2013, and then ADK, Upgraded all Deployment shares along the way, and now the extra drive (D:) Wim will not apply to Drive, i have tried two different ways to handle the said action, the first was using the Unattend.xml, adding the DataImage Action, the other was using an Imagex command from the MDT task sequence. neither is applying the Wim, before the upgrade this worked. has any one else had this issue?

Recently, we added drivers for a new Dell desktop. The method was as per previous, (1) download the cab of Win 7 drivers, extract (2) Run the 'unblock-file' powershell on the driver directory to remove the 'downloaded from internet' flag (3) Import into the Windows 7 folder in Out-of-box-drivers (4) Regenerate Boot Images and update the boot images in WDS.

I recreated the boot image fully, in case it had gotten corrupt, and it reported some errors during the import of drivers. Perhaps these had also happened the first time, I hadn't been watching the output as closely.

Hello Forum, I've run into a weird issue. Only one of my images will not deploy. It doesn't boot to the PXE environment, it hangs at the windows screen(see screenshot). I figured, maybe it's a driver thing, so I went to the manufacturer's site and grabbed the latest drivers as well as the Winpe drivers, still no go. Next, I deleted the deployment's boot folder contents and completely regenerated the boot files, still no go. I've also, rebuilt the wim file from scratch, still at a dead end. I'm totally baffled because only one of our models has this problem.

I've made my media folder and placed the contents on the root of my USB key. The computer allows me to boot from the key and select either x86 or x64 (either option ends in the same result.) The computer loads PE and opens up to the greet me with the initial "Solution Accelerators" background. I would expect that the deployment process should kick off at this point but, after a few moments, the X:\windows\system32\cmd.exe box appears and the party is over.

If I can explore the USB and if I try to manually start the litetouch script I get a prompt detailing the script path and a message stating: "No such interface supported". In the command prompt window, I get a resulting line stating "Access is denied". I verified that folder permissions should not be causing the problem.

3. When using a WMI Filter with only one computer model like , the filter works. But it's not convenient to have the same TS step for installing an application three times with three different WMI filters when the same SW should be installed on three different computer models. And we have 4 identical TS that install different OS custom images. So, when there is a new fingerprint reader SW, we have to make 12 changes: Three TS steps in four TS.

Is there a better method to archive this described requirement?

Using MDT 2013 trying to deploy Windows 8.1 with default Taskbar/Desktop icons for every new users...

I have built an image and i use the copyprofile=True settings in my unattended.xml.

I have used the script here: -taskbar-icons-windows-7-sysprep-v2/ and saved it under"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup" , then sysprep'ed the computer. After deployment, however, looks like the script is executed during the auto logon during the deployment task sequence and as the script is meant to delete itself, it is not accessible for new users.

I'm not sure if anyone has tried this, but I thought I'd ask. What I'm trying to do is call litetouch.vbs which is sitting on an MDT distribution share from WinPE. I can call litetouch.vbs and pass in my paramaters to run a task sequence, but the task sequence stops before it runs setup to deploy the OS.

I'm guessing this has to do with some of the info that's being gathered from the scripts and task sequence variables. Has anyone tried this and/or know what would need to be changed to be able to launch MDT from the share instead of from the content on the MDT iso?

If I use %Make%\%Model% approach to set driver group and install drivers with that vs. selection profile that is set to install all drivers from selection profile X. both will have PnP ID driver detection disabled this way.

The first one is to remove the WSUS Registry Keys, we have tried with a VBS Script and reg import. Both do not seem to run to remove the registry settings, but if ran separately they work fine (outside of the task sequence)

The second one is to run two files that are part of Kbox (dell KACE), this fires off an .exe with a switcher. This script is also not running as part of the task sequence, yet once ran separately its fine...

We are getting new model ultrabooks here at work and I have been assigned the task of building our golden image. I got everything configured the way I wanted and when I went to capture the image I got an error after reboot that said Windows failed to start. The file ifm63x64.sys was missing or corrupt.

After banging my head against the wall and searching Google I found a solution, in the driver package on the deployment share there were 2 SCSI drivers that were imported with the NIC driver. I removed those 2 drivers and updated the share completely regenerating the boot images and was able to get a sucessful capture. Now when I go to deploy the .WIM file that I captured I'm getting the same error. It will go through all the motions of installing the OS and goes to reboot the first time and it hangs giving the file ifm63x64.sys is missing or corrupt.

I have created a new share just for this model machine and only imported LAN drivers from the manufacturer, but still got this error. I deleted all of those drivers and imported LAN only drivers from Intel and no go. Go back into the drivers list and see the SCSI drivers are there so I deleted them and still get the error.

I am currently attempting to find a work around that will allow me to leverage a single WDS/MDT image for all of my PC hardware. At the moment, my biggest hurdle comes from hardware manufacturers that are not properly labeling their hardware.

My company has a decent mixture of traditional OEM PCs (Dell, HP, etc.) as well as consumer level PCs with a variety of components (ASUS, Intel, EVGA, etc). The issue I am faced with is getting the proper identification information from the consumer level hardware using the standard 'wmic csproduct get name' command.

If I run the 'wmic csproduct get name' command, several of my components return vague identifiers like System Product Name or OEM. Obviously, this is not ideal as it does not uniquely identify the hardware. In an effort to find a solution, I discovered a suggestion to use the WBEMTEST utility in another thread but sadly, the results are the same - System Product Name or OEM appear in those locations. However, a thread on superuser.com suggested the use of 'wmic baseboard get product' which actually returns uniquely identifiable data.

Any feedback the community can offer will be greatly appreciated. I know this is not the first time this issue has come up but thus far, I have not found a single solution or workaround that adequately resolves the problem short of buying hardware from manufacturers that know what they are doing.

After the OS is applied MDT stops at the Eula Page. I have to hit "accept" and then it takes me to the "express settings" selection. Once I select express settings I am taken to the logon prompt. I have to enter the administrator password where it takes me to the desktop and THEN the task sequence installs my apps and completes.

3a8082e126