Unable to find SETUP and error Code = -2147467259 Windows 7 MDT


  • When capturing the customized image of my reference computer, I was forced to use the IP address of the technical computer because otherwise I could not find it on the network by name. However, I was able to capture the image and moved on to importing the image to MDT. Then I copied the ISO to a bootable USB and started to deploy the image to my test computer. The error I got was similar to the first mentioned in the title of this post. The error said something about "Unable to find SETUP..." and it mentioned something about the BUILD number. I looked online and found that the build number of my Window7 setup files (had imported that to MDT separately) and those from the captured customized image were different. The solution I found online was one to "capture" a NEW customized image with the setup files from the previously captured image. I tried it and was ready to test the deployment, so I did, and I GET OTHER ERRORS!

    ERROR - Unable to find SETUP, needed to install image \\name_of_computer\DeploymentShare$\Operating Systems\name_of_iso\name_of_wim_file

    ZTI ERROR - Non-zero return code by LTIApply, rc = 1

    LiteTouch deployment failed, Return Code = -2147467259 0x80004005

    At this point I am not sure what else to try. I thought it was because the TEST computer could not find the TECHNICAL computer by name, so I went into the Deployment Share properties and changed the name_of_computer to the IP address in both the DefaultSettings and the bootStrap files, but this doesn't seem to fix it. As you can see in the error above, it is returning the path to the wim file with the name_of_computer and not with the IP address.

    Any suggestions?

    Monday, April 12, 2010 9:15 PM

All replies

  • The build version in the imported os properties does not matter, it's not evaluated during deployment. But MDT does need to find the setup files.

    When importing the custom (captured) image, make sure to always select to also copy the setup files (the option is named: Copy Windows Vista, Windows Server 2008, or later setup files from the specific path).

    MDT do try to locate the setup files from other imported operating systems (in the same deployment share only), but I consider it's a best practice to always import them so that the image has everyting it needs on its own.

    • Proposed as answer by HorNet505 Wednesday, February 02, 2011 12:01 PM
    Tuesday, April 13, 2010 9:39 AM
  • Thanks for the reply. What I am going to do is re-capture the image from my reference computer and look for the option that tells me to to Copy Set Up files. However, you mention it will ask for the specific path, and I am wondering if this path is that path to the previously imported Win7 CD or what? Because this is what I did the first time, and so I keep getting this ERROR - Unable to find SETUP. Can you please clarify this for me?

    I have a similar problem to the one described at:

    He doesn't say anything to solve the problem except for avoiding updates, which I am unsure what it means. My reference machine has about 30 applications and it is running Win7. If he means that "running updates" is literally running the updates on an installed Win7, then I guess this is what I did because the imported Win7 CD build number does not match the captured image from the reference machine. However, this makes no sense; why would I want to deploy an un-updated customized Win7 image?

    I would appreciate any feedback.

    Thank you,


    Wednesday, April 21, 2010 6:56 PM
  • Thats fine - except where there are no setup files for the build number you have due to a windows update changing the kernel version on you...  Is there anyway to modify the setup builds for these situations?  Or do you just have to make sure that those updates dont get on your reference image?


    I posted this thread - because of similar issues: 

    Installing MS10-015 - KB977165 before capture will break deployment.



    • Edited by Dan Baker Wednesday, April 21, 2010 7:09 PM more stuff
    Wednesday, April 21, 2010 7:07 PM
  • Btw, you are correct in saying that I should have selected "Copy setup files...". I had actually picked the first option. So now that I am importing the Win7 CD again. When I re-capture the reference machine, I will pick "Copy source files..." and give it the path to the CD, right? Anyways, I will post my progress.




    Wednesday, April 21, 2010 7:16 PM
  • Anyways, after more trouble shooting, the following things had to be done:

    When logged into the reference computer, the credentials of this machine have to match those of the server. Also, the CLONE TAG problem that a lot of post talk about was solved by deleting the CLONETAG varibale in the LTISysprep file.

    We are encountering problems, but moving along. I am starting to have this software though. Why can't it be simple like Gosh Cast was?

    Friday, May 07, 2010 7:44 PM
  • I think MDT is way easier than ghost or any other imaging solution is...  It gives you so much control over your deployment and works without any additional costs.

    They fact that you can inject drives as needed, easily modify deployment task sequences, and manage everything from a central DB including computer OUs, and really anything dealing with the OS deployment... its a great solution.  And MS supports it, so if you call in for support, you can get it from the horses mouth when it comes to MDT :)



    Saturday, May 08, 2010 2:37 AM
  • Thanks Dan.
    Is the update, KB977165, the only one we need to ignore before capturing the WIM? 
    In other words, is it the only update that modifies the kernel thus far?
    Friday, July 09, 2010 2:19 AM
  • If you add the setup files (which you should anyway) when importing the custom wim you don't get this problem.

    Friday, July 09, 2010 7:57 AM
  • Johan is spot on, I added the setup files and my image with all the task sequences executed flawlessly, when importing the WIM, you have 3 options, I chose the 2nd option, to import the setup and sysprep files, it then applied the setup files to the OS directory under the content folder in the distribution share.
    Wednesday, October 27, 2010 5:31 AM