ImageX HTA with Win PE 3.0/4.0 x64/x86 Server 2008/R2 WDS Tutorial
Posted 09 February 2011 - 10:21 AM
Basically, if you did the xcopy winpe.wim sources\boot.wim, AND you mounted and modified the boot.wim, then you need to add that one.
Posted 14 April 2011 - 10:52 AM
First of all, I would like to thank to everyone that made this fantastic solution possible!
It really helped me a lot!
Now...the 2 issues I still have!
After applying the image to a machine I always get 2 boot options (both named Windows 7), one works and continues the machine installation and the other do nothing (crashes to the usual boot manager menu).
It's there anyway with this processo to add an answer file when applying the image?
Posted 15 April 2011 - 12:30 PM
2. Unfortunately no. You can add an answer file directly into the image. All my images that use answer files have them in the image already.
Posted 11 July 2011 - 10:21 AM
Also what I am trying to do is, I have wim files in server. I want to stick my USB driver in whatever computer I want and apply the wim file to that computer. So how do I do that any comment will be appreciated.
Thank you very much
Posted 11 July 2011 - 02:37 PM
Open a CMD and verify you have an IP and can access the mapped network drive. Otherwise you'll need to use DISM to put your NIC drivers in the boot.wim.
Also, in the imagex.hta, on line 25 is a "myFilePath" which is what you want to match against the map driver command in your startnet.cmd. For example, mine says:
myFilePath = "Z:\" 'The folder that contains the *.wim files add "\" to the end of the path.
This post has been edited by Tripredacus: 11 July 2011 - 02:39 PM
Posted 27 July 2011 - 07:46 PM
Noob to all this and after reading the first page this looks like it only works back to a network Share.
Before i start getting stuck write into this can it be used to Capture WIMS from the Computer to the USB Drive.
Sorry about the stupid question
Posted 28 July 2011 - 08:46 AM
Posted 04 October 2011 - 10:43 AM
'**************************************************************************** 'Two values '****************************************************************************
ObjFile.WriteLine " ElseIf form.Custom2.Value = 0 Then"
ObjFile.WriteLine " ElseIf form.Custom2.Value > 0 Then"
Here is a Beta Beta version - NOTE: Does not work in WinPE4 RTM x64
For Server 2008 R2 deployments and support for GPT. You cannot PXE boot to this and expect it to work. It can only work if your WinPE boots from a UEFI enabled CD/DVD or USB key. You can still use the non-GPT options with PXE, but if you choose the GPT Disk option when you PXE boot, you will have a 2TB C: drive.
I have a separate boot.wim that uses this "Server" class files. Here are those instructions.
1. Need to change the x:\windows\system32\misc\diskpart.txt so that it will do a default deploy of Server correctly.
sel disk 0 clean creat part pri size=100 sel part 1 active format fs=ntfs label="System Reserved" quick create part pri sel part 2 format fs=ntfs label="LocalDisk" quick assign letter=c exit
2. I have modified the HTA to run a program called GPT check, which checks for the presense of the MSR partition. In my test boot.wim, I have the EFI components saved into the ramdisk, however the appropriate method would be to have a WIM to deploy the appropriate EFI files. And that will get tricky as well because any UEFI deployment is HDD size dependent. I have not yet been able to test same size drives among different manufacturers! GPTCheck.exe (autoit) src here:
This program is called during the reboot MsgBox, which means if you elect to do the other option, it won't run the prorgram. So if you choose to do a shutdown, next boot will result in an error.
3. The second option for the Diskpart.hta "Make one primary partition" now says "use GPT Disk".
4. Changed it so the custom partition values will work and create the System Reserved Partition. This only works with having 0 in the second box. ALSO this does not allow you to do a custom partition on a GPT disk either.
You can test it out. Hopefully I modified the file appropriately.
Number of downloads: 108
This post has been edited by Tripredacus: 25 April 2013 - 02:31 PM
Posted 10 May 2012 - 08:39 AM
I'm working on making a WIN7PE_SE script for v7.3 of this HTA. That tends to mean its a bit of a non-standard install, but even with that, I'm getting some strange behavior.
I'm currently working with the 32bit version of the HTA/COM. I'm using the package installer script to install the hta, mdac, scripting and wmi packages, and that seems to be working just fine. I currently have the script install everything to the program files folder (ease of shortcuts etc) and have the GImageX_COM.dll set to register on boot. I had some trouble getting that to work, but it's working now. The only modification I've made to the HTA itself was to add the GImageX icon attribute.
When I go to apply an image I run into two issues: first, it tells me I need to have a cmd window open. This is strange to me, as the HTA does not appear to use the cmd window, it just wants it open. I looked at the HTA itself to see if I could figure out the logic behind the cmd count stuff, but it's a bit over my head. Any info as to why it does this, and assuming it is essential, how I might be able to automate it doing this (with the window hidden), would be useful.
The second issue, is that even when I make sure to have a cmd window open before running the HTA, I make it all the way to the diskpart settings, select an option (one partition), select the c: drive, and the entire HTA becomes unresponsive.
If anyone has any ideas relating to why this might be happening, and how I can resolve it, I would love to hear them. My organization has been using an older PE 2.0 version of the HTA for a while now to help ease imaging computers for techs with little background/time, but I'd like to put together a more robust version with a number of other utilities (hence the WIN7PE_SE set up). Unfortunately, all of that is for nothing if I can't get this HTA to work.
EDIT: I should note that the HTA is running from RAM, loaded off a flash drive. I don't think that's related, but ya.
This post has been edited by dcistech: 10 May 2012 - 08:41 AM
Posted 11 May 2012 - 09:21 AM
For the CMD issue, the HTA script checks for CMD presense. That is, if you have an additional CMD open (besides the one startnet.cmd uses) it may not run properly until it is closed. I have not tested what this script behaviour does if the HTA is loaded via winpeshl.ini or any other method. I also do not know what the purpose of the CMD checker is for, since it was a function added by the original programmer who has abandoned this project.
There is supposed to be a progress bar that appears on the screen. Since that ability to have a working progress bar did not present itself at the time this HTA was created (Vista) its functionality has not been updated for the newer versions of Imagex.exe or DISM.exe imaging. Even so, many people have trouble being able to accurately read the progress value.
Typically, what appears in its place is a gray rectangle in the middle of the screen. However, on some video cards, no box may appear after selecting the drive letter to install to. In these cases, you need to wait until the Confirmation box comes up saying it is done.
Have you tried a manual build of this HTA to make sure it is working?
Posted 11 May 2012 - 11:41 AM
A quick clarification: when you say it's working in 3.1 x64, do you mean the progress bar as well?
As for the cmdcount (cmdpc) business, I've gone ahead and removed it as part of my modifications--I see no point to keeping it in a Win7PE_SE version wherein the circumstances its checking for don't really exist. I'm building a WIN7PE_SE with it removed, and I'll check on functionality to report back to everyone. If I manage to get it all working, I plan to post if for everyone who cares to add it to WIN7PE_SE.
I'm guessing my issue was not being able to see the progress bar, as the HTA does appear to have renamed the primary partition of my test machine "system" which it was not named before. The only question then, if the progress bar is working in 3.1 x64, is what I need to do to get it to work in 3.1 x86, or if it's an issue of video drivers/cards. In that case, I may try a few drivers.
Depending on what happens with the build of WIN7PE_SE I'm making right now, I'll double check with a normal PE 3.1 and see what happens. It'd still be better than nothing (and far more capable than the old version of this HTA that's currently in use in my organization). I'll edit this post to provide updates hopefully later this afternoon.
Thanks again for your help.
EDIT: So, good news. The only major issue is the progress display. It applies the images just fine. I'm currently experimenting with using the 6.0 wimgapi.dll (the same .dll called for by the normal GImageX WIN7PE_SE script), the updated GImageX_COM from autoit, and the newest SetRes to see if that somehow changes anything (at the very least, they're more recent versions, meant to play nice with windows 7). I'm also having trouble with the network drive mapping window, in that it displays mostly off screen. I've messed with how it determines "center" to no discernible effect, and I'm turning off a few options in WIN7PE_SE. If that doesn't resolve it, I will try with a standard PE 3.1. Also, the cmdpc/cmdcount stuff was worthless. Nothing that I've seen indicates it's needed--at least in WIN7PE_SE. So, I've removed it.
This post has been edited by dcistech: 11 May 2012 - 03:15 PM
Posted 14 May 2012 - 08:25 AM
As it stands, my use of the HTA has diminished greatly in the past year. I do not know our actual usage of the public functionality but I would guess less than 30%. I likely won't make any code changes for the forseeable future. I typically use it to launch custom deployment apps.
Posted 18 May 2012 - 09:45 AM
So I've been tidying up some things in the HTA, and I'm now working on getting a basic animation to display while it's working on whatever its doing. The problem I'm running into is that I can get the super-simple animation HTA window to open, but I'm struggling to get it to close properly. I've tried having it objShell.run(processing.hta) before the main capture/apply/etc operation, and that works great, but objShell.terminate doesn't want to work when the main operation is over (something about HTA limitations maybe?). I've also attempted window.open and window.close, but then I have to direct it to a plain .gif with the stupid IE frame around it. Which is annoying, because eventually I want the text of the processing window to be customized based on the action being performed.
Long story short: does anyone know how to get the main .hta to close the other animation .hta? I looked to the other HTAs run by the main one, and they all terminate themselves(window.close). I could even do that if I knew how to check whether the the main .hta was done, but I don't. All these strange limitations to vbscript in an HTA are frustrating.
This post has been edited by dcistech: 18 May 2012 - 09:46 AM
Posted 21 May 2012 - 09:25 AM
So this is kind unimaginative but... clone mshta.exe to mshtatemp.exe. Then launch your progress HTA using mshtatemp.exe. Then when you are satisfied with your progress and you are done with the animation, then kill the mshtatemp.exe process.
However, I just realised I did do this when I had built a custom recovery partition for an old client... It appears I used window.close() to kill the child HTA when it was finished. So here is that code:
window.close() Exit Function End Function
Now the difference with my example is that I have that child HTA actually doing a task, so it stays open until that task is complete. In your use, you could do a similar thing except you'd need to check for a running diskpart.exe or imagex.exe task, and stay open as long as those processes are running.
Posted 31 May 2012 - 02:03 PM
Sub GetWims(myList()) Dim FSO, strSelectedFolder, strFileList, ObjFile Set FSO = CreateObject("Scripting.FileSystemObject") On Error Resume Next Set strSelectedFolder = FSO.GetFolder(myFilepath) If Err.number <> 0 Then Call Browse() End If Set strFileList = strSelectedFolder.Files For Each objFile in strFileList If Lcase(Right(objFile.Name,4)) = ".wim" Then myList(Ubound(myList)) = objFile.Name Redim Preserve myList(Ubound(myList)+1) End If Next If Ubound(myList)>0 Then Redim Preserve myList(Ubound(myList)-1) End if On Error Goto 0 End Sub
The offender comes right after "Set strSelectedFolder = FSO.GetFolder(myFilepath)," and looks like this (since I do not seem to be able to highlight in the code tags):
If Err.number <> 0 Then Call Browse() End If
The problem is, since GetWims is run automatically on start, the first run will necessarily result in an error (since no wims have been selected) and GetWims will automatically open browse and ask for you to specify a wim. If it stopped there, that would be fine. However, in order for the info browse allows GetWims to pull to show up in the main window, Window_OnLoad has to be run again. So, what you end up with is Window_OnLoad being called from within a sub that was called from Window_OnLoad. And, since Window_OnLoad calls ParseFile, ParseFile (as part of Window_OnLoad) gets run once by GetWims, and then again by the rest of Window_OnLoad. This leads to the HTA taking twice as long as it should to get information from a wim selected when the hta is first opened because the info command gets run twice.
So far, the only way I've found to untangle this mess is to remove the error browse call from GetWims. The fact that it's there in the first place is somewhat strange in that browse will only ever let you select a .wim, so the chances of GetWims erring out due to a legitimate error that needs addressing by re-running browse is incredibly unlikely.
So ya, if anyone else has an idea that somehow untangles the mess without removing the GetWims error call, I'd love to hear it, but as of now it seems completely unnecessary, and actually slows everything down.
Posted 01 June 2012 - 09:01 AM
Potentially, you could try changing the Window_Onload in Browse() to use the Reload() sub instead.
Posted 21 November 2012 - 09:50 AM
- You can add Powershell package
- You don't need to use the set-resolutionx64 (not compatible) and WinPE4 should set resolution to the optimal it thinks the display can use... I didn't test setres.exe because I don't work with 32bit WinPE anymore.
- WinPE4 does not have BCDBoot.exe in it by default, so you will need to copy this in additonally.
NOTE: You cannot use the basic functions of this HTA to work with Windows 8 or Server 2012 images. Imagex.exe does not do the job unforuntately. This still works with previous OSes the same. You'll have to manually use DISM to capture/deploy Windows 8 images!
Posted 13 January 2013 - 12:00 PM
The "Decompiler" is no longer part of the AutoIT scripting package to do the x64 thing.
As such I can't decompile the Browse.exe program to make some modes I want to do with it.
I'm trying to re-create it with the AutoIT scripting package, but having some problems getting it to all work - I'm in a bit of a time crunch, so not much time to learn the Ins & Outs of AutoIT yet.
Does anyone have the Script that was Decompiled from Browse.exe ??
Thanks in Advance
Rob in Milwaukee
Posted 14 January 2013 - 09:10 AM
- ← OEM POST Key (F11, F10, etc) to Activate Windows PE
- Windows PE
- PECMD - password protect explorer.exe →