RicaNeaga

I will play with component removal after Lego will be moving probably to 1.6.0, and develop his app into this direction. And a guide only for Component Removal will be very easy to put together, especially if the app will have inside more info on each component. But I don't think of this as an urgency. I'm in the process of writing a guide for the whole Win Toolkit app (first in my native language, then I'll translate it in english and post it here), and when it comes to component removal my first ''recommendation'' is to remove as little as possible - for Home Premium for example only Anytime Upgrade and the folders (Support & Upgrade) are a ''must''. This will evolve with time, however my main goal won't be to make my Component Removal later (1.6.0) guide very stuffed with informations, but rather to ''convince'' Lego to include as much info as possible in his app, so more users would easier find out what removal of some stuff implies.

@Thiersee Are you sure you spelled correctly KB2529687? What kind of update is this??? You mean KB2592687 right??? About KB2574819, please read the discussion here. It's related to this Remote Desktop new protocol. Both of them however won't install on my PC - Home Premium x86 - see here. It's very likely they're compatible only with advanced-networking-features OSes, like Professional and Ultimate. What version of 7 were you trying to integrate those two into?

Ok, great! I won't insist anymore with IIS and MSMQ, they were optional also in my opinion, however two more important things to add: i) VERY IMPORTANT - komm has for x64 three folders: Client folder, Client and Server folder and last Server folder. The Server folder contains updates NOT intended to fix windows 7 problems, but rather Windows Server 2008 issues, so DO NOT include it in the scan!!! Only Client folder and Client and Server folder should be included. To make a comparison, everything in the main x64 folder from McRip server can be found in the main folder from komm's TWO Client / Client and Server folders. ii) About having tweaks txt and html files in the ''main'' section - really don't think it's a good idea. I'll come back tommorow with a full explanation / motivation since now I'm pretty tired. However, the best way from a beginner perspective, as having those there complicates things more than necessary, and make them ''waste'' more time than necessary, is to move them (.reg, .html, .txt files) to a third and last sections, named smth like ''Further info & tweaks'', or maybe not have them at all (.msu files only). And regarding tweaks, I already requested in the tweaks thread for some KB / updates - related tweaks, having a section for them in AIO should be enough, or even better to also select by default those tweaks in the AIO tweak section when a complementary update is added in AIO. Once again, I'll come back tommorow with more motivations for this.

1 - 4. Great! 5. I'll investigate further and come back with feedback.

If you wanted feedback on this, I think that you can let other users enjoy the many improvements you've done so far in the beta, and release a new stable build soon. Maybe tommorow, as i'll also do some more tests and see if everything is ok with the latest beta. And maybe then, after a stable release, other beta-related code refactoring... Once again, for me it's ok only with the beta channel 99% of the time, I was ''asking'' from the cautious users perspective.

1. I think it's better to remove the Desktop Enable Gadgets with UAC Off tweak. Reason: Microsoft already considers it a security flaw, no motives to help in that direction. 2. I think you should rename the Explorer Remove Shortcut Prefix to Remove Shortcut Suffix. 3. Faster Browsing in IE - moved from Misc Category to Internet Explorer. 4. The Misc Remove Windows Mail Splash - remove it or name it Vista only. Windows Mail is gone from Windows 7 / 8. 5. System tweak Disable Windows 7 built-in CD/DVD Burning - although disabled, there is still a windows explorer context menu with the Burn option - do we need another tweak to remove it entirely, or it doesn't work?

99% this request is solved, but please don't close it yet, I'll test Update Catalog tommorow more thoroughly (in an updated test build, not the current v17). Thanks for the answers and support.

Further feedback with test 17. a. The Update Catalog download option is bugged. I tried twice to download KUC Windows 7 x64 checked by default list, and it stopped after downloading only the first update (IE9). Or do I have to press the download button forr 377 times? b. I see you (continue to) include the html / reg / txt files from his server. Why? c. Why do you consider that 7 and 8 (WMPNetShare MediaCenter and Group Policy) from the first post aren't important? Once again, such folders aren't on McRip's additional folder, but they're in the main folder from his server, so he considers them important. I really don't understand the logic behind it - using Media Center in Windows 7 and having multiple accounts on one computer are rare cases in your opinion? d. Why do you scan WMPNetShare MediaCenter updates only from Client and Server folder (5 updates), and not also from Client folder (3 more updates)? Once again, all 8 combined updates are in McRip's main folder. e. Are you sure the updates from the main Client folder are included in the scan for the main category? f. As I've said at no 6, KB971033 is found in the Additions subfolder of Client and Server x64 folder, while KB2646060-v3 and KB917607 are found in the Additions subfolder of Client x64 folder. Why KB2646060-v3 and KB917607 aren't found by Update Catalog scanner? Of course the answer to d, e, and f questions above is that you're ignoring this - http://www.windows-u...fix/x64/Client/ - and it eludes me why.

7 and 8 is the difference from McRip and komm. 7 and 8 are found in McRip's main folder, and not in komm's!!! So they are a must in the second important additions category!!! Let's wait for other opinions, but I really think you should also include 9 and 10 to the second ''important'' additions category. Also, McRip's main folder has its equivalent in BOTH Client and Server and also Client folders from komm. So both are a MUST for the (new) main folder!!!Client and Server reffers to upddates that are aplicable to both Windows 7 / Server 20xx. From what I remember, OLD for BAD is the recently superseded updates folder, but I'm not 100% sure. I'll come back with an answer in an hour or so, I have something to do, or maybe another one can give a quicker answer.

I'm not reffering to the what happens to what happens to superseded updates on the server - of course they're deleted. I'm talking about the updates in the folder found on the user's hdd. Let's say he has update KB998 and KB999, from last month's scan, and this month he rescans, and those two updates aren't found on the server anymore, because they were superseeded by KB1000. But how does he easily finds out those updates aren't needed anymore? I think in the current implementation KB998 and KB99 are still kept on the user hdd, since nothing tells him otherwise, and he will integrate them (KB998 and KB999) alongside KB1000. I'll check again later on this (an hour or so) with build beta 15 / latest.

Then half of the request is done. The other half is to also find the superseded / deleted updates, so the user can also delete them from their PC folder... And sorry for not beeing very meticulous about this. Somehow I just wasn't aware of this.

About beta / test 15, here's my feedback: * New Updates name really must be changed to smth like Main updates, as it's confusing (most of those updates DO NOT change monthly, so there's nothin new to most of them) LE: Nevermind this, however smth like (New ) Main Updates I think is to be preffered as the title to that category. * Question: For komm server, did the ''New'' x64 main updates category contain both Client and Server, and also Client folders? And I hope the ones from the Server folder aren't included / scanned. * Can you make three categories for komm's server? (New) Main Updates / Important Additional updates / Other Additional updates. Important Additional Updates will include 2, 3, 4 and 7, 8, 9, 10 folders from the first post.

I'm not reffering to a list of updates, but to the contents of some folders that are by default checked (with the exceptions of points 5 and 6 from the first post). So if you can make that preset to be variable, 1, 2, 3, 4, 7, 8, 9, 10 locations from the first post to generate ''lists'' that are checked by default after the content from the server is loaded, and then the updates from 5 and 6 to be added. I can guarantee that you don't have to maintain any list, it's very unlikely that anytime soon any other stuff will be added to this preset (except of course IE10 instead of IE9, when it will become available, probably in two months or so). You know better what this implies, however please move this topic to the request sub-forum. The reasons behind it are important, so please take another look. Also, now in beta 14 KUC server scan generates ~800 files, while the preset I'm talking about equals ~400 files. Half! The difference is ridiculous.

Posting it in a new thread, it may be hard to implement, so I don't mind if you won't solve this soon, Lego, or not at all. The problem that generated this feature request is that users every month prefer to spend at least time as possible with updates needed after patch tuesday, so they just download the .7z archive from SoLoR (in the past) / McRip / komm's servers. Or delete the folder with last month's updates, and start over through Win Toolkit. This means high traffic for McRip or komm, and this is really NOT DESIRABLE - the less traffic generated by Win Toolkit users, the better for them. I think there is an alternative. How about this: Win Toolkit Update Catalog to have the feature to scan either McRip / komm's server, and then compare the ''list'' generated from searching the servers with the updates from a folder from the user's PC? And afterwards to generate a list as to what updates found in the user's PC folder aren't on the server (aka deleted / superseded), and also what updates are found only on the server and not also on the user PC (aka new updates). This means that users can safely and easily update each month and download ONLY the UPDATED content from the servers, and also delete the unneeded old content from their PC, in a matter of minutes, faster than deleting and redownloading the whole content of the server, and also with less server load. I has a conversation at some point with komm, that was very ''angry'' with users that tend to download the same content every month - unneeded bandwidth / traffic is used / generated. This request unfortunately also implies having a similar to AIO preset box check, as let's say a user wants to compare the content of only the main folder from the server with what he already has on the folder from his PC, and not compare the entire server with the content of his PC, as let's say unneeded server-like update folders don't interest him. So what do you think Lego? In my opinion this feature is NOT much like the complex tool komm has (that searches for installed updates on the client PC), but at some level the purpose is the same - to generate less traffic for komm / McRip's servers. However I will ask him today / tommorow if this feature is ok with him, and come back with an answer.

Type, Size, Date - unnecessary, I think. Regarding search, I have an idea... but I'll make another request thread since it's more complicated and very likely either undoable, either very hard to implement. However, about treeview, I have also an advanced complementary Win Toolkit feature in mind: make two user selectable presets for Update catalog, named smth like ''Needed x86 updates (regular or home user) to integrate via GDR branch'' and ''Needed x64 updates (regular or home user) to integrate via GDR branch''. Reasons / Motivation: users tend to install everything - this for server-related updates or enhancements, and for 99.99% of users out there, integrating them is just a waste of time as they aren't needed by home users and/or they won't ever use those server-related windows features; beginners NEED the info on what is really needed and what is not; and from our experience, we surely can guide them through such a preset ; save server load for komm / McRip - although they ''give us a finger, we shouldn't take they hole hand'' - komm said at some point that server loads are high enough, and the updates .7z archives may at some point be removed from the server, due to the possible very high traffic. So the less Win Toolkit users stress their servers, the better. The updates must come from komm server for GDR branch. Why? komm's server has an updated folder named Satisfy WU for GDR branch; McRip has such a folder only for LDR branch; komm's server don't have KB2685811 and KB2685813 in the main folder, that may generate windows issues even when installed in LDR mode - McRip has them; (for the moment) McRip's server is innaccesible by many users due to the recent security hardening changes made by McRip. What folders from komm's server must be included in the ''Needed updates (regular or home user) to integrate via GDR branch'' preset? The updates from the main folder, ONLY the .msu files! (BTW, It would be fantastic if you could sort the .html, .reg and .txt info / registry files from his server in a separate category in the treeview, as having them would only scare beginners away, and also the .reg files are meant only for online install procedures, for integrating purposes many of those .reg files need to change). x64 location warning: The main folder means actually two of them, aka the updates from both Client and Server, and also Server folders, with different updates; The Satisfy WU folder; The IE9 folder, WITHOUT its subdirectory LP (language packs); The WUA folder (windows update client updates); KB947821-vxx (currently KB947821-v24) - here we have a problem, since komm prefers not to have it on his servers, only a link to it in the additions, due to its size; it would be perfect if this one can be got from McRip's server; Only KB917607, KB971033 and KB2646060-v3 from the Additions folder; warning - that folder has more updates than those three! KB2646060-v3 is a tweak really needed for AMD current processors (more performance at the expense of more power consumption; also the same result with Intel processors), KB917607 can pop up in WU after installing certain software products, and KB971033 is related to windows activation, and also pops up in WU. x64 location warning: KB971033 is found in the Additions subfolder of Client and Server x64 folder, while KB2646060-v3 and KB917607 are found in the Additions subfolder of Client x64 folder. WMPNetShare MediaCenter folder. x64 location warning: The folder is found in both Client and Server, and also Server folders, with different updates; GroupPolicy folder; MSMQ folder (~ optional, awaiting other opinions); IIS folder (~ optional, awaiting other opinions, although some ''so-called beginners'' may try to host their site on their pc for a while, so having IIS updated may help them). The same way, a preset can be made for LDR branch needed updates, only from McRip's server (that has a LDR-only WU Satisfy updates folder, unlike komm), however LDR (aka beta Microsoft branch) is supposed to be destined / targeted to advanced users, that really know what they're doing, so such a preset may be too much. Awaiting feedback however, as such a preset is much easier to put together from McRip's server.

Fantastic! And more ideas are coming! Thank you also for beeing very receptive to the feedback - the fantastic app (aka Win Toolkit) is a direct result of this.

Ok, great! No need for a request, I thought the preset was linked only to the hosts file. My mistake.

Another issue occurs now in test 12. You can see here the screenshot. It says the savepath must start with %SystemDrive%, although I've introduced it. Not to mention the default location (save path) or preset in Wintoolkit when I load the hosts file is ''%SystemDrive%\Windows\System32\hosts''; it should be ''%SystemDrive%\Windows\System32\drivers\etc'', and hopefully will work without errors in the next build.

It may be integrable, but it surely isn't installable. Not for me that is, on a live system.

If DISM cannot integrate it, then very likely it's not integrable... Also, for me (Home Premium x86), that ''update'' (it's more of an ehancement), the same as the related 2574819 update, cannot be installed on a live system. Also, Remote Desktop Protocol is a very server-oriented feature, for home-users third-party entry-level utilities like TeamViewer are recommended.

Yeah, the RunOnce screen from first logon (that appears only if there are many silent installers added, and the process takes longer than necessary). Thanks!

Just made a x64 image with drivers, updates, addons, silent installers, tweaks, unattended, and everything is as advertised! So build 10 (except the small things above) is just GREAT, nothing wrong in VM, a little faster and also no more pop-up screens about smth needing to restart windows during first logon, probably you can consider the next build final (if you don't make other big changes to it). I'm also going to test the next build (probably tommorow), as I also want to make another x86 image and re-install it on my main machine. Also, another small improvement - please add a warning in the first logon screen (the one that has Win Toolkit by Legolash2o), smth like ''Please be patient - some programs may take longer to install. For example .Net Framework 4 (or 4.5) can take more than 5 minutes on some configurations. Also, it's recommended to restart the pc after everything is installed and you can access the desktop''. I heard that some friends of a friend of mine became very anxious during .net install process (they even thought the installer is corrupted, although no error sign was displayed), turned off the pc, then of course had .net errors etc etc. So this kind of idiot-proof warning, although it may seem useless for the vast majority of users (and especially for advanced users that browse wincert), can be very useful for some.

McRip is really having server issues. For some users the server is online, for other it isn't. So no need to bug Lego with this issue, it probably makes him waste more time than needed for a non-existent Win Toolkit problem.

Ok, great! Also, more of a question: if I remember correctly, wasn't supposed Driver Installer Tool to detect the x86/x64 architecture of the system, and then hide the inadequate drivers (for example hide the x64 drivers on a x86 system) aka stopping them from beeing installed? Now x64 drivers are added to the list (haven't tried to install them), with no warnings (red bar or smth) on a x86 system...

Two small issues in test 10 beta of Win Toolkit 1.5.0: 1. Still the Ene cardreader x86 driver shows up yellow in Driver Installer Tool. You can see a screenshot here, and you can get the x86 5.89.0.71 driver from here. 2. I think the new transparency ''feature'' is quite transparent in certain cases. For example see here - the on-top Apply Unattended window is more transparent than probably intended.