RicaNeaga

Looks like there's also a need for a prerequisite area in the silent installer category from AIO. Why - already said above, .net 4.5 + Windows Management Framework 3.0 should always be installed first during first logon (in this order), so that other hotfixes for Windows Management Framework 3.0 (currently only two for it - KB2809900 and KB2823180) can install after that. All of them are recommended updates in WU, so this is a needed thing to do. I'll make a request if when Lego's back', he won't solve this one. About that AD LDS hotfix, I'll take a look this week. LE: Windows Management Framework 3.0 cannot be integrated because .net 4.5 currently cannot be integrated (no true addon for it), and so neither can their hotfixes.

KB2809900 (btw, you forgot a 0 in the end) and KB2823180 are both, as you can see here, Windows Management Framework 3.0 related updates. Windows Management Framework 3.0 needs .net 4.5/4.0, so you need to move them both to silent installs area in AIO, and rename them so .net 4.5 (4.0) always installs first, then Windows Management Framework 3.0, and only after that those two updates, Also, KB2772930 is an AD LDS update. I don't get it in my WU window from this month because I haven't integrated AD LDS related hotfixes. So you also need to move that KB2772930 by renaming it with a ''z'' in front, making it integrate last / after the hotfixes in the AD LDS folder. btw, why do you need AD LDS for? You're really a power user...

I don't think any of the current important repacks from ricktendo (.net & this vc/b aio) are compatible with Win Toolkit anymore, at least when using switches in Win Toolkit AIO (under silent installers tab). It's either the new multilingual lines from the setup, or the new SFX. Going to test it this weekend / next week and come back with feedback. @ ricktendo Visual Studio 2012 Update 2 is out. Probably some newer VC++ 2012 is also out...

Please update this also to the latest version. I'd like to try it in my next xp build. Thanks.

At last a real reason - see here.

So it's an order issue after all... probably build 15 test 15 wasn't aware of IE10, that's how you were able to integrate it last, right? I mean that the reason IE10 isn't moved by default in the prerequisites area... Win Toolkit doesn't have a rule to add IE10 to the prerequisites area as in the latest build. If this is really the issue, and I don't see why not, I don't want to dig up an old argument, but I've really never understood why integrate Internet Explorer before the rest of the hotfixes. I made a thread special for this (besides making my point a couple of years ago, when this was first introduced for IE9 and its language packs), see here, so in a way I ''predicted'' this issue. @Lego Maybe the order is not the issue, maybe something else is just wrong in Win Toolkit, this really doesn't matter however to my request from here. If such a removal of prerequisites filter would exist for advanced users, and we'd have the liberty to integrate the updates in whatever order we'd want, at least we could better troubleshoot situations like these.

I don't think it's a Win Toolkit issue, probably McRip named it so.

Question: Why aren't you integrating also the KB2533623 prerequisite with build 22? It's needed although it's superseeded - see here. I noticed it since you have only four prerequisites installed instead of five.

Everything works great now on x64 (addon integrated with Win Toolkit). Great work! Going to try it also on an x86 image, and post again if anything happens. But it's likely everything will be great also for x86, as only x64 was always a little problematic.

I edited my first post as the second error was a one-time-only glitch. Kept though the spoiler with the error log, maybe it's useful. The first ''cosmetic'' error happens however everythime - ''WinToolkit_Mount'' is always left behind.

IE8 is in the untouched MSDN SP1 edition. And DISM gives in AIO a message that IE8 is uninstall pending after integrating the IE10 cab. I also always use MSDN images. I was thinking for a solution for your problem, like moving the language pack to the silent installer area, I'm not looking to argue with you. But still think it's a strong possibility that this is a Microsoft problem, not a Win Toolkit one.

komm ran some test and come out with a very interesting theory, and this is probably the source of your problem. Qoute from here: You may have noticed in the Installed Updates tab (after the integration took place in AIO) that IE8 has an uninstall pending notice. So it's very likely some language packs cannot be integrated because of that uninstall due to happen process. When is that happening? Theoretically during first stage of windows installation. So as I suggested earlier, I repeat myself - try to add the language pack as a silent installer. It's very likely it will work. So it's a strong possibility that this isn't a Win Toolkit bug, but a Microsoft one. komm also pointed out that from his test the latest platform update is incompatible with VC++2010 and VC++2012. As there was also the f**kup with the driver framework that still generate blue screens on some systems (they don't get along with some especially video drivers), and also the decision to stop develop SP2 for windows 7, it's either a tactic to force people into upgrading to windows 8, or just sloppy work. Either way, hope it will work for you as a silent installer. At least we'll have an answer.

The warning I'm talking about is the one attached, reffering to the possible errors generated by some (?) hotfixes in the Additionals folder from McRip servers. I suggest to remove / improve this vague warning, that may scare users away from the hotfixes in the Additional area (as the useful IE10 and probably soon the Satisfy WU hotfixes). Solution A - the quick solution - add this warning only when KB2592687 is loaded in AIO, as this is the only hotfix that can make windows install process go bananas. See detailed thread here, it can generate errors even without its prerequisite. Solution B - the ''complete'' solution, with three sub-requests. This covers ALL problems generated by the Additionals folder. 1. Add a warning for KB2592687 ONLY if added in AIO; 2. Move KB943790 automatically to the silent area when loaded in AIO. I also attached the error generated when trying to integrate this useful ''hotfix'' / additional funtionality; 3. Remove from McRip's servers default scan in Update Catalog some sub-folders in the Additional area - the ''Integrate to installation media'' (why? because ~ all are not integratable, and the .txt instructions aren't loaded by default in the Update Catalog), the ''RemoteDesktopProtocol8.0'' (why? because it includes the most dangerous hotfix Microsoft ever created - KB2592687) and the ''BallotScreen'' (why? not integratable, really unuseful ''hotfix''). This also involves an additional explanation to the ''Update Catalog Filter'' checkbox from Options, smth like ''Update Catalog will only show .msu, .cab and .msp files. Some non-integratable hotfixes are skipped by default, and also some nonessential hotfixes that when integrated may generate errors during windows install. Uncheck this only if you're an advanced user''. With solution B I think you'll get rid of many potential bug reports (both on the forums and directly via the app). However you'll decide which (sub)solution is is the best to implement.

Ok, since this is the only solution, I trimmed your installer and your config.txt to the best of my abilities. The result - a passive installer, that requires no user interaction, and that installs everything except F# & J# (also removed them from the package, so it's also smaller in size) - if anyone's interested, you can find it here. All the credits go to ricktendo, but I didn't wanted to repack his installer, the reason beeing that I can't use SFXMaker anymore for this. Again, please ricktendo, investigate this for the next version, this has never happened to me with any installer that I wanted to make silent with SFXMaker (it always worked with this installer also until ~ month ago / haven't tried it in the last month).

This is very important and gives a totally weird KB order when you load updates in AIO with the ''Add Updates + Subfolders'' option in the Updates ''basic'' tab. The random order is also present in the prerequisites category, with IE10 first, above its prerequisites! I attached the result. I really thought my request was finally solved, but this happens only when selecting the ''Updates'' option from a single folder. The desired behaviour would be for WinToolkit to sort the (for the first time) loaded hotfixes in AIO with KB9xxxxx first, then KB2xxxx, and of course with the prerequisites always above, even when loading the updates from a folder with many subfolders. Also, the sorting feature using the categories in AIO (name / size / location etc) doesn't work also, but this is not so important. If Win Toolkit would always automagically sort by default for the first time in the correct order (prerequisites, then KB9xxxx, then KB2xxxx) the loaded updates, then consider this solved. PS: x86 win 7 Home Premium environment.

1. As you can see in the screenshot, a leftover folder (''WinToolkit_Mount'') is still present after only integrating one update in AIO. x86 win 7 Home Premium environment. 2. KB2446607 isn't integrated (also not in the integrated tab) with the following error: Title: 1 error(s) have occurred ErrType: Error (1.4.1.22) Description: Win Toolkit has recorded errors which occurred during integration and have been stored via '>> Details'. Exception: Exception: An error occured whilst integrating an update! Exception: Microsoft Windows [Version 6.1.7601] Copyright © 2009 Microsoft Corporation. All rights reserved. C:\Users\Administrator\Desktop\WinToolkit141-22>Set SEE_MASK_NOZONECHECKS=1 C:\Users\Administrator\Desktop\WinToolkit141-22>"C:\Windows\System32\Dism.exe" /Image:"C:\WinToolkit_Mount" /Add-Package /PackagePath:"C:\7lite\Updates\McRip Windows 7 x64\Windows6.1-KB2446607-x64.msu" /ScratchDir:"C:\Windows\Temp\WinToolkit\ScratchDir" /English Deployment Image Servicing and Management tool Version: 6.1.7600.16385 Error: 3 An error occurred. The directory in the temporary folder C:\Windows\Temp\WinToolkit\ScratchDir could not be created. Ensure that the path to the temporary folder exists and that you have Read/Write permissions on the folder. The DISM log file can be found at C:\Windows\Logs\DISM\dism.log C:\Users\Administrator\Desktop\WinToolkit141-22>exit ---------------------------------- Tried again in a second run, to install only this update, and everything went fine. I'll give more feedback as I want to find out the needed WU Satisfy hotfixes for both GDR and LDR, so I'll integrate it one more time in LDR mode, and see if this error comes up again when integrated with all the other updates.

Please take a look here. Make sure you have the correct five prerequisites, and you use the .cab renamed with a ''z'' in front of it, so it always will be below the 5 prerequisites in the integration queue. If this isn't the issue, then maybe installing the language pack as a silent installer will help.

Just tried to integrate the IE10 .cab (english version, no language packs), and before getting to the two issues below, just like to say that the correct prerequisites (the correct 5 hotfixes) are pushed ~ above for it, and IE10 is detected even as a .cab. Great! 1. As you can see in the screenshots below, IE10 .cab isn't integrated AFTER the prerequisites unless it's named properly. Putting a ''z'' before the real name of the .cab ''solves'' the issue. But this shouldn't happen, this is more of a bug, IE10 .cab SHOULD ALWAYS be pushed last in the prerequisites front list, beeing ALWAYS integrated AFTER the 5 hotfixes. 2. Tried to integrate the IE10 .cab without prerequisites. ''Succeded'' with a blue line - no warning box whatsoever! Of course IE10 wasn't really integrated, but my request above was to add a warning box (smth like ''be sure to also integrate the followinf FIVE hotfixes that are needed for IE10 to be integrated properly'') when IE10 is detected. LE: x86 host system environment, maybe this is important, to be more exact Win Toolkit 1.4.1.22 was used in a x86 windows 7 H.P. environment.

Ok, but can you please give me an alternative to SFXMaker? All I want is to repack your installer with the /ai switch. Please not only give me a suggestion, but test it yourself, as I really think there is something wrong right now. ~ A month ago everything was fine... Thanks

Can confirm this is happening because of the architecture. Just tried on a x64 virtual machine, and the bug is gone. However, it's still present on x86 architecture (for the host system) with the two similar addons from above. Weird bug, hope you'll be able to have a x86 environment soon and solve this one.

Also, important info in this thread from today. It's related to the latest service and how it doesn't need admin privileges (so yeah, the UAC shortcut really isn't needed anymore). LE: Posted in the same time, going to test in about four - five hours, please take a look at the link, maybe some other changes are needed.

Tried your latest addon in a x64 VMBox environment, and got errors, probably due to the shortcut. Screenshots attached. Also, if I start the program from its installation folder, it does start and works ok, however the startup scheduled task isn't, so if I want to use it I have to start it everytime from the installation folder, as the shortcut from start menu doesn't work.

Can you think of a reason why this installer doesn't work with SFXMaker anymore? It's not SFXMaker version to blame, I tried both the current one (1.3.1) and also the previous 1.2.1. I'm trying to apply the /ai silent switch to it via SFXMaker, but it doesn't work, both via Win Toolkit's first logon, both on live system (same ''setup.exe'' error). You have the error attached. However, if I use the /ai switch via Run Arguments on a live system, everything is working fine. The reasons why this is happening are beyond me... this has never happened in the past. LE: To be more precise, when added via SFXMaker, the setup files don't get extracted /unarchived / uncompressed on the local disk (doesn't get to this ''first'' stage), while via an argument on a live system they do get extracted, and after that everything is ok. Maybe you changed something in the last ~ month that generated this weird behaviour. Maybe this, as it's related to the ''extract'' stage.

I think this is virtually impossible, as the file is downloaded and ''created'' on your local disk. If you worry about the source & data integrity of the files downloaded, there are more advanced tools for this out there, as for example MD5 readers.

Yep, can confirm the specified bug, both in 2.1.2, and also in the today released 2.1.3. Everytime I try to open a .msi file, I get the run parameters window. Weird bug and don't understand how the devs aren't able to detect it. I don't have time to try it and either to open a support ticket (probably they'll close it right away, as it's ''unbelievable''). Great I have an ''old'' alternative - Run with Arguments. Going to use it until things are better on this front. Thanks again for the info & help.