bphlpt

I think that the necessary fonts are protected from being deleted on a running system. If so, to find out which fonts are necessary to keep you could try the following: (I have not tested this method, but I think it should work.) 1) First, copy all existing fonts to another folder so you can put them back if you need/want to. 2) Second, revert your system to the fonts included by a default install of Windows by following the instructions here - http://www.online-tech-tips.com/windows-7/windows-7-fonts/ 3) Then you can go to your fonts folder and try to remove fonts one at a time. The necessary fonts should be protected from removal, if I understand things correctly. You might want to install Office first, to make sure that any fonts required by Office remain. This page - http://office.microsoft.com/en-us/office-xp-resource-kit/administering-fonts-HA001136393.aspx lists fonts used by Office XP, I assume it is the same or similar to what is used in other versions of Office. Here is another link that lists specific fonts that should not be deleted - http://graphicssoft.about.com/od/aboutgraphics/a/fontoverload_3.htm. The page was originally written in 1999, but the fonts it lists should be appropriate, but there might be more fonts that should also not be deleted. I hope this info is helpful. Cheers and Regards

Downloads fine here with SWIron (version of Chrome). Cheers and Regards

Say what you will about RT Se7en Lite, and I usually say as little as possible about it, but in the latest issue of MaximumPC (September 2012) in the advice column "Doctor" the question was asked "I need to reinstall Windows 7. Is there a way to get all the Windows Updates without reinstalling them one at a time?" The ONLY suggestion they made was to use RT Se7en Lite. -:Heavy Sigh:- For a program that hasn't been updated in years, it is certainly well known and well used. Cheers and Regards

@Rick, it would be great if you could post instructions on how to use KUC with offline images, or point me to a tutorial if one exists. I also agree with you, Mark, and others that it would really be great if Lego could somehow incorporate KUC's functionality into Win Toolkit in some way, or use it as an external tool, or something. Cheers and Regards

I'm not positive, since I personally prefer to not remove anything, but my understanding of the way that DISM, and therefore Win Toolkit "removes" things is that they are supposed to be removed from use, so the OS does not have access to those features when running, but most of the actual files remain so the size of the ISO doesn't change that much. Is that what you are seeing? That is why some people still try to use RT7Lite, NOT that I would recommend using it, or vLite, but special steps have to be taken to use vLite with Win7 Sp1. Both of those tools have the ability to actually remove the associated files, but you will have to live with the risk of OS "damage" that might occur as a result. Remember that neither of those tools have been updated in quite some time and are no longer being actively being developed, unlike Win Toolkit. If the features are removed from use,I would think the netbook should be able to run just fine with the Win Toolkit "slimmed" version. Is the available disk space so small that that is the issue? It might be more reliable to spend a few bucks for a little bit larger disk drive if that is the case. Just a thought. Cheers and Regards

I've been seeing this a LOT when I use http://www.wincert.net/forum/index.php?app=core&module=search&do=viewNewContent&search_app=forums. Today, just now, I noticed that Reaper is listed on that page as "Guest" for ALL the threads he updated over the last week or so - 8 or so posts, though his avatar is correct. When you go to the actual thread he is listed correctly. Usually it is Rick that is the "Guest". I haven't really figured out the pattern, but it did start this behavior fairly recently, maybe a few weeks ago. Cheers and Regards

I believe it is this way because if the "normal" Temp folder is used it probably has all kinds of junk in it from many different apps. For Win Toolkit to be able to easily clean up after itself it puts all its files in a subfolder of the Temp folder. To be consistent, if you then specify a different "Temp" folder, ie a different outer shell, it will still create a subfolder for ease of cleanup, since Win Toolkit has no way of knowing if that temp folder is being used for anything else or not. I think it is all done for consistency, safety, and ease of programming. Cheers and Regards

Kel's having problems both his health, been in the hospital for several days, and with his site. It's not you. No need to keep asking for updates, we're all aware of the issues. Just be patient and keep an eye out for updates. Cheers and Regards

Patience, patience. Unless you are willing to pay Lego for his time, consider yourself lucky that he devotes any amount of time to this wonderful project at all. Complaining to any author of free work is more likely to just get them p**sed off enough to quit, rather than inspire them to meet your demands. It has already happened to more authors than I would like to think about. Be grateful for what you get, when you get it. Cheers and Regards

I really hope that the optional use of KUC can somehow be folded into Win Toolkit. I would love to end up with a somewhat automated way to achieve the type of results that compstuff did as he described in his link mentioned above. As long as all the various update providers, SoLoR, McRip, and Komm, provide different benefits, it makes sense to provide the option to use what works best for you. Also, this way if one or more is not available for whatever reason, you'll have a backup other than trying to get all xxxx number of updates one at a time from MS manually IF you can find them all. I would hope that the various tools all have similar enough organizations so that only one copy of each of the various updates is required in your local update repository. Cheers and Regards

I would love for someone with more knowledge than me to adapt Kel's instructions to using Win Toolkit. My understanding is that Win Toolkit can do much, if not all, of the work automatically without extra tools. And of course for the most flexibility, the instructions should specify what needs to be changed, if anything, to allow the result to be used via USB, either stick or drive. Eventually, the goal is to end up with a universal solution that can be modified for whatever particular need the user requires, in the fewest number of steps using the fewest number of tools. Cheers and Regards

Thank you for putting the amd64 section first. You are correct that both sections will still run and that this is not a substitute for a properly constructed batch file. But both ar_seven_am and I, and perhaps others, prefer it this way, and again if it doesn't create any problems for you, why not? crashfly's method of checking for the existence of a file that either should or shouldn't be there if a routine has already been run, is one that is very often used and is a proven way to handle a situation that just can't seem to be handled any other way. Of course it is also always best if you have to create a flag file that you make every attempt to clean up after yourself and delete the flag file after you no longer need it. Assuming the batch will only be attempted to run twice, and you actually only want the code below the test to run once, this can be accomplished as follows: if exits=%SystemDrive%\filetemp.txt del %SystemDrive%\filetemp.txt & exit echo . > %SystemDrive%\filetemp.txt (This also assumes that this code is in a batch file that will be called twice. If you have separate batch files for the x86 and amd64 section then this solution might not work for you.) And this test does not have to be the first lines of the batch. If there is code you always want to have run, even if it has been run before, then put this test after that code. To accomplish exactly what you want during an OS build requires a delicate dance between the Autoattend.xml and the batch files that it calls and exactly how those batch files are constructed - what is in them and in what order. Perhaps we should expand this thread's discussion to include the batch file's construction and contents in more detail since the batch files and the Autoattend.xml are so intertwined? Cheers and Regards

Thank you for continuing to work to make the Autounattend.xml as robust, universal, and bulletproof as possible. But I have to ask, in addition to everything you are doing, if processing amd64 first and x86 second as ar_seven_am and I have suggested, can even help with just one potential problem and make it even more bulletproof, why do you not want to do that? If it doesn't hurt anything in any way, why not? Cheers and Regards

I thought that Win Toolkit offered that same capability. Can anyone confirm that it does or does not? Cheer and Regards

Where? Cheers and Regards

That is true of course, and I understand your point, but I just figured that since for a computer running a 64-bit OS the "<FirstLogonCommands>" for BOTH "x86" AND "amd64" sections will get processed, it made sense to put the 32-bit programs in the "x86" section and the 64-bit programs in the "amd64" section. No? I realize that there will be a few exceptions to this rule, but in general I thought that was the best way. If I am incorrect, could you please give me some examples? Actually I just thought of an example that requires programs to be listed in both "x86" and "amd64" batches, assuming that the batches are set up to only be run for 32-bit and 64-bit OS's respectively - dual arch installers such as Adobe Flash. Since it is now only provided as a dual arch installer it should go in both the "x86" section and in the "amd64" section, with the "IF" tests set up to make sure that the installer is only run once. As an alternative, you could have two different sections within your 32-bit batch for 32-bit vs 64-bit OS installations to utilize. You could even get fancy and have three different sections - an "all" section at the beginning which would get run for any installation, then your "IF" tests would split it into 32-bit only and 64-bit only sections. The batch called from the "amd64" section would then truly only need to be 64-bit programs to be used in 64-bit OS. Right? Cheers and Regards

So Escorpiom had it backwards? The presence of the ei.cfg file will override the Autounattend.xml? So if the ei.cfg file is removed we can use the same Autounattend.xml for either DVD or USB use? Shouldn't your comment above: <!--Batch file to launch the 64-bit or 32-bit programs--> actually be: <!--Batch file to launch the 64-bit programs--> since from where it is it will only be called for a 64-bit OS? While your other comment: <!--Batch file to launch the 32-bit programs--> should actually be: <!--Batch file to launch the 32-bit or 64-bit programs--> since from where it is it will be called for both 32-bit and 64-bit OS? Or am I missing something? Cheers and Regards

I would love to hear the details of this method, it's advantages and disadvantages, and why you chose to use this way over RMPrepUSB and the other options. Probably best to explain the details in another thread though. Don't want to hijack the thread. As if I'm an expert. LOL Actually, it depends. I only looked at them briefly before and thought they were two tests you made with the first one giving the correct results and the second one not. Is that correct? And it is then called from the "FirstLogonCommand" section for x86 only, since x64 only commands can be called cleanly in a separate batch from the "FirstLogonCommand" amd64 section. Is that correct? Assuming both of those statements are correct, so the batch will only be called from the "FirstLogonCommand" section for x86 and statements inside will only be intended to be executed by a 32-bit OS, hence the whole reason for the "IF" tests, and also assuming that you do not need the Arch0 variable for any reason, then your batch can be written: @echo off if not exist "%SystemRoot%\SysWOW64\cmd.exe" if not defined PROCESSOR_ARCHITEW6432 goto :Cpu86 goto :exit :Cpu86 :: Put all your x86 only statements here :exit exit which is what you had only slightly "cleaned up". If my understanding was not correct, I would be happy to take a look at the actual routine you are trying to use to see if I can spot any problems. I would also need to know when it is called and where it is called from. Cheers and Regards

Escorpiom and myselfidem - It would be really great if we could come up with appropriate settings that would accomplish these in all cases, ie have a truly universal AutoUnattend.xml that would work as intended for both DVD and USB installation methods and hopefully for all the most popular installation tools including Win Toolkit, WinNTSetup, WinSetupFromUSB with GUI, RMPrepUSB, NT6FastInstaller, DX WinNT6.x True Integrator, and any others I've forgotten including plain vanilla installs using nothing but MS tools and methods. Possible, or just wishful thinking? Please feel free to list all other OS installation tools anyone is aware of that the Autounattend.xml might be used with. It would be nice to have them all listed in one place. Note also that I have not used all the tools I listed above so if I listed one that has nothing at all to do with Autounattend.xml please let me know. Cheers and Regards

I hope Lego has better eyesight than I do because I can't read either one of those pics. Any chance for a larger version? Cheers and Regards

Download link works fine for me. Cheers and Regards

Escorpiom, double check your logic. Your logic says: If A And B Then Exit. My logic says: If NOT ( If NOT A And If NOT B ) Then Exit. They are not the same. Mine can be reworded as: If A Or ( If NOT A And If B ) Then Exit But since batch does not have an "Or" that can't easily work without breaking the code into multiple statements. Also, B, ie the existence of PROCESSOR_ARCHITEW6432, ONLY matters if NOT A, ie if "%SystemRoot%\SysWOW64\cmd.exe" does not exist. Any decision made strictly on the existence of PROCESSOR_ARCHITEW6432 might be incorrect. I know it can be confusing, but I believe the way I wrote it in my earlier post is the most efficient structure. Cheers and Regards

The key is that for myselfidem's cmd batch files SPTDinst_x86.cmd and FirstLog_x86.cmd, or whatever you use that is called from the "RunSynchronousCommand" and/or "FirstLogonCommand" sections, are skipped if it is determined that this is a 64bit OS. Those extra exit points are not needed in either SPTDinst_x64.cmd or FirstLog_x64.cmd since those will only be called in a 64bit OS. myselfidem uses a test for the existence of "%SystemDrive%\Windows\SysWOW64" to determine the bit-ness of the OS. You might want to check out this thread - http://www.ryanvm.ne...opic.php?t=9672 for a more detailed discussion of this particular problem. If you find the "improved" method mentioned there suits your needs then the part of myselfidem's batches that currently reads: if not exist "%SystemDrive%\Windows\SysWOW64" set Arch0=x86 && goto :Cpu86 if exist "%SystemDrive%\Windows\SysWOW64" goto :exit could be changed to: if not exist "%SystemRoot%\SysWOW64\cmd.exe" ( if not defined PROCESSOR_ARCHITEW6432 set Arch0=x86 && goto :Cpu86 ) goto :exit Note that the variables Arch0 and Arch9 in the batch files must be used elsewhere in myselfidem's batches. You might not need them. But with an understanding of the concept you should be able to modify the batches for your needs. Read both myselfidem's reference and the one that I gave carefully and consider your personal circumstances to decide on a course of action. Then test carefully in a VM before trying it on actual hardware. Please let us know how it goes and share your final solution if you feel it would be of benefit to anyone. Cheers and Regards

Have a Great time Reaper! Cheers and Regards

I don't know if WPI is meant to be run at the point you indicate. Doesn't WPI stand for "Windows Post Install", meaning after install is finished or after first desktop? Cheers and Regards