ImageX HTA with Win PE 3.0/4.0 x64/x86

[6Maverick6]

Hey Guys

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

[Tripredacus]

It doesn't have to be a network share to use this. As a standalone, you just need to change the drive letter (see the post before yours) to point where the images are located. Even if you don't do this, you can use the Browse button to select the correct drive.

[Tripredacus]

Found a bug with the custom partition values option. HOWEVER this will only work if you put a value in the first box, but leave the second box zero. In this section:

'****************************************************************************
'Two values
'****************************************************************************

Suspect line

ObjFile.WriteLine "    ElseIf form.Custom2.Value = 0 Then"

Should be

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:

#include <file.au3>
#include <array.au3>
Global $var
$var = DriveStatus ( "s:\" )
RunWait (@ComSpec & " /c x:\windows\system32\bcdboot c:\windows")
If $var = "READY" Then
	RunWait (@ComSpec & " /c xcopy x:\windows\system32\EFI s: /e")
EndIf

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.

Server_ImageX.7z

Edited April 25, 2013 by Tripredacus

[dcistech]

This seems as good a place as any to post this question, but if I'm in the wrong place, let me know.

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.

Background:

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.

The Issue(s):

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.

Edited May 10, 2012 by dcistech

[Tripredacus]

I haven't used Win7PE_SE with this at all, so I can't comment on it, including whatever behaviours you are encountering. I have confirmed (in testing) that it does work in WinPE 3.1 (Win7 SP1 WAIK Supplemental) x64.

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.

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.

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?

[dcistech]

Tripredacus, thank you for taking the time to reply. I know this all non-standard, and not your script originally, so thanks for taking the time to comment.

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.

Edited May 11, 2012 by dcistech

[Tripredacus]

No, the progress code is totally broken and won't work as designed. You could replace that code with an animation to show that it is actually doing something I suppose.

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.

[dcistech]

Alrighty,

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.

Edited May 18, 2012 by dcistech

[Tripredacus]

My implementation of using an HTA for a progress animation is easy to close because it isn't being launched from an HTA. So I can just kill the mshta.exe process. However that won't go over too well with this setup, since it would kill your host HTA too!

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.

[dcistech]

There appears to be something wonky going on with the Window_OnLoad, GetWims and ParseFile subs. After adding my animation to the parsefile sub (so people could tell it was working when attempting to get wim info), I noticed it's actually running twice by default--something that's silly, and slows down the HTA. The culprit seems to be a bit of code in the GetWims sub that appears unnecessary. Here is the sub:

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.

[Tripredacus]

I do not see this behaviour happening. The Window_OnLoad that is run from browse is only run after a path is selected. I strive to never actually let techs see that Browse box to begin with. Its primarily a sign of trying to use incompatible hardware with the platform.

Potentially, you could try changing the Window_Onload in Browse() to use the Reload() sub instead.

[crowe80]

I've tried all these suggestions which were all good, but no luck. I'm not sure what's up with this device

[Tripredacus]

Not going to make a new thread for WinPE4 since it isn't too different. The build of the PE is the same as WinPE3 with some exceptions.

- 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!

[robinmke]

I have the v.71 .ZIP file with the ImageX stuff that I'm trying to implement for a project.

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

[Tripredacus]

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 believe that I have included the 64bit browse.exe in the 7.3 download.