Komm has to update the KUC since 9600.17031 got leaked.Everytime i start KUC it says that i got OLD beta packages installed.
If the ADK is final and is build 17029, interesting build 17031 of update 1 is available via the direct Windowsupdate links in the 'Update 1' thread.
..not anymore; KB2919355 link is gone-file not found error and some of the updates download undersized: ...from pg 91 thread 902.
Only KB2919355 is down, rest are working and there sizes are correct KB2937592 is only a 302kb in both x86, x64
that's not as bad as you think. With rtm_gm nearly all old updates are superseded. So the database is totally out of date now.
I managed to get all 6 packages from the mediafire link posted in the update 1 thread after the Pg 91 post. I just went ahead and installed them all in the order specified in that thread (cabs only through DISM). The windows build is now 17031; Windows 8.1 Pro x64. It already had Komm's March 2 KUC updates installed. The whole update went smooth as silk and so far gaming etc. I have not experienced any concerns at all-ran cleanmgr with the reset base switch after update and still have 61 updates installed. Really have not had enough time to gauge real world performance: ie: "my computer seems snappier, faster, more responsive" etc. One thing for sure though is it is no less than before update 1. Also, I have no, and prevent all, M$ appsx/appsz from installing through DISM in my image and live in Group Policy. Also, I have Windows Store and UAC disabled in Group Policy so I cannot vouche for any changes in those areas. Just as a side note, there are many posts on what the prerequisutes are to slipstream Update 1, but, I wonder exactly what is required in the image for this RTM build....?
I think I am going to go ahead and slipstream just the update 1 17031 package-nothing else, and install on a VHD, go to M$ update and see what it has to say.
You cannot install kb2919355 without kb2919442 kb2919355 requires ServicingStack 6.3.9600.17021 as installerAssembly (and this is the first update i have seen ever that explicitly states specific ServicingStack version, all others since Win7 leave it general at 6.0.0.0)
I slipstreamed all but kb2919355 first, saved the image, then, integrated kb2919355, saved the image. I am typing this from a VM with just these 6 updates slipstreamed/installed-so far perfect. Only one update deeply superseded. KB2894029 is not required anymore. M$ update is taking forever; does not show as not responding in Task Manager, but, I am wondering if it is not hanging anyways-just sits there with the "Checking for Updates.." GIF-5 minutes now. Just sits there and hangs on the VM so f***k it; I shut it down. Works OK on the live system though.
You don't need to save image multiple times, all updates can be integrated fine one by one: kb2919442 kb2939087 kb2919355 kb2932046 kb2937592 kb2938439 yes, komm already sorted-out the superseded updates currently those are non-superseded updates: Code: 999994 mspaint hotfix 2894852 .net35 security update 2894856 .net451 security update 2897066 iis hotfix 2925384 .net451 hotfix 2913236-x86 erratamanager update 2926995 .net35 hotfix 2934802 flash update 2935092 DST timezones update additions: 917607Windows Help program Client 976002Windows Browser Choice 2693643 Remote Server Administration Tools 2923122 RSAT hotfix 2835517 Media Feature Pack for N and KN 2899189 Camera Codec Pack did you install the VM in audit mode?
Thanks for this, did not see this anywhere, but, my forum searches rarely turn out successful. I noticed KB2894029 is not on the list...I ran cleanmgr after VM install with the reset switch before running the check CBS log cmd; would it be because M$ update satisfy needs it? I batched the slipstream, so, if I do not integrate KB2919355 after all others have finished I get the Windows version incorrect error and it won't slipstream-of course. Yes, in sysprep; I attached the CBS and Analyzed files resulting from that VM install. I tried saving a sysprepped image once in Windows 8.1 Prox64, but, when doing a live install it changed all the letters of my logical partitions to one up; ie: D became E and E became F so that none of my runonce or cmd files on first login ran because the drive letters were changed. P****d me right off, so, rather than have to deal with it I don't save any sysprep images anymore. Copy Profile leaves me with a fanthom Administrator account that does absolutely nothing, but, if not deleted causes untold grief moving forward. It also takes even less than Windows 7-almost nothing at all-to generate a fatal sysprep error in Windows 8.1; they managed to make it even more fincky than usual. I run on....... (a bit of a rant...) still not happy about M$ update hanging....errrrr Reading the various M$ sites they have special switches for VHD/VM drives in sysprep, but, I just can't be bothered-superflous BS. Why they feel all the drive letters must be changed I'll never know.
WU doesn't work in audit mode in Windows 8.1 i really don't have that much experience in sysprep (i don't even like it ) but modern Apps causes sysprep failure in some cases
It works fine in Windows 7; good thing M$ decided to code another Vista and rename it Windows 8.1-cheaper that way.
superseded or superseding? the list makes it a bit unclear, since e.g. additions still apply, the mspaint hotfix is ldr, latest timezones is post-update1 etc i.e. which updates of the current repo can be kept?
i ment the currently non-superseded updates the above list is my latest check, non-public KUC's special hotfixes are superseded (or included) in KB2919355
Use the windows option to boot to VHD and boot into it. Do a Dism /Cleanup-Image /Online /StartComponentCleanup /ResetBase and Syspreep OOBE Generalize Shutdown and them mount the vhd and capture it and you are perfect to go