RicaNeaga

Such an advanced option that can be checked by advanced users can be fantastic, and adress everyone's needs.

Win Toolkit now scans only for .cab and .msu files, so only integratable files from komm / McRip servers. If you don't like this behaviour, you can leave a request, but it's better also to give reasons on why you want it. My request (that Legolash thought to solve it in this manner) was to make Win Toolkit's Update Catalog more begginer-friendly. And I think it's very ok right now. Advanced users can make those exe files silent installers without checking each month for updates, or checking only for the ones they need.

Ok, but why is that? This is the same as beeing deleted, aka not beeing shown publicly. What if I want to brag about my help in developing the greatest Windows customization tool to my grandchildren? I'm serious about this, I don't think it's ok you just delete those. Please discuss this with the wincert administrator, and make a section public (named ''Old stuff'' or whatever) with the contribution other people had from the beginning in developing your tool. Don't get me wrong, I'm not upset, I also value and respect your work very much, but this deleting stuff or making them not beeing available publicly may raise questions on why you do this and also can make some people think you don't respect very much their contribution to your app. I know this is not the case here, just making a point.

@myselfidem or other people with the knowledge - two questions: 1. Important - Can I set through the autounattended.xml file the Default Input language for windows 7? This of course if the user selects more than two input languages (in my case, if I select also romanian, and romanian also becomes the default input language - I don't want this, I want to be english). 2. If I select a suplimentary input language, it may have more than one keyboard attributed to it. Can I delete a (keep only one) keyboard through the autounattended.xml? Thanks.

Just made a build with test 36, tested it in VM, and everything seems ok. I'll also install it on a live system and report back. So voted yes. However, maybe you'll take a look at three ''important'' posts first, Lego, with hopefully small bugs/requests... one, two and three.

I also had the same problem with KB943790 that George has mentioned, and I remember you told me Lego to move it to the silent installers folder, which I did. Isn't a good idea for AIO to move it automagically to the silent installers area in AIO by default, as it does now with not integratable updates? I think it's recommended otherwise users will report over and over again this ''error''.

Where is that OLD category? Sorry if I missed it... It's where the old deleted threads from Win Toolkit area (mostly with requests probably) are moved into.

The attached ''error'' happens when trying to integrate via AIO's DISM the non-integratable updates from komm's DVD folder (here for x64, here for x86). These updates are meant for the installation media only. The updates in question (that give DISM errors) are: Windows6.1-KB2023591-x64, Windows6.1-KB2521168-x64, Windows6.1-KB2525084-v2-x64, Windows6.1-KB2673007-x64 and Windows6.1-KB2757588-x64 The updates from that folder that are OK (integrate fine via Win Toolkit) are: Windows6.1-KB2561821-v2-x64, Windows6.1-KB2732500-v2-x64, Windows6.1-KB2748302-v2-x64 and Windows6.1-KB2756651-x64; So there are three options: 1. DVD folder is removed entirely from Update Catalog scan; KB2732500, KB2748302 and KB2756651 are also found in ''duplicate'' .msu form in the main folder, so the only update that will be ''missed'' by he users if the entire DVD folder is skipped from the Update Catalog scan will be KB2561821-v2, and only for x64 images. 2. A filter is set in Update catalog that prevents the updates that are not OK with DISM to be added to the list / downloaded by the user; 3. Win Toolkit has additional rules in AIO for those updates and installs them successfully - additional info on them, besides the individual KB articles, can be found here. Whatever you choose Lego, is fine by me.

So have you fixed this in test 36, Lego? I wanted to make a build... Thanks. BTW, as you can see attached, this error happened also with some user loaded .reg files, not only addons.

Ok, no problem, probably your reasons have something to do with the coding part, so I won't insist. Then can you at least make the app to not consider a .msu file and a .cab file, with the same name, as the same file? Three updates are in this situation: Windows6.1-KB2561821-v2-x64.msu is considered a duplicate of Windows6.1-KB2561821-v2-x64.cab, Windows6.1-KB2748302-v2-x64.msu is considered a duplicate of Windows6.1-KB2748302-v2-x64.cab, and lastly, Windows6.1-KB2756651-x64.msu is considered the duplicate of Windows6.1-KB2756651-x64.cab.

I understand this, but can't those duplicate updates be hidden from the additions folder if they are available in the main folder (recommended section)? The other way around... As I've said, it's important for people who rely on the preset (pre-ticked updates), so they download only the updates in the main (recommended section), and may skip integrating some important updates just because komm or McRip forgot to also delete them from some additional folders.

Great! In test 34, The "User_Extra_Updates" folder isn't renamed anymore, so Win Toolkit doesn't look inside it, so problem fixed, and also the download button is back where is supposed to. However, in test 34, the first two problems from my previous post are still unsolved - to put it shortly, from komm's main folder, five updates are missing form the main recommended section (Windows6.1-KB2494036-v2-x64, Windows6.1-KB2703811-v4-x64, Windows6.1-KB2561821-v2-x64, Windows6.1-KB2748302-v2-x64 and Windows6.1-KB2756651-x64), all having duplicates in one form or another.. The first two updates have duplicates in .msu form, the last three though have duplicates in .cab form, and since you said earlier that, quote, ''Win Toolkit no longer shows duplicates and just shows them in the additionals folder'', can't you do it the other way around, I mean not show them in the additional folder, but show the duplicates in the main folder? It's important because people who rely on the preset (pre-ticked updates) may skip integrating some important updates just because komm or McRip forgot to also delete them from some additional folders. Also, in the future, I'll be making a separate thread for each minor bug I'll encounter, so it can easier for you. Thanks.

In the test 32 version all my problems from my previous post are still present - the five updates from Problem 1 and 2 are nowhere to be found, and also "User_Extra_Updates" is still renamed by Win Toolkit to ''Old". In test 33 again "User_Extra_Updates" is renamed to ''Old", however now the Download button is just gone from the Update Catalog interface, so can't say for sure for the other two problems, but pretty sure they're again present. LE: Attached a proof of this (missing download button in test 33).

It may be a good idea for a simple and quick fix for both - 1.4 and 1.5 - to move KB2592687 by default when loaded to the silent installer category, as with KB2533552 (and other not integratable updates). However, 1.5 looks very close to a final version to me, the only real pain-in-the-... in the probably .7z related issues (loading updates to the app, addon decompressing). Also, the changes in 1.5 are the wow factor. But it is a complete mistery why would a ''simple'' update - KB2592687 - turn Win Toolkit upside down and behave in this manner.

This never happened to me, and I've tried probably hundreds of builds. KB971033 is always integrated with no issue. For me, of course. Lego is already aware of the slowness issues, due most likely to the ''new'' .7z tool. So KB2592687 making Win Toolkit go ''berzerk'' is the real issue. So let's talk it in the other dedicated thread.

At the end it was integrated fine, despite the error quoted, and also after installing the resulted image NFOPad (the problematic addon in question) was installed just fine, and also started it in VM - no problems. So... don't know what to make of it. :g:

Ok, done, updated my previous posts. Also two ~ new tweaks that need your intervention to work: 27. Not working through Win Toolkit integration because the permissions / ownership aren't set - Disable Zip & Cab Folder View [-HKEY_CLASSES_ROOT\CLSID\{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}] [-HKEY_CLASSES_ROOT\CLSID\{0CD7A5C0-9F37-11CE-AE65-08002B2E1262}] 28. Not working through Win Toolkit integration because the permissions / ownership aren't set - Remove Gadgets from Desktop Context Menu [-HKEY_CLASSES_ROOT\DesktopBackground\Shell\Gadgets] And hopefully at some point someone will write here the WORKING .reg tweaks for: Turn Off Windows Explorer Click Sounds Disable Clicking Sound from Internet Explorer Disable Shutdown Sound

This is a small but very important request. After using alot the Update Catalog lately, I decided to use this feature from AIO / Updates. I used to have all updates for each architecture in only one folder, without sub-folders, but now this wasn't the case. And I've noticed that after they were loaded / added to the list, there was no order to them, and for example KB2xxxxxx were loaded BEFORE KB9xxxxx, alphabetically probably, which is a BIG mistake from an integrating point of view. So please change how they're sorted after loading all of them (actually now they're ~ not sorted at all after been added to the list), arranging them the same way the windows OS sorts them in explorer - KB9xxxxx FIRST, and then KB2xxxxxx.

Great thanks!

Tested after making a build with test 31 - everything is ok now. Fantastic how the app now duplicates the location of the file loaded to where it's supposed to be copied. Also love the new First LogOn (RunOnce) screen, with the loading bar. Some may say it's a little thin that bar, but I'm ok. Great work man!

If you take a look here, at first post, a certain tweak was removed from Win Toolkit at my request. It was called ''Enable Gadgets with UAC Off''. Did you use it in the past? Can those gadgets have problems if installed / integrated without that tweak?

Ok, here's what I've found: So dig up from the internet the following tweak for How to Remove “Burn” Button from Windows Explorer Command Bar: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer] "NoCDBurning"=dword:00000001 BTW, maybe permissions / ownership needs to be set for this tweak to be integrated succesfully? Just asking, NOT suggesting. It works ok on a live system. So for the quoted no. 5 tweak to work, also please add this tweak I've mentioned in this post to it, a complementary tweak, and rename it in AIO from ''Disable Windows 7 built-in CD/DVD Burning'' to ''Disable Windows 7 built-in CD/DVD Burning and Explorer Command Bar'' After that, this thread can be considered solved & closed. Thanks.

I've discovered a new issue, one is ''revisited'' and also one suggestion: Problem 1: Win Toolkit's Update Catalog skips from downloading three updates from KUC's x64 main folder - Windows6.1-KB2561821-v2-x64, Windows6.1-KB2748302-v2-x64 and Windows6.1-KB2756651-x64. Don't know why - I searched, I don't think they're duplicates. Please Lego investigate further. Problem 2 (revisited): Although I've sent komm a pm, he still didn't have the time needed to remove the two duplicate updates that generated the problems you're aware of (Windows6.1-KB2494036-v2-x64 and Windows6.1-KB2703811-v4-x64). When I've run today Update Catalog again (31 test build), the two duplicate updates were nowhere to be found!!! So, before your latest fix, those two updates didn't appear in the main update folder (recommended category), however they were downloaded from their duplicate sub-folders, ''server or AD LDS'' and ''server or RSAT''. Now, in test 31, after your latest tweak, they're not beeing downloaded at all! Maybe it would be a good idea to fix this without waiting for komm's fix to its server, because duplicate updates in multiple folders may also be present in either komm or McRip servers in the future, so I think a solution that solves potential duplicate updates is preferable, making Win Toolkit future-proof against this kind of issues. Suggestion 3. Let me first explain why I want the next thing - komm doesn't have on his server Windows6.1-KB947821-v24-x64, because of its size (360 MB for x64, and half for x86), so I named a ''extra'' named sub-folder inside the updates/KUC Windows 7 x64 folder generated by Update Catalog, and put Windows6.1-KB947821-v24-x64. When I ran Update Catalog again, it renamed my sub-folder from ''extra'' to ''Old'' - an expected behaviour, since Windows6.1-KB947821-v24-x64 is not present in komm server. So my small request / suggestion: Maybe the user will have some unnofficial updates or Windows6.1-KB947821-v24-x64 that he wants also integrated alongside komm's updates, and if he isn't careful, Update Catalog will move them to the Old folder, and so the user will delete them, thinking they're superseeded. Can you do something about this, Lego? Maybe a certain folder, with a certain name, like ''User_Extra_Updates'', inside which Update Catalog won't ''take a peek'' / scan?

New addon problem. During integration - this error. I had three addons, only this one manifested this error. Integrated it fine in the past though. Maybe the path is too long? Should I retry with WinToolkit on drive C:?

Nope, Thiersee is right, it's the loading of updates in the AIO list to blame. In v31, is MUCH slower. So probably Thiersee has in its preset also his updates, so that's why his preset is slower. Thiersee, so nevermind / ignore my previous post, with making the preset once again.