thank you very much. this resolved my week long frustration. in my case it was putting _SMSTasksequence and minint folder on the recover partition cause thast what i had on top of the list as partitions. it would install rest of the image on Primary but after reboot it would get stuck in log and show litetouch.wsf not found(cause they were not on C: but on the recovery somehow). But thanks again.
Following the customization of the deployed image, the attempt to capture fails. I take a snapshot first, then I map the drive to our network share, and can access it without issue. I navigate to the scripts folder, and run litetouch.wsf. **It stalls at "processing bootstrap settings". The progress bar just doesnt move.
Since this is fairly new as far as updates go, there isn't much that I can find out there as to why my capture task sequence works with Windows 7, but fails to get past this part in Windows 10. I can post my bootstrap.ini if requested (with identifying markouts) The command window starts the "About to run command" portion, stalls for a second, and then gives me the "command completed" without the progress bar moving.
We have a WindowsPE image that we have built and are including it on new computers we provided to our clients so we can boot into the PE so we can access the machines remotely and image them if need be. I use to use an old BartPE that was based on XP and when booting the disc it would require a password before the environment would load. I am looking to see if anything like this available for WinPE 3.0
If you download the free MDT 2012 from Microsoft , and look at the MDT 2012 boot media you find two vbscripts (litetouch.vbs and litetouch.wsf) that together with a HTA provides a logon screen to both WinPE 3.0 and WinPE 4.0. You can "borrow" these scripts to your own custom WinPE image.
This PE environment is not going to be used for PXE or similar services. It will be booted from either a DVD or WIM via a BCD edit. To provide a proper clean environment for us to test, backup, restore a computer in the field. We are trying to prevent users from being able to boot into the environment or the disc and have full access to the machine unless we supply the credentials to login to the environment.
The image we are working with now, was built using another utility that builds a WinPE 3.0 disc that has a feature provided by one of our vendors. It feels and performs just like a basic PE disc. We have added extra applications to the disc as we needed. We are just trying to password protect the environment.
what your suggesting is that we use Winbuilder which will build basically a portable Windows 7 environment that will allow the same features of WinPE for deployment plus added things like the security options. Since the site is not loading for me at the moment. Is this utility still follow the rules and licensing of WinPE 3.0, this will only be used for clients with Windows 7 so there for the are fully legal in having a PE disc to us to use as needed on that machine.
BartPE builds from XP (not PE) the same as Winbuilder-XP. This makes it somewhat irrelevant to even use WinPE as WinPE is usually just a "stripped down" Windows which ALSO uses (AFAICR) a Windows CD to build it (I have all of the PE-versions, supplied by signing up as an OEM). Not having used the later WinBuilder software I don't know how well it will work or if it allows for Passwords. Note that I don't use the WinPE's from MS anymore since the alternate method (Winbuilder) is IMHO vastly superior.
All you need is to modify your winpeshl.ini to launch a wrapper that prompts for a password. Then if the password is correct, then it will launch whatever application your normally would. Here is an example of a credential prompt I had built for WinPE to restrict access to cmd.exe:
Can you either: return some more lines in the bdd.log file? I can't tell
from the two lines provided what is happening.
Or, can you re-run litetouch.wsf with the /debugcapture flag in a command
prompt?cscript.exe //nologo litetouch.wsf /debug:true /debugcaptureHopefully the error should reveal itself.-kKeith Garner is a consultant with Xtreme Consulting Services, part of the
Xtreme Deployment Team , and he is a Subject
Matter Expert in Windows Operating System Deployments.
I had a similar problem in the last week. Check your Task-Sequenz and
enable the "continue on error" in the step that cause the problem.
In fact, the resulting problem in my case ist, that the target
computer does not create a bootmanager :)
Deployment works just fine when the computer reboot the first time he
is truely sad not to have a bootmanager at all ...
I am really stuck with one problem with MDT 2010 while automating Windows 7 deployment.I had manually captured (Imagex) windows 7 installation and then created a MDT task on the deployment share. When I bootinto winpe I come across the "failed to run the last action: Install Operating System" error with codes -2147467259b0x80004005. It says litetouch deployment failed.Could you please help me out?I am using lenovo ideapad s10-3 with 32 bit Windows 7 (enterprise edition)LTIApply.log
A tip to debug this issue is to add the /debugcapture when you start the litetouch.wsf script.You can edit the Windows PE Unattend.XML and add the /debugcapture after the litetouch.wsf in the RunSynchronous section. The value on the right side states to run wscript.exe x:\deploy\scripts\litetouch.wsf, just add /debugcapture to the end of it. After making this change you will need to regenerate your boot image with MDT 2010. Then start the process by booting and view the log file when you are done. This might give you some additional information in the BDD.log
You can easily change this background image and use any other images you might want to display during the initial MDT deployment process. To change this background iamge, you will simply need to right-click on the Deployment share within the Deployment workbench console, select properties.
If you want to display the name of the action currently executing instead of having a static text, you can edit the litetouch.wsf script (located in DriverLetter:\DeploymentShare\Scripts) and locate the line
c80f0f1006