Windows Integration Guide - murphy78

I've noticed that when you add a bunch of kbfiles to an index and then try to export the index using install.esd format, it gives an occasional installation error as if it's not finding the data correctly.
The strange thing is that it often goes away after rebooting and re-trying to install.
It doesn't happen every time and it seems to be fairly rare, but I have noticed it occurring with more frequency the more data you add to an offline image.

Next month for my win8.1 aio I'm going to do an experimental method where I export each index to a different install.wim using /checkintegrity and then also do another export using /checkintegrity back to a separate install.esd file.
I'm thinking that the issues regarding my install.esd problem might be related to the way the install.esd is created. It might not deal well with the way I integrate one index, re-mount to change setup\scripts folder for pre-activated stuff and then re-exporting.

The idea is that it may be treating the install.esd like a highly compressed virtual hard disk snapshot method. I'm not exactly sure what it is doing because it's fairly undocumented, but I have a suspicion that the methods with which it handles the indexes during the export may be very finicky. If you can recall when we were playing around with KMSmicro 5.0.0, it had a snapshot method where the original hard-disk is highly compressed, but any modifications are saved to a second file. I'm thinking that the install.esd may be handling things in a similar fashion. Or, I could just be completely wrong and it could just be some sort of issue that MS is aware of, but not spending any time fixing since install.esd files were designed for single indexes.

Anyway, I'll try and remember to post my results next month when I test it out. I'll give it a test run on a win8.1/office2013 sysprep capture I plan on doing later this month, but I don't anticipate any issues as they only have 2 indexes and this problem seems to occur when you have like 10+ indexes and 500+mb of updates queued up for each index.

It could also be related to the dart I added to the boot.wim or re-compressing the boot.wim with max compression.

It could also be related to pending updates. Perhaps there is a maximum number of pending updates allowed with the install.esd format. It wouldn't make sense to me, but It seems like it's possible since setup.exe would have to handle the install.esd separately from an install.wim method.

I'll play with a lot of different options and try and report results.

 

You need to login to view this posts content.

 

Just wanted to add that I seemed to have solved my export to install.esd issue with the 95-97% install failure.

What I did to solve it is what I described attempting:
First I export each index to a new install.wim using /checkintegrity flag dism commandline
Then after I'm done with the entire AIO, I do a for /l loop to export all of the new install.wim indexes to the install.esd and also use /checkintegrity

I think that, as strange as it is, it was getting hung up on my integration method exporting each index to install.esd, remounting the same index to modify a few files, and re-exporting it to a new index.

So for the enthusiasts out there, the export to a different install.wim command looks something like:

Code:

dism /export-image /sourceimagefile:c:\win81x86\sources\install.wim /sourceindex:1 /destinationimagefile:c:\temp\x86\install.wim /compress:maximum /checkintegrity

I obviously repeat it for each new index that I need to be on the AIO and I use imagex to rename them if same index, but with pre-activation files etc...

and the export to install.esd loop looks something like this:

Code:

del /q /f c:\win81x86\sources\install.wim


for /l %%x in (1, 1, 20) do (
e:\waik5\amd64\dism /export-image /sourceimagefile:c:\temp\x86\install.wim /sourceindex:%%x /destinationimagefile:c:\win81x86\sources\install.esd /compress:recovery /checkintegrity
)

 

There's an update to the 8.1 adk that changed the imagex.exe
Perhaps they noticed that and fixed it.
I've been using the old gimagex v2 or the dism for exporting so I haven't really paid attention...

 

You don't want to add them with software while online.
What you would do is first capture the image.
Then mount the image
Then do a dism /add-driver command. Example:

Code:

Dism /image:d:\mount /Add-Driver /driver:E:\Win7Slipstream\Install-Drivers\x86\ /recurse

the /recurse option is a must have for folders that have many subfolders with drivers in them. It will hunt for inf files and their corresponding drivers and programs.
Note that it will not add setup information. This is just for the auto-detection stuff during Windows Setup.
It will also not use unsigned drivers. You can enable unsigned drivers but you may or may not be forced to change the image to allow unsigned drivers as well.
I don't mess with unsigned drivers and I also recommend that you guys do not mess with them as well, unless you know exactly what you're doing.

 

You cannot slipstream any net4+ stuff into win7. You can script it to install during setupcomplete.cmd, but I've purposefully not done that.
It actually takes less time to install after the system is up and running and all of the runtime improvements are active.
I had a lot of people complaining that their install time was too long when I had net4.5.0 and the hotfixes included.

 

I'll likely be including the update this Tuesday. When newer versions become available, I will likely include those instead.

@yessmann answered in your pm.

 

You need to login to view this posts content.