I have the same experience, but this "integrated" ISO is released after April updates and hopefully contains all updates integrated and not streamed. Have you found download link for this version to check for sure what it is?
It states that VLSC and MSDN do lack the same Updates . Means they are identic regarding update status.
So far i didn't see someone offering them . As even MS states them being as identic as twins ... i simply believe them. Can remember murphy78 and/or abbodi1406 stating that only the names differ but content is the same .
I haven't laid hands on them either, but the only benefit would have been the additional 2934018 update which is the large one. Since there's an issue with that currently, I have no reason to believe they would have added it to a vl release. MS has a habit of renaming files and putting them on different servers... the digital river win7 isos, for example, are exactly the same as the msdn versions, just with different name. They also like to put up evaluation versions that are actually the same sha-1 hash as the msdn isos sometimes. I believe one of the 2012 and at least one of the 2011 server versions did this.
MS always names them differently, it is doing exactly what it is supposed to do. Make the VLSC people feel like they got a special iso. One example From VLSC Code: 0c65f74adf6444c6ead8c9e822df2df958b6e131 *SW_DVD5_MapPoint_2013_English_Euro_Maps_MLF_X18-20392.ISO d79e709a8255b82c9fd04b5753ede94c3798167a *SW_DVD5_MAPPOINT_2013_ENGLISH_-2_NA_MAPS_MLF_X18-48328.ISO From MSDN Code: 0c65f74adf6444c6ead8c9e822df2df958b6e131 *en_microsoft_mappoint_euro_2013_x86_x64_dvd_1047857_vl.iso d79e709a8255b82c9fd04b5753ede94c3798167a *en_microsoft_mappoint_2013_north_american_maps_x86_x64_dvd_887972.iso
I am familiar with this MS tricks, but I would like to believe that postponing release for one week gave to MS opportunity to clear all the mess with Update 1 and finally provide "integrated" ISO. Whoever get hold of this ISO, should post download links.
In the link you posted is clearly stated that they don't differ, would guess for that reason noone will upload the same stuff again and again .
Think I might have solved the install.esd install failure ~90% problem. I think there is some sort of memory problem in the way that install.esd files are handled. Perhaps It allocates a certain amount of existing memory but toward the end of the file, it goes OVER the allocated amount because of the recovery compression method. I didn't notice the actual error issue in question until I experienced the error with a dism apply in my diskpart/apply script. It gave a memory error. I forget exactly what it was called. So what's the solution? Code: bcdedit /store c:\win81x64\boot\bcd /set {default} truncatememory 0x40000000 bcdedit /store c:\win81x64\efi\microsoft\boot\bcd /set {default} truncatememory 0x40000000 0x40000000 is hex for 1GB. 0x80000000 is hex for 2GB, but be warned that I experienced problems using 2GB. My installs didn't fail a single time using 1GB. You could play with it a bit if you need a little more memory for added language packs or something, but you should test the hell out of anything that uses more. My theory on why it fixes the issue? I think it has something to do with the way that 32 bit programs use memory and perhaps some 32-bit code is mixxed in with the recovery index de-compression that fails when a 32-bit part of the coding tries to interact with the 64-bit part of the coding. In other words, I think there is some x86 stuff happening when amd64 stuff should be happening. It's not specific to setup.exe, but rather a problem with winpe in general when applying esd recovery compression. I still have no idea if they've fixed the EULA issue with split-wims. I doubt it.
@ murphy78 Could you tell me how to put the script from install.esd to install.wim? I don't have any problem from install.win to install.esd but on the other side I can't Many thanks in advance,
It's not advisable to go from esd to wim as you have to apply/re-capture. you can do it, but your wim file will be different every time. It's better to keep your wim source and just export to esd. If you really must know, though... basically the best way is to create a vhd with diskpart and then apply an index to it with dism, then re-capture the directory to a new wim file. You can pick apart the esd decryption and conversion script in my sig and just strip out the decryption parts if you wish, tho you don't really need to. The decryption won't modify the esd if it's not encrypted. EDIT: abbodi1406 figured out a way to export an esd to wim using the wimlib-imagex update utility and a nifty export/delete trick... You can pick apart his latest esd decrypter tool and just use the tid-bits that suit your needs.
Hmm although I experienced no crashes after limiting the ram that boot.wim uses, others are still reporting issues. I played with a lot of different options. I integrated a pre-ga boot.wim with all the updates and resetbase'd it, and subbed it in and copied over the newer date files from sources\ directory to the iso folder... That didn't help at all. First image I tried, failed. I then decided to re-export the coresl versions using abbodi's new trick, in the hopes that maybe there was some sort of datastream problem and that a non-captured version might help. On top of that I decided not to integrate things in the same manner. Basically my previous method add-package'd and resetbase'd the 3 non-pending updates. Then it would install the other 3 starting with 2934018... In this latest version I just start with 2934018, add all the rest, and don't bother with the resetbase stuff... My thinking is that maybe there's some sort of file length issue with a version that has had resetbase applied to it while offline. I also moved from a purely msu integration method to a purely cab method. There's really no need to use msu files on an offline image. My hope is that a combination of the three things I did here will fix the problem, and so far testing has proved successful. Of the 9 indexes I've tested so far in a vm, 9 passed... I'll flip it to uefi and test the other 10 after this next one... But, it looks promising... Anyway, just documenting the issue...