RicaNeaga

He's the man! Thank you very much! :dancing: I'll try it with -ai switch in a couple of hours, and come back with feedback.

I've used your installer with nlite also (made it as an addon first). Everything is ok with Everything 1.2.1.452 Great job! Thanks again!

@Cipherfx2 you can find the answer you seek here.

Let me continue... 4. Wax on, right hand! Wax off, left hand! Wax on, wax off! Sory for the offtopic. Couldn't help it.

Besides requesting once more that very useful ability to Auto-Select Language, Locale and Keyboard Locale (when you'll have the time, of course), I have two suggestion regarding Unnatended Creator: 1. A warning for users when they start the creator to choose between the x86 and x64 architectures at the top (the interface is a little akward, and this option may be unintentionally skipped), or perhaps it's better to show it under general category; 2. A warning for users when they choose the skip auto-activation to also insert a generic serial from the info tab (this is how I understand this option works).

Were this and this kind of logs also removed? I was using version 52 when I captured those from Reaper's addons integration sequence...

Yep, and only Intel. I'll try again next week on another system (last time I used an old laptop, now going to try on a Sandy Bridge desktop), again with a x86 version of windows, and report back if the same thing happened with the Intel chipset drivers.

Nope, if you install a x86 os with x86 drivers integrated in a x86 os, you're in trouble if you have a Intel chipset for the machine you're installing the os to. If you install a x64 os with x64 drivers integrated in a x64 os, everything it's ok. The problem is how DISM (probably) sees mixed x86/x64 Intel chipset drivers - as only x64 ones. Or it isn't integrating them as it should.

1. I understand that now they are just for show, but in version 50 they showed what drivers would be integrated wrong by DISM. It really did. 2. The only drivers that are integrating ok from the 9.2.3.1022 version of chipset Intel drivers in a x86 environment are the USB drivers. AND in version 50 they WEREN't red marked. If this doesn't mean anything for the way DISM sees things - you know better. 3. It's only happening in a x86 environment. I haven't had such problems in a x64 environment, but I'll check when I'll have the time. 4. The drivers were integrated through your app, but probably were marked as only x64 by DISM. Or I don't have an explanation for why this is happening. 5. You can find ALL the chipset drivers here - please download version 9.2.3.1022. Hope my feedback help and hope you'll sort this out. It's a very important bug. I'll be back later for other info.

Unfortunately the bug is still present in version 52 of your app. And I repeat, 90% probably a DISM bug. I don' think it's system/configuration specific - the version 50 was the best version so far that recognized drivers that would not be integrated properly. Version 52 only masks this; for example I remember that the USB drivers for Intel chipsets were integrated fine, weren't red marked by your app (and also considered x86 ok by DISM). I dunno how I can help you further. I'm sure 100% that integrating those chipset drivers for another windows and another Intel configuration will give the same results for an x86 environment

Can't auto-Select Language, Locale and Keyboard Locale, and also can't leave the serial blank. AND, most important, its interface isn't sexy LE: Really a joke last one :grin:

Nope, live system. I'll reply on this matter on tuesday, when I'l make another disk with at least version 51 beta. Hope you'll also have some time to investigate it further until then. And sorry I haven't mentioned it before, ALOT of features work more than ok in W7T, version 51 looks to me more of a close-to-final version Except Unattended Creator, of course

I can't reply to a closed thread, so I'm trying to elucidate a potential (unresolved) problem of your app. I can confirm that in the 51 beta build of 1.3.0 the cosmetic problem of the Intel chipset drivers beeing displayed as only x64 ones was resolved. However, this doesn't assure me that the real problem is fixed. The real problem was the drivers were slipstreamed (maybe it was because of DISM fault) as x64 only, so in a x86 environment they weren't recognised by the 7 OS, and weren't associated with the proper hardware (Microsoft 2006 drivers were the newest for at least 6 Intel chipset HWIDs). So, can you confirm that this glitch was also resolved? I'll also retest it on a live x86 Intel-based system probably on tuesday. Also, another 2 Marvell AHCI and one AMD IDE drivers that are mixed ones (x86&x64) are seen as only x64. You can see that here and here, and can find those drivers here.

Will the new and improved Unattended Creator make it into 1.3.0? I really hope so

A big problem with chipset drivers from Intel - all of them are VERY wrongfully seen by w7t as only x64 ones - as you can see here. I thought it was only a cosmetic problem, but although I slipstremed them with version 50 (windows 7 home basic x86 sp1 was the target), after windows install I had the older Microsoft drivers for chipset devices instead of newer Intel ones. Also, installing the inf utility on the live system changed nothing, I had to update all the drivers manually directing them to the unpacked folder of the inf utility. So please investigate this issue of not detecting the chipset intel drivers as MIXED ones, because I think that somehow they are slipstreamed in windows as only x64 ones. Also, if another driver is wrongfully seen by our ap, should I expect the same thing to happen - for example a mixed driver that is seen as only x64 by w7t can't be usable in a x86 environment?

I think this should be top-priority Also, the ability to leave a blank serial (trial) would be nice.

One question though about Everything-1.2.1.452Int_SI.exe installer: is it possible for it not to start right after the installing process took place? If I choose to make a nlite addon out of it, it will pop out its window at T-13, and that is a little awkward, and making installing of windows xp not so unattended. But thank you again.

So with version 50 I can try and add KB2533552 (msu) directly as a silent installer? Is this corect or I should add somehow that /quiet argument?

I've tried your latest (private) build Everything 1.2.1.452, and it works GREAT! Please update the alpha with this one. Thank you very much!

@shon3i Regarding a .net 4 installer, I only need one that wouldn't take forever to install, like yumeyao has done for xp. Or is faster it because it's happening at T-13, with the final step (waitnet / ngen) during first logon?

Just out of curiosity... why would you need the silent installers be run at T-13? They can be ran now with the help of windows 7 toolkit during first logon.

Great! Thank you!

Maybe you'll have time to implement some of these in the near future (hopefully build 48) ... some great tweaks above (those that don't duplicate already implemented tweaks)...

1. ... That would also be a nice addition to your app, only if it won't be buggy and easy to implement. 2. Great. Case closed. 3. You're the boss

I'm also having issues with that tweak... my solution for now is this silent installer.