We are using SCCM 2007 task suquence to build our machines & some packages are self healing on the first launch & it's looking for a task suquence path after first launch. The path is no longer avaialable once the task sequence is complete. Can someone tell me what's been done for this issue.

I've encouter the same issue upon running an MSI from a share location but works fine if i run it locally. What's the way to go about setting up my task suquence can someone please help me on this.



0 Comments   [ + ] Show Comments


Please log in to comment



You will need to modify the packages which are causing this issue. If there is a user profile related file which needs to be self healed then the above mentioned issue will come.

You need to remove this file in the package from user directory and place it in system directory. Then use a script to copy this file from system directory to user directory. and that script should run on repair as well.

Answered 07/11/2013 by: piyushnasa
Red Belt

Please log in to comment

Read this:

Do the above to copy the package locally using a TASK SEQUENCE, then execute the install string using a [SCCM TS] General > Run a command line.

This will fix your problem as your sources are now local and should be able to heal/repair/make you coffee or what ever.


Answered 07/16/2013 by: rileyz
Red Belt

Please log in to comment

Deploy the task sequence again and start the up and use it as normal. Look in the event log to see what components are triggering the repair - you will get some funky looking GUIDS. 

Once you have that you can open the package in InstEd! or your choice of MSI editor to see what component is casuing the problem. From here you should be able to fix the problem if you are a packager. 

*Set the component to always install - cant remember the name of the setting you need.

The reason this happen is because its installed under the SYSTEM context, and misses some bits, i havent figured out why yet, but it happens from time to time in packages when deploying from SCCM.

Good luck!

Answered 07/11/2013 by: rileyz
Red Belt

  • Not quite.

    The problem is that WI records the source folder for the MSI as 'C:\_SMSTaskSequence[blah, blah, blah]' but, after successful execution of a Task Sequence, the SCCM agent deletes this folder.

    It's not pretty but I have in the past worked around the issue by packaging user-level stuff as a separate package with a dependency on the TS package being present.

    Oh...and @OP...the "Cloud Computing" tag? Huh?!?!?
    • Wouldn't it be better to solve the source issue form the get go?

      I haven't run into this issue often but isn't there settings to ensure the package is cached and used as source for repairs instead of the original file location. I haven't really run into an app recently that I noticed original msi was required.

      Then again, I probably would just use a scripted activesetup vbs or something to copy user files from INSTALLDIR to proper locations, its what I know. or another msi like you said.
  • I think the MSI always get cached in the MS installer hidy place. But you do get problems when there is a CAB file as this wont get cached at all. At this point I try and shove new souce paths into the MSI it can look somewhere else to find it, ie on the network etc.

    Love this forum, everyone has a different way of achieving their goal, learnt a lot from others here.
  • Thank you for all the feedbacks i've tried bunch of things and still getting
    "C:\_SMSTaskSequence...The feature you are trying to use is on a network resource that is unavailable" Do you guys think by adding the add ADDLOCAL=ALL property would do the trick? I haven't tried this yet
  • If you just want a fast fix hack job. In the TS get it to copy the installer locally but hide it from users in a location like C:\Windows\Software, Run a cmd to install from the local source. Since it was installed from local it will know where to find the files on heal.

    OR in the TS run a CMD to install it using a UNC path.
    ie \\BlahServer\Share\msiexec /i MyInstaller.msi /qn
    Since it was run from UNC it will know where to find it - juts dont move the files in future.
  • In the default scenario, that won't work, will it, because the local System account has no network access.
  • Oh yeah, good shout. Chichora123 dont try the 2nd one.
    Im going to have a BBQ now, hot in London :D
  • You have a fundamemtal misunderstanding of the function of ADDLOCAL. Aside from that, it is specific to Windows Installer. SCCM will be blissfully unaware of *any* property in an MSI! :-)
Please log in to comment
Answer this question or Comment on this question for clarity