Jump to content

GreenMachine

Developer
  • Posts

    3,070
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    France

Everything posted by GreenMachine

  1. Here is my version of the RoyalBox HotFix SlipStreaming Method. This is similar to the script posted by RoyalBox, both being offsprings of his original work posted here. The XP distribution is prepared for installation by slipstreaming the latest service pack, slipstreaming hotfixes that are slipstreamable, and programming other installation processes and hotfixes to be executed during system installation. The advantage to the hotfix slipstreaming as done using this method is that (almost) all versions of the files on the installations CD will be coherent and up to date, and there will be minimal need to re-apply a hot fix after windows asks you to insert the installation CD at a post setup point. I find this the most stable method, as the maximum of files have been updated to the latest versions, the only exception being the type 2 hotfixes that cannot be slipstreamed. (There are fewer type 2 hotfixes, and they are often more of an additional component than a hotfix). Files inside of cabinet archives are updated, and the master file list, DOSNET.INF, is also updated according to hotfix updates. There is debate about how to handle type 2 hotfixes. I have decided not to attempt to slipstream the contents of these hotfixes. The code, however, is still in place, but "deactivated". I do program these hotfixes to be run, along with type 1 hotfixes, during the installation process. The installation of hotfixes requires quite a bit of time, and you will find your installation "stalled" at the T-13 point for up to 30 minutes. This is due to each hotfix going through a long search for installed devices and software. (Windows update is quicker, as it does this only once per session, I think ...). I install the hotfixes in unattended mode, as opposed to quiet mode, so that you will notice some life in the installation at this point. As I was developing and testing the process, it got a little out of hand, and I kept adding bits to the scripts. So now I have it rip the XP CD, slipstream, and burn the new CD. I have decided to include the whole script here ... as I am too lazy to only include the actual hotfix slipstreaming. The slipstreaming part is the majority of the script. The basic operation is: - Place all the hotfixes in predetermined directories. - Place custom files in predetermined directories. - Put your XP CD in the CD Drive - Put a blank CD in a second CD burner (optional, or switch in the middle if only 1 drive) - GO Behind the scenes: 1) Initialize the environment 2) Copy CD contents to HDD 3) Slipstream Service pack 4) Slipstream Type 1 Hotfixes 5) Create the SVCPACK.INF installer file, and update corresponding DOSNET.INF file. 6) Create the CD structures, adding all additional and custom files 7) Create an ISO CD image 8) Burn the image to CD I have written this to suit my needs and style. This may not be yours ... but the script is not too big, and I have tried to keep it simple and modular. If it does not work as you like it, you should be able to modify it with out too many headaches. I have tested the burn process, but not extensively. Beware. If you have constructive criticism, or interesting questions, I'm willing to listen and talk. If you think your method is better, it probably is. I have enough trouble understanding my own code, let alone someone else's ... and this does just what I need at the moment. I know this post should in all rights be included in one of RoyalBox's two THREADS on the subject, but I have decided to make a new thread so I can be first! No, I have decided to make a new thread so that I can post the script as part of this message, and update it from there as opposed to using a download site. Hope that's alright by all. The latest version of this script will always be listed below. For the moment, the readme file is a little sparse. To try it: HERE @RoyalBox: Thanks for your help and ideas. @AaronXP: Fell free to use this however you see fit. I post it like this so I do not have to host it somewhere. I have not included any binaries, as software distibution is not my thing. However, if you want to package it with the binaries, that would be helpful. If not, there are links for all files needed. Here it will at least be easy to find.
  2. IEXpress, eh? Could I get you to elaborate HERE please?
  3. Thanks, Gosh. Any chance you could edit your first post to have the .INFs in CODE BLOCKS? That way it'll be around indefinitly. Thanks again!
  4. So that's the trick: SFX. I wonder why MS suggests that MSI installers be run from GuiRunOnce, and not before. I wonder if MSI's in a wrapper is OK. I guess there are quite a few that do it (and I probably do as well, inadvertantly, by running one of the MS updates/installs like DotNet of WMP & MM2). Thanks.
  5. Thanks for the links, I'll look a little later. A repackager for the DotNet and MDAC executable, that could upack the single installer, and call it with the proper switches would suit my needs. I could then call these files from CMDLINES.TXT or SVCPACK.INF without the need for quotes i the switches (it don't like that). I would also like to get inside the installers to modify or override the installation paths.
  6. 1) NO - I think installing from SVCPACK is an undocumented, unsupported option. (But I do like it!) Kind of try and see, but judging from the results, and the point of the installation at which it happens (just before CMDLINES.TXT) I am convinced it is safe. 2) I really don't enough about .msi's. I install DotNetFX, and I assume that is an msi in an installer. I have done it, others do it, and it seems to work. There is another thread going on about this subject, and I am just getting around to learning about it. 3) The .cat files are the security catelog, i.e. signature files. If the hotfixes are indeed slipstreamed - that being pertenant files extracted and injected into the distribution, than these .cat files must be with the updated files. Aarons guide does not say to use them (I think, I have not actually looked at it in details since he posted it) as he uses SVCPACK.INF to call the hotfix installers, and does not integrate the files before hand. I use the RoyalBox HotFix Slipstreaming Method to update the files on the CD before CD creation. Aarons method just installs the hotfixes from there. We still need to actually run the installers to update the registry and such, and it will, in fact, once again try to update the files, albeit with an identical version. The risk of Aaron's method is that files exist on the CD, but a later version is installed. Probably a very minor risk for most of us, and both methods result in an equally up to date installation (at point zero). If the system ever asks you to insert the Windows XP CD, then you may have to ask your self which files it is getting, and if they are up to date.
  7. That must have been the short article I passed you ... The other one is actually quite a good reference, though not exactly easy reading. (See previous posts for links) Yes, updating the [ForceCopyDriverCabFiles] section is to allow updating files inside, without updating the cab itself. This, I would think, is the prefered method, as the system will look in the I386 directory, find the file, and not need to extract it. Updating DRIVER.CAB is, perhaps, not needed. I do the [ForceCopyDriverCabFiles] thing, because I think it the better way, but I update the DRIVER.CAB for two reasons (Three, if you count my sometimes compulsive tendencies...) Firstly, I do not want to have any outdated files on the system. I do not see that it would ever help me. Secondly, I was thinking about all the cabs, and I extract, update and recompress all of them (See point three above). This way I do not have to treat it as an exception, it is just one in the loop like the others. In terms of updating DOSNET.INF, my approach is this: I always start with DOSNET.INF (along with over 5000 other files) off the distrubution CD. I slipstream the latest service pack (I think this updates DOSNET.INF, but I do not know: I wait till slipstreaming is done before touching it.) At that point I take the file, and assume that the [OptionalSrcDirs] has not been added, and that the [ForceCopyDriverCabFiles] is the last section. I loop trough all files to be slipstreamed, and if they exist in the DRIVER.CAB file, then I add them to the end of DOSNET.INF (with the ECHO >> DOSNET.INF append option). After all the files have been added to the list, I add the [OptionalSrcDirs] section. Note that I can no longer add any files to the [ForceCopyDriverCabFiles], as this section is now closed. (That is one reason to start fresh each time.) I think I just realized that above is kind of what you said... I do not have the problem of an updated DOSNET.INF, as I start with a new one each time. In fact, my staging area only contains files that are NOT on the CD (WINNT.SIF, CMDLINES.TXT, INSTALLS.CMD, *.REG, HOTFIXES, UPDATES). Each and every time I create a CD (or ISO) I go through the whole process, from rip to burn. It takes about 10 minutes, but it is a click once and wait thing, so that is OK. Basically, my ideas on the subject: Start from a known state each time (virgin DOSNET.INF, un-service packed files). Search and replace is messy at best. This also allows you to remove superceeded fixes.
  8. QCHAIN's function is to go through the list of files in the registry that are supposed to be updated at next boot (usually SET??.TMP to FILE.DLL or something). It analyzes the version numbers of the files, and if the same file is to be updated twice, it insures that the final update is the latest version. QCHAIN will become worthless, because QCHAIN functionality is built-in to the Windows XP Hotfix Updater - well almost. It is the "almost" that makes it a keeper. There are probably very few hotfixes that would need it, but one is enough for me. More than once, I have spaced out and forgotten it, and did not notice any particular problem. It is harmless, whenever you run it, so for that reason I say to use it. Another reason I suggest to others to use it, is that it will eliminate one more unknown in the debugging, and if I am going to be helping searching for a problem, I think it most effective and efficient to take all known precautionary measures. (Not to mention how stupid I would look if that was, in fact, the problem on an installation I either did myself, or helped with.) I guess it is kind of a CYA thing. I will continue to use it until at least SP2, or later if I forget to remove it... Security Rollup may not need it, but there are still other hotfixes that I use that are not integrated into SR1.
  9. QCHAIN.EXE should be in <CDDRIVE>:\$OEM$\HotFixes\ to work in your example. It is not actually copied to the hard drive: It is run from the CD, and it rearranges the order in the registry key that determines which hotfix files will copied/updated on the next reboot (oldest to newest).
  10. Whether you NEED QCHAIN.EXE is hard to say - depends on exactly which hotfixes you use - but it NEVER hurts. Put it in to be sure.
  11. I wanted no /n switch so I could uninstall in order to reinstall. There is also a "HotFix' or "Update" key in the registry that lists hotfixes, and is used by QFECHECK. You could also try that or even better HFNetChk and see what they report. Sounds like you were really close, though, if you got it once ... I'm hoping you can save me figuring out this one. You can also look at the inf file extracted from the hotfix, and there are sometimes clues there. The WMP9_MM2 is good 'cause it's easy and clean. no switches.
  12. I'm flattered. If I wanted to keep it for myself, I probably would just be a lurker. Glad it helps.
  13. I noticed something up with as well, but have not had the time to check it out. I install WMP with MM2 in a package, and have no problem with that one. Last time I had a similar problem, it had to do with the registry, and that when the package was installed without the uninstall option (/n I think) it did not report as installed. I attempted to install without the switch, both from the command prompt, and from windows update, and though the installation did not complain, there was never the uninstall option added to the control panel. For this reason I could never actually uninstall to install over, and when installing over it see's that the files are up to date, so does not gracefully exit the installation procedure. What I would try (will try?) is to install with no switches and see if it is no longer listed in Windows Update, uninstall and see if it comes back, and then track down the file and reg changes, add them little by little, and see at which point Windows Update thinks the files are OK. Please post any progress. @Ypsos: MS recommends that .msi files be run from GuiRunOnce (then again, what do they know ...) I am interested in the link, though. An MSI to EXE would be really great.
  14. Looks good, Miso. May I ask how you are installing NetFW without any switches? I would like to do the same. And the Media Player Tweak as well.
  15. Yes, SVCPACK and CMDLINES are suspiciously similar, and apparently interchangable. SVCPACK seems to be "richer", as you have the full .INF install structure. Neither method allows for a command line with a quote character, so MDAC and .NET cannot be done from there. I seem to remember a similar problem with WMP9, and I don't think I found the answer: that is why I went to the silent switchless WMP&MM2.
  16. HotFix Installation Methods There have been many different methods mentioned here, but the three following are the only ones that I would consider "safe". 1) SVCPACK.INF Method. 2) CMDLINES.TXT Method. 3) GuiRunOnce Method. 1) Advantages: When done correctly, insures the highest level of file coherency as all previous versions of all files are replaced with the updated versions. These hotfixes will never need to be re-installed. Most space efficient of 3 methods, as outdated files are removed before creating the distribution. This method, SVCPACK.INF, also requires modification of the DOSNET.INF file. This method will slipstream the hotfixes, the other methods will apply the hotfixes. 1) Disadvantages: Most complicated of the three. 2 & 3 are similar in end result, and not as stable as 1. The advantage is that it is easy to implement. Picking which of the two to use seems to be a personal preference, but according to MS:
  17. RoyalBox! There was another thread about slipstreaming the security rollup, which got me thinking about DRIVER.CAB. I think you also mentioned about checking out the .cab files. It looks to me like DRIVER.CAB does, in fact, have some files that are updated. This and SP1.CAB appear to be the only ones (at this point). I decided to unpack them all, update tham all (if necessary) and repack them all (regardless). I don't think that should matter for the .cat files, it is the files, and not the cabs, that are signed. (I hope ...). There was also a link to the MS Site, which is worth reading. After reading that, I decided to automatically update DOSNET.INF in the [ForceCopyDriverCabFiles] section (fortunatly at the end), and the [OptionalSrcDirs] just afterwards. I also decided to use SVCPACK.INF to install the other updates, like MSJavaVM, DirectX, etc. To that end, I have a few more hotfix directories, that determine both the execution order and the switches. I need to run WMP9 before the corresponding hotfix, and QCHAIN.EXE at the end. I also now use the Unatteded switch instead of Quiet, so there is animation at the T-13 point. I've tested it with all hotfixes installed/slipstreamed except 4 non-critical, and HFNetChk, and it all jives. In terms of 817778, I have determined (in my own mind...) that it needs the shell to work, and running from SVCPACK.INF, or CMDLINES.TXT, the shell is not loaded. I'm afraid I will finally need to use GuiRunOnce HERE'S WHY (read the Choosing a Method for Automating Post-Installation Tasks section) ... know any good guides ... For the rest of SuperhumaN's questions, I haven't the foggiest. They work for me. I use HFNetChk, an alterantive to QFECHECK. Don't have the download, but MS has it.
  18. NET ACCOUNTS /MAXPWAGE:UNLIMITEDThis changes the Maximum Password Age to something like 49000 days.
  19. Sorry, I did not go back and read over your posts, and still haven't. The line above led me to believe that you were merging HKCU from the GuiRunOnce (...don't know why...). Many people here make changes to HKCU from the administrator (GuiRunOnce), and this has no effect on any user other than the administrator. Merging again, to "ensure that it would properly activate my choices" will have no effect except for the administrator account. That's all I was trying to say. OK. 3) Should read "I do not personally use or configure OE, so I cannot help you there." Again, the second .reg merge is futile. I do not know much about the drivers, but if the video drivers are already installed at this point, you can remove the "Drivers" directory. I would think that GRO would be a fine place to do cleanup, but again, these are not the methods I use, so I prefer to let others answer.Lastly, the setting mentioned by Geeko should work at any point (though you may need to restart). It is not one of the Explorer or IE HKCU Visual Settings. You can at least test it without building a system. I say you are making a simple problem complicated, because you have too many unrelated problems. It looks as you made a complete installation from the top down, instead of bottom up. I have difficulty debugging in this fashion: perhaps you do not. I prefer to start with the MS standard unattended setup, insure that all is working, and then add the modules one at a time, moving on to the next module only after the previous is error free. Chill: I was only trying to give you a hand looking in the right direction...
  20. In the registry, if you still use that, there is both "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" and "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders". One uses %USERPROFILE%, the other does not.
  21. As I said BEFORE, dime to a dollar it's 817778 ...
  22. Which method is "true" and which is "NOT" is simply a question of semantics ... The result of either method is quite similar: both have the files "integrated" (a.k.a. slipstreamed) into the I386 folder. The difference is in the installation method. Gosh's method extracts the installer, and only keeps that (thus the "UPDATE" directory, as opposed to the "SVCPACK" directory), not the compressed updated files, which are already in I386. The installer will still overwrite the updated versions, albeit overwrite a file with itself, as it is working in it's native form, and looking for files in the parent directory to copy to the installation source. You cheated with your "salesmans" math: you do not take into account the free space due to deleted (overwritten) files. Sorry, I just get suspicious when presented with number arguments ... Though the files contained in the RollUp are indeed those from previous hotfixes, the .inf file, a compilation of the included hotfix .inf files, is not. This is the beta part. Don't underestimate the importance of this: all registry settings are controlled here. In any event, using beta software in a supported microsoft environment is not an option in the professional environment: Waranty violation, or just simply no longer supported. All in all, both slipstreaming methods will result in the same installation (or there would be a problem here). Gosh saves space on the CD (I don't need it: I have a ton free already). Now, either my head is still fuzzy this morning, or you overlooked the obvious: With "UPDATE" and UPDATE.INF now hardcoded, what happens with the next hotfix you would like to integrate? Even worse, suppose we have RollUp I and RollUp II? I do thank you for bringing my attention to [ForceCopyDriverCabFiles]. I have to look into that further. I looks like you listed everything. I wonder if only the files actually in DRIVER.CAB need to be listed? I wonder if this might apply to other .cab files?
  23. I'm not that fluent in the batch stuff either. It was the other one I thought more interesting, the "ENABLEEXTENSIONS". Still, there is no reason it should work for me and not you. I am running on win 2003 server, but I would hope that is not the problem ... It just is not logical. I loop through the directory listing, if there are any .cat files, I copy to the exe and delete the .cat files. The second time around (if there are 2 .cat files), there should not be any .cat files left, as I deleted them the first time 'round. How do you get there 2 times? Doesn't this sound suspiciously similar to the problem listed above, where you had to change *.* to *.sys? "IF EXIST CATDIR\*.cat" is returning true, when it is false. It works for me AND the logic is sound. Strange indeed ... unless it is an undocumented feature of the UK version over the US version. Try it with just the one troublesome file, and put a pause in the loop, so you can examine whether the *.cat is really true.
  24. I was sure I posted this, but I must have forgot to hit the OK button ... @RoyalBox: I think the problem may be in the environment(SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION). @ECHO OFF SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION if exist HFDUMMY RMDIR "HFDUMMY" /S /Q > NUL MKDIR HFDUMMY FOR /f "usebackq delims==" %%i IN (`dir /b HFTYPE1\*.exe`) DO ( IF EXIST CATEXT\*.* RMDIR CATEXT /S /Q IF EXIST CATDIR\*.* RMDIR CATDIR /S /Q START "HotFix" /wait "HFTYPE1\%%~ni.exe" /q /x:CATEXT IF EXIST CATEXT\UPDATE\*.cat xcopy /d /h /y /s CATEXT\UPDATE\*.cat CATDIR\ IF EXIST CATEXT\SP2\UPDATE\*.cat xcopy /d /h /y /s CATEXT\SP2\UPDATE\*.cat CATDIR\ IF EXIST CATDIR\*_me.cat del CATDIR\*_me.cat /q IF EXIST CATDIR\dummy.cat del CATDIR\dummy.cat IF EXIST CATDIR\empty.cat del CATDIR\empty.cat FOR /f "usebackq delims==" %%j IN (`dir /b CATDIR\*.cat`) DO ( IF EXIST CATDIR\*.cat COPY HFTYPE1\%%~ni.exe HFDUMMY\%%~nj.exe DEL CATDIR\*.cat /Q ) )That works for me, even after naming the hotfix as you had in your post. Try and tell.
×
×
  • Create New...